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

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

Если кавер-версия пролностью соответствует оригиналу, то вы являетесь исполнителем произведения, а не автором, авторские права остаются у автора произведения (композитора).
Если вы вносите какие-либо изменения, то создаете "производное произведение". Вам будет принадлежать авторское право на арранжировку, но только "при условии соблюдения прав авторов произведений, использованных для создания производного или составного произведения". Создавая арранжировку без согласия автора, вы его права нарушаете.

На практике, авторские отчисления, например за публичное использование, обычно делятся между авторами (композитором, автором текста) и исполнителем, причем исполнитель получает существенно меньше автора.

little endian - после каждого символа ASCII вставить символ с кодом 0. big endian - перед каждым символом ASCII вставить символ с кодом 0.