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

Сервисы работы с отчетами - https://agari.com, https://dmarcian.com, https://ondmarc.redsift.com/

Рассчитывать на forensic-репорты не стоит, крупные почтовые сервисы их обычно не шлют, надо смотреть в аггрегированные.

quarantine я бы не рекомендовал использовать, тем более с процентом отличным от 0 и 100. Лучше использовать reject сначала с нулевым а потом с маленьким процентом, постепенно его наращивая - например 0-1-5-20-100 и следить за логами. Если письмо у какого-то получателя попадает в спам - вы ничего не можете с этим сделать и даже не будете знать у кого именно. В случае reject вы увидете недоставки (за ними обязательно надо следить и лучше в реальном времени) и сможете переотправить недоставленные письма, устранив проблемы.

https://en.wikipedia.org/wiki/IEEE_802.11w

Устройства с поддержкой 802.11ac должны поддерживать 802.11w

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

Основная проблема паролей не в длине, а в том что пользователи пароли генерируют не случайно (т.к. не умеют использовать парольные менеджеры), переиспользуют, плохо хранят и ведутся на фишинг. При таких проблемах их длина практического значения не имеет, и по факту практически никогда не встречается брутов на которткие пароли, встречаются бруты на словарные, пароли с пользовательскими данными и стаффинг паролей с других сервисов, просто среди коротких гораздо больше словарных, пароль длиной 7 символов и меньше с высокой вероятностью будет словарным, даже если он случайно сгенерирован, случайный уникальный пароль 10+ символов практически никогда не будет взломан по сети, даже если в нем только маленькие буквы, т.е. в нем менее 50 бит энтропии.

Если вы хотите защищаться от офлайнового брута (например речь идет про сид коршелька) - то вот тут уже надо учитывать и вычислительные мощности тех, кто может ваш кошелек атаковать и запас на будущее и потенциально квантовую криптографию. Допустимая битность в таком случае будет зависеть от используемых алгоритмов, мощностей атакующего и допустимого уровня риска (например вы можете взять достимый уровень как вероятность взломать за год на вычислителе с 1 Петафлопсом 0.001% и исходя из алгоритма посчитать необходимое количество бит энтропии)

1. support@питер.рус будет работать практически везде (но где-то может показываться punycode-адрес домена) при условии что при отправке домен корректно кодируется в punycode, могут быть проблемы с написанием на этот адрес у пользователей старых почтовых программ. поддержка@питер.рус будет работать только если все почтовые серверы и клиенты между отправителем и получателям поддерживают RFC6531/RFC6532, на практике такие адреса не используются и их не будут использовать в обозримом будущем, т.к. мгновенный переход всего интернета на UTF-8 невозможен, а что делать если респондент не поддерживает UTF-8 не понятно (аналога punycode для local-part нет). А вот использовать для почты домен питер.com я бы не рекомендовал, т.к. в таком домене используется mixed script и он не проходит по требованиям безопасности Unicode (aka TR39).
2. По RFC 952/1035 имя хоста начинается с буквы и заканчивается буквой или цифрой, внутри могут быть цифры, буквы и -. RFC 1123 дополнительно разрешает начинать имя с цифры. Но технически протокол DNS поддерживает любые символы, даже 8-битные и в браузерах могут открываться даже не соответствующие стандарту имена. Но, разумеется, правильней ориентироваться на стандарт.
3,4,5,6. С local-part все интересно, ситуация обратная. По стандарту там может быть практически все что угодно, но внутри строки в двойных кавычках (quoted-string). По факту адреса c quoted-string не используются и обычно не принимаются. Без quoted string так же очень много чего разрешено, могут быть любые цифры, буквы, символы "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" в любой последовательности так же разрешен символ "." Поэтому все ваши адреса допустимы. НО нельзя начинать и заканчивать local-part точкой и использовать две точки подряд (это в некотором роде баг стандарта RFC 2821/2822 и более поздних связанный с формализованной записью, который достаточно поздно заметили, стандарт RFC 821/822 разрешал две точки подряд). На практике использовать любые "странные" адреса относительно которых есть сомнения я бы не рекомендовал, т.к. не все, что разрешено стандартом по факту всеми принимается.

1. В read наверняка надо передавать buf а не &buf (точно сказать нельзя т.к. описания нет)
2. В зависимости от того, как вы запускаете процесс, дочерний процесс может получить SIGHUP при закрытии родительского процесса или SIGPIPE на printf, стоит добавить обработчики сигналов до fork().

Не уверен, что можно mail() использовать таким образом, но как минимум: у вас нет пустой строки после заголовков и в основном парте и в обоих текстовых. Разделитель строк должен быть CRLF, \n\r дает скорей всего LFCR или CRLFCR. И это в данному случае не влияет, но charset надо указывать у text-парта, а не у мультипарта.