ChymeNik: про Windows не уверен как именно работает нулевой лингер, но точно могу сказать что коннекты в time-wait / fin-wait там ни к каким негативным последствиям, типа невозможности рестартануть сервис и слушать тот же порт, не приводят.
Если у вас BSD, то, скорей всего, это не лечится, чтобы избежать проблем при повторном запуске демона/открытии порта используйте SO_REUSEADDR / SO_REUSEPORT. Если Linux, то это странно, потому что при нулевом лингере по идее должен идти RESET, а не закрытие сокета через FIN. Попробуйте устанавливать лингер при создании сокета. Возможно вы пропустили какие-то ситуации закрытия сокета, например когда закрытие соединения инициируется другой стороной.
+ если у вас протокол с долго живущими соединениями, которые могут подолгу простаивать без передачи данных, не забывайте использовать SO_KEEPALIVE, иначе клиенты за NAT'ом могут отваливаться втихую, что и приводит к многочисленным fin-wait'ам.
Eddik: нет, ничего не могу сказать. Но в целом, чем больше уровней вы накрутите - тем меньше будет выигрыш, т.к. фактически придете к тому же самому функционалу, что реализован в ядре и вряд ли он будет сильно быстрей работать. Если поверх юзерспейс-стека вы поднимете, например, интерфейс для быстрого сетевого аналога мемкеша - то есть шанс, что-то выиграете. А если накрутите веб-сервер со скриптами - то вряд ли заметите разницу. Возможно вам надо смотреть не в сторону kernel bypass, а наоборот унести что-то в ядро, например через sendfile() / splice().
Василий Печерский: вот пример конфигурации нескольких пулов адресов с модулем rlm_ippool wiki.freeradius.org/modules/Rlm_ippool
там же в комментарии сверху пример что в каком файле прописать, чтобы одной группе пользователей назначались адреса из одного пула, а другой из другого.
Аналогичная проблема так же может быть с черновиками, проверьте что черновики настроены правильны и что яндекс не собирает черновики во входящие. Если собирает - можно отключить хранение копии черновика в IMAP-папке.
Tian: попробуйте на mail.ru или gmail, они покажут причину фейла. Убедитесь, что DKIM-ключ опубликован как _domainkey.site.site.com (с селектором из s=), проверьте все, о чем говорилось ранее, и еще вы используете нормализацию simple для тела письма, при ней важны переводы строк, проверьте что используете правильные переводе (CR+LF) и они не трансформирутся в процессе передачи или поправьте нормализацию на relaxed/relaxed.
Mail.Ru формирует сообщение на основе стандарта DMARC (RFC 7489) с использованием технологий авторизации SPF (RFC 7208) и DKIM (RFC 6376) и сообщает о невозможности проверки отправителя, если авторизация отсутствует или не совпадает с доменом отправителя. Использование открытого стандарта прозрачно для всех сторон.
GMail формирует сообщение на основе принадлежности DKIM-подписи.
Оба сообщения, и GMail и Mail.Ru являются правильными и не противоречат друг другу. Гугл информирует о том, что письмо было отправлено через Яндекс, а не через Mail.Ru не делая выводов о возможности подделки отправителя. Мы информируем о том, что не можем проверить авторство письма и отправитель мог быть подделан, что справедливо при отправке письма от пользователя mail.ru через Яндекс. Здесь www.slideshare.net/phdays/ss-35165366 презентация с конференции PHDays с демонстрацией возможностей подделки отправителя при подобных проверках.
Азат Ваджипов: я в этих файлах русского текста не наблюдаю. Если ты текст берешь из базы, то убедись, что кодировка текста в базе тоже выбрана как utf-8 и текст в базе лежит как utf-8.
И, в данном случае это не влияет, но Header имеет смысл добавлять до того, как ты документ отдавать начал, перенеси установку локали и добавление хидеров в начало файла.
Азат Ваджипов: А можешь куда-нибудь выложить файл в архиве, например?
UTF CastExpress скорей всего неправильно определил кодировку исходного файла, например спутал cp866 и mac-cyr.
