Владимир Дубровин

На уровне сети (IP) и транспорта (UDP, TCP) pid не передается. Процесс, которому предназначем полученные данные транспортного уровня, определяется по принадлежащему ему слушающему сокету, который определяется IP адресом, протоколом и портом.

Надо смотреть содержимое пакетов, иначе плохо понятно что происходит, попробуйте поснифать трафик. DHCP Discover может быть не только для получения IP адреса, некоторые службы, например WPAD, тоже используют DHCP, при этом идет отдельный запрос.
Мне больше кажется странным то, что у вас идет
Apr 15 08:09:55 mail dhcpd: DHCPACK on 192.168.1.187 to 50:46:5d:8c:77:20 (comp1) via rl0
Apr 15 08:10:08 mail dhcpd: DHCPACK to 192.168.1.187 (50:46:5d:8c:77:20) via rl0
два ACK на один DHCPREQUEST. И у вас случайно не поднят шлюз DHCP где-нибудь? Может быть сервер ждет ответа от шлюза, т.к. шлюз всегда отвечает с задержкой, а ответ на адресный запрос при обновлении лиза обычно имеет приоритет над броадкастным.

Можно установить 3proxy https://github.com/z3APA3A/3proxy/ в некоторых дистрибутивах он уже есть в пакетах.
с примерно такой конфигурацией:

auth strong
users user1:CL:pass1 user2:CL:pass2 user3:CL:pass3 ...
allow user1
parent 1000 extip IPv6-1 0
allow user2
parent 1000 extip IPv6-2 0
allow user3
parent 1000 extip IPv6-3 0
...
socks -6 -iIPv4 -p1080

документация
3proxy.ru/documents
особенно FAQ, HowTo и "Семь слоев матрешки, или Настройка 3proxy для чайников".

У multipart/mixed не может быть Content-Transfer-Encoding.
После каждого заголова должна идти пустая строка - перед
$headers .= "This is a MIME encoded message." . $eol;
перед
$headers .= $message . $eol;
и перед
$headers .= $content . $eol;
После конечного сепаратора - тоже.
Строки должны разделяться CRLF, PHP_EOL в Linux это просто LF.
Если это не поможет - опубликуйте конечный eml.

Да, скорей всего это можно раскрутить до XSS, попробуй вектор типа
" onmouseover="alert()" b="

traceroute -P TCP -p 1723 IP

Но скорее всего, проблема не в блокировке порта. PPTP помимо порта TCP/1723 использует протокол GRE, если ваш провайдер использует NAT, то в нем требуется специальная поддержка NAT для GRE, если ее нет, то соединение не установится. Если у вас запрашивается и принимается логин с паролем, а потом не устанавливается соединение - то проблема именно в этом. Возможные варианты решения - использовать SSTP вместо PPTP (в Mac OS X скорей всего надо ставить сторонний клиент).

У вас настроен лимит на размер подписываемого содержимого (l=366) и этот лимит конфликтует с размером ключа. Уберите этот лимит, его использование крайне нерекомендуется.

P.S. временную метку (t=) я бы тоже рекомендовал убрать из подписи, иначе можете получать ошибки если у вас часы будут вперед хотя бы на секунду относительно получателя.

P.P.S. и нормализацию используйте relaxed/relaxed, меньше проблем будет.

На шлюз провайдера в данном случае пакет не уходит, если у вас единственное подключение и NAT настроен на вашем шлюзе.
Скорей всего происходит следующее - вы отправляете пакет на внешний адрес (шлюз), шлюз NAT'ит его на внутренний адрес сервера, сервер видит что пакет локальный и отвечает напрямую, минуя шлюз, поэтому пакет не NATится обратно и приходит с адреса локального интерфейса. Поскольку адрес ответа отличается от того, на который был послан пакет - ответ реджектится инициатором соединения.
Чтоб такого не было, обычно серверы выносят в отдельную зону (DMZ) которая роутится через шлюз.

Убедитесь что весь контент, который вы используете (картинки, стили, баннеры, внешние скрипты) прописан без указания протоколов, т.е. не src="http://example.com..." а src="//example.com" или по относительным путям. Настройте SSL, потом поднимите прокси и "прокликайте" свой сайт через прокси. Убедитесь по логам прокси, что нет обращений по http:// и что в браузере не вылазит сообщений о небезопасном содержимом.

Попадание в спам не зависит от интенсивности отправляемых писем, зависит от качества писем и правильности оформления. Вот здесь мы собрали технические рекомендации + убедитесь, что вы соблюдаете основные требования к массовым рассылкам.

Работа с аргументами обычно идет через va_start / va_arg / va_end. Но вам все равно надо каким-то образом передавать типы структур, как это делает printf() например, или хранить их описания в каком-то формате и передавать их.

При двойном туннелировании обязательно надо учитывать MTU и понижать MTU на вложенном туннеле. Для TCP проблема MTU более критична, т.к. обычно в TCP ставится флаг don't fragment. Если при этом у вас блокируются пакеты ICMP need frag, то вы получаете классическу проблему black hole.

Отследить маршрут UDP пакета на хост:порт 1.2.3.4:500 можно с помощью команды
traceroute -U -p 500 1.2.3.4

Возможно три варианта:
1. IMAP-сервер создает эти папки во входящих для новых пользователей, тогда надо смотреть конфигурацию IMAP-сервера.
2. IMAP-сервер вообще их не создает по умолчанию и они создаются почтовым клиентом, которым вы первым заходили в этот ящик по IMAP, скорей всего это был Thunderbird, т.к. он создает эти папки по-умолчнию именно как подпапки входящих.
3. IMAP-сервер создает папки, но названия отличают от тех, которые "любит" Thunderbird (например название папки Trash для удаленных). В таком случае Thunderbird так же создаст папки, но помимо них будут еще папки созданные IMAP-сервером с другими названиями.
Исправить это можно через свойства учетной записи (Параметры/Параметры сервера для удаленных и Параметры/Копии и папки для остальных папок). В Outlook есть соответствующая настройка. Mail.Ru подхватывает имеющиеся папки, чтобы применить изменения в папках можно удалить эккаунт через https://account.mail.ru/user/delete и войти по-новой.

Вы hd_src не проверяете, при проблемах с открытием файла будет обращение по нулевому указателю. А функцию read_callback вы определили?

У вас опубликован DKIM-ключ для селектора mail (mail._domainkey) а письмо подписано с селектором dkim (s=dkim в DKIM-Signature). Насколько я понимаю, письмо формировалось вашим сервером и DKIM-подпись добавлял он, а не яндекс. Соответственно, или поправьте селектор в настройках своего почтового сервера с dkim на mail (подойдет только в том случае, если вы используете тот же ключ, что и Яндекс) или опубликуйте публичный ключ, который он использует в записи dkim._domainkey или используйте отправку через SMTP Яндекса с авторизацией, тогда письма будет подписывать он.

*/* в Accept: чаще всего бывает при доступе браузером через прокси и в некоторых случаях - при обновлении страницы в браузере. То есть шанс убить какое-то количество легальных клиентов есть. Лучше поставьте каптчу на регистрацию.
P.S. Pragma: no-cache тоже ставится при запросе через прокси.