korobey, наличие в трассировке адресов RFC1918 ничего не говорит о наличии NAT, маршрутизаторам часто назначается "серый" собственный адрес чтобы они не были доступны извне.
3proxy специально разработан для таких конфигураций.
Проблема не в том, что 3proxy что-то не умеет, а в том, что вы не настроили маршрутизацию для дополнительных IP адресов.
Что вы имеете ввиду под дескриптором, базовый адрес?
Но в любом случае не хватает исходных данных, а что у вас при этом есть? Можно получить, например, адрес какой-нибудь функции из таблицы импорта исполняемого файла, если он уже слинкован с DLL и по нему найти начало DLL в памяти.
Не могу сказать про ePochta Mailer, но Content-ID и ссылки cid: в приложениях для рассылок обычно генерируется уже при отправке, в приложении генерирующем письмо вставка изображения как правило производится каким-то другим способом, специфичным для приложения, например по имени файла или через WYSIWYG редактор. Почитайте документацию по программе, например вот эту статью.
Это не так, ассимметричная криптография не используется для шифрования больших объемов данных. Ассиметричная криптография используется для аутентификации и генерации симметричного сеансового ключа, сами данные шифруются с использованием симметричной криптографии.
Если у epoll_wait последний параметр -1, то это значит, что кто-то изо всех сил хотел выстрелить себе в ногу, т.е. это и есть случай плохо написанного приложения, при котором перед ним лучше поставить обратный прокси (nginx например).
Конец вашего вопроса не понял, соединенный (connected) сокет всегда соответствует одному соединению. В TCP всем принятым соединениям соответствует соединенный сокет, собственно это и есть соединение. Или вы имеете ввиду сокет epoll'а? Для epoll_wait обычно устанавливается таймаут соответствующий мимнимальному из таймаутов соединений.
Данил Тунев, причем тут загромождение памяти? В любой функции ожидания событий от сокета (select/poll/epoll/etc) изначально есть таймаут, приложение всегда обрабатываете таймаут как событие. Поэтому в любом приложении есть таймауты на соединение. Если у вас плохо написаное серверное приложение и в нем таких таймаутов нет или нет возможности ими управлять - ставьте перед ним нормально написаный обратный прокси, в котором такие таймауты есть.
armodim, спамеры не заполняют руками формы, они просто дергают серверсайдный конец. Если "обязательность" поля проверяется в браузере и не проверяется в серверсайде, то ориентироваться на это не надо.
Ваш комментарий это прямо пучок заблуждений. Во-первых, невозможно лишить автора авторства, даже если автор сам этого захочет. Во-вторых, открытость исходных кодов не означает перехода в общественное достояние. Более того, публикация по GPL и публикация как общественного достояния - не совместимые вещи.
Да, это так - письмо хранится в "разобраном" виде с дедубликацией вложений и инлайнов, при этом обратная сборка не всегда дает тождественный результат, особенно на письмах с необычным форматированием вложений. Поэтому письмо из "отправленных" в Thunderbird и с сервера может не совпадать.
Но письмо полученное из ящика на сервере в Thunderbird и полученное через загрузку eml в web должно совпадать, т.к. получается одним и тем же способом, если различия возникают при таком сценарии - напишите в службу поддержки.
etrhfgth, ну вы проследите чтобы по крайней мере это была витая пара с экранированием и грозозащитой и трос с заземлением. Потому что првайдер рискует только коммутаторами, а вы - всем что к сети подключено.
Если быть точнее, то это
Ошибка (уязвимость): использование небезопасного метода при вызове внешнего приложения + недостаточная фильтрация ввода (сочетание двух ошибок)
Вектор атаки: шел-инъекция
Импакт: удаленное выполнение кода
MaKS_Ibl4, если вы правили DNS-запись, то она может кешироваться на какое-то время.
Если не правили, то основная причина - неправильно сформированое письмо, которое нормализуется (исправляется) при доставке. Нормализация меняет DKIM-подпись. Самые частые причины - отсутствие Message-ID или Date, слишком длинные строки, неправильные терминаторы строк.
