tex620, скорей всего, вы ошибаетесь. И для UDP и для TCP требуется отдельный порт для каждого "соединения", просто в TCP эфемерный порт обычно назначается неявно при connect, а в случае UDP его надо открывать явно через listen. Более того, по умолчанию nginx использует отдельный порт для каждого UDP пакета, см. здесь https://www.nginx.com/blog/announcing-udp-load-bal... ответ от Owen Garrett.
Лучше бы вы описали свои задачи, а не ваш вариант решения с велосипедами, потому что в этой схеме прокси скорей всего вообще не нужен, нужен source routing.
Это опять путаница между контролем файлов и контролем процессов. При подмене DLL на диске и затем при запуске приложения антивирус будет проверять файл DLL, потому что к нему будет обращение. Если вредоноса в нем не обнаружено, то игра запустится, но антивирус будет контролировать активность процесса. Если процесс начнет выполнять действия характерные для мелвари - антивирус может быть сумеет эти действия обнаружить и блокировать, ему не важно каким именно образом мелварь попала внутрь процесса. Если процесс загрузит файл (т.е. создаст новый файл на диске), этот файл опять же будет проверяться как файл. Если и в нем не обнаружено мелвари, то его можно будет запустить и антивирус будет контролировать активность процесса и обнаруживать характерную для мелвари активность процесса. В целом, антивирус обычно ничего не знает о цифровых подписях и лицензионности игры, он ищет известные ему вредоносы, Или антивирус умеет детектить этот вредонос или не умеет (если он новый и не похож на другие по повеению). В случае подмены или заражения файла совершенно все равно что именно заразили - EXE или DLL.
Подмена DLL может обойти инструменты/политики Windows (иногда используемые в корпоративных сетях) для ограничения запуска приложений, при которых контролируется путь и подпись исполняемого файла, антивирусу на нее в общем-то наплевать. Вряд ли эти инструменты используются на тех компьютерах, на которых игры установлены.
это в общем-то даже не версия, на момент написания "RFC" более-менее надежное распознавание символа требовало точного позиционирования и метки позиционирования, в т.ч. такие были (и сейчас часто встречаются) в практически любых формах предназначенных для машинной обработки даже если форма заполняется не от руки, т.е. распознать машинописный текст без таких меток было бы просто технически неразрешимо.
redcircle, имеются ввиду отметки позиционирования, например похожие используются для распознавания позиций на почтовом конверте - верхний ряд черточек https://upload.wikimedia.org/wikipedia/commons/thu...
только здесь их предлагается делать (вертикальными?) между символами.
Версия с голубиным дерьмом конечно интересная, но увы, тут речь про машинное распознавание.
Потому что такой подход пораждает вторичный спам, который заваливает abuse-контакты, предназаченные для "человеческого" обращения и спама становится еще больше (оператору крупной сети разбирать вручную спамрепорты по каждому случаю спама совершенно нереально). Использовать подход спамкопа нормально для администратора небольшого корпоративного почтового сервера, но если крупные почтовые службы начнут спамить на abuse-контакты, то наступит апокалипсис. Стандартный механизм для оповещения о спаме это FBL (Feedback Loop), он поддерживает отправку репортов в стандартном формате поддерживающем автоматическую обработку на специально выделенные для этого адреса и только тем, кто в этом заинтересован https://help.mail.ru/developers/notes/fbl
Mail.ru умеет слать репорты как по доменам так и по IP адресам, и напрямую и через ReturnPath (https://fbl.returnpath.net/) - это крупнейший аггрегатор FBL.
Насколько мне известно, Spamhause в настоящее время на стороне Mail.ru не используется.
Дополню, что большая часть распространенных лицензий на открытый код не запрещают создание производного коммерческого кода, но некоторые накладывают дополнительные оаграничения (например по GPL исходный код должен публиковаться, по LGPL код может быть закрытым, но должен собираться так, чтобы LGPL библиотеки можно было заменить и т.д.).
Они не отбрасывается, они оставляются в системном буфере и могут быть получены при последующих обращениях к recv(). Ваш код просто не сработает, он будет ждать пока другой конец не закроет сокет и не сможет отправить клиенту ответ, например.
Проще всего админом сбросить пароль пользователю, после чего на стороне пользователя валидировать телефон, тогда никаких анкет и обращений в поддержку не требуется
Отправьте сообщение на любой сервер и посмотрите заголовки полученного письма, обычно по заголовкам Received и/или Received-SPF видно и PTR и HELO, например
Сам факт совпадения PTR и HELO обычно практически не влияет. Сильно влияет наличие в HELO правильного имени, сильно влияет наличие SPF по этому имени (у вас он совпадает с SPF по самому домену) и очень сильно влияет наличие правильного PTR, который разрешается обратно в тот же IP (FCrDNS)
Да, во-первых получатель видит не адрес отправителя из SMTP-конверта, а адрес отправителя из поля From, и они могут быть разные. Ответ уходит на адрес из From, а сообщения о недоставке на адрес SMTP-конверта.
Во-вторых, можно установить заголовок Reply-To, тогда ответы будут уходить на адрес из этого заголовка, он может быть отличным от обоих предыдущих.
Вячеслав Грачунов, в целом нет, т.к. проси не видит что происходит внутри https, можно установить маленький таймаут на CONNECTION_SHORT/CONNECTION_LONG, см timeouts
В SPF нет ограничения на количество элементов в политике SPF, есть ограничение на количество DNS запросов, которые нужно сделать для применения политики.
a: требует одно разрешение имени
mx: требует одно разрешение для получения mx + по одному разрешению для каждого сервера, на который указывает mx
ip4: требует 0 разрешений (т.к. это уже IP адрес). Поэтому ограничений на количество элементов ip4: в SPF нет (кроме технологических ограничений DNS).
вот тут есть достаточно подробно: https://habr.com/en/company/mailru/blog/338700/
там раздел "Заблуждение: чем больше всего (a, mx, ptr, include) я включу в SPF-запись, тем лучше, потому что меньше вероятность ошибиться"
