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

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-парта, а не у мультипарта.

Статистика постмастера строится не по письмам которые отправил пользователь Google, а по письмам домена отправленным на гугловые ящики. При этом у гугла есть дополнительные требования по количеству писем при которых статистика начинает показываться. Важно при этом не сколько писем вы отправляете, а сколько писем вы отправляете получателям на GMail. Так же, в статистику обычно засчитываются только письма авторизованные DKIM, убедитесь что он есть в ваших письмах.

#если нужна персистентность между запусками, у 3proxy должны быть права на доступ к файлу
counter /путь/к/файлу/счетчиков
#countall поддерживается в 0.9.3, это если надо считать весь трафик. В более старых только countin/countout
#Можно считать отдельно входящий и исходящий через countin/countout. 
#Трафика надо давать на 10-15% меньше, чем провайдер, т.к. провайдер считает сетевой или даже канальный трафик, а прокси считает прикладной
# 15 мегабайт в день
countall 1 D 15
# 250 мегабайт в месяц
countall 2 M 250