Правильные терминаторы \r\n, но при этом может сам скрипт заменять \n на \r\n, может MTA это делать, это надо учитывать, в результате может быть наоборот лишний \r + убедитесь что в конце текста перевод строки есть. h= в RFC 4870 не обязателен, в RFC 4871 он обязателен, т.к. иначе в бою все будет фейлиться из-за заголовков которые MTA добавляют, например при пересылке.
Ну как минимум у вас нет заголовка h=, поэтому если какие-то заголовки (например Date или Message-ID) добавляется после подписи, сервер некорректно валидирует письмо. Так же nofws выбран только для заголовков, возможно в тексте у вас некорректные терминаторы строк, которые меняются при передаче после подписи.
P.S. резюмируя —
ping -l 1500
можно использовать когда точно не известен MTU на данном компьютере и надо определить нет ли проблемы с blackhole.
ping -l 1472 -f
имеет смысл использовать, когда известно, что MTU на локальной системе равен 1500
ping -l 1500 -f
не будет работать никогда.
Если размер IP пакета больше больше чем MTU то он фрагментируется при отправке, а любой фрагмент уже имеет установленный бит DF. Поскольку 1500 больше чем 1472 (максимальный размер данных ICMP убирающихся в IP-пакет 1500 байт), то этот пинг будет фрагментированными пакетами и как раз таки -f здесь ни на что не влияет.
Единственное, можно было бы упустить ситуацию когда MTU установлен существенно больше дефолтных 1500.
Скорее всего по какой-то другой причине пинги проходили а TCP нет, например на пинги отвечает одна железка с маленьким MTU, а TCP соединения у гугла заворачиваются на другую железку, с бОльшим MTU/MSS.
Нет, почтовый клиент готовит одно письмо и список получателей. Сначала клиент авторизуется (при необходимости) и передает на сервер сведения об отправителе (SMTP-команда MAIL FROM:) и о получателях (SMTP-команда RCPT TO:, дается на каждого получателя письма, т.о. можно указать несколько получателей для одного письма). Далее дается команда DATA и передается письмо вместе со всеми заголовками. То, что вы указываете в To:, Cc: и Bcc: серверу абсолютно все равно, он не разбирает эти заголовки, а производит доставку по адресам указанным в RCPT To. Т.е. с точки зрения SMTP нет никакой разницы в получателях из To CC и BCC, разница исключительно в заголовках. Получатели указываются в поле To, получатели копии в Cc, а получатели слепой копии нигде. Поле Bcc это вспомогательное поле, на удаленный сервер оно не передается, оно нужно, например, чтобы полный список получателей хранить в «отправленных» в почтовой программе или в черновиках.
И таки это похоже на проблемы с MTU. Видно, что MSS 1460, он соответствует MTU 1500 и со стороны гугла не проходят большие пакеты, он тоже анонсирует MSS 1460. MTU устанавливается индивидуально на каждый сетевой интерфейс, понизьте MTU на вайфайном интерфейсе.
Тогда хоть платформу уточните. Еще варианты:
Убедитесь что то, что пингуется по имени гугла по IP адресу это действительно google, проверьте файл hosts
Проверьте route print, нет ли у вас двух маршрутов по-умолчанию (строки начинающиеся с 0.0.0.0 0.0.0.0)
Попробуйте поотключать антивирусную проверку
Убедитесь, что нигде не перекрыт порт 443 (https)
А кабели к компьютерам, надо думать, у вас с потолка свисают?
Если вы хотите наколенных решений — да, можно поставить свитч под столом у бухгалтера, когда его уборщица шваброй заденет — просто придти и проводки воткнуть/подергать. Причем поверьте, это не сарказм, раньше так и делали и у меня такой опыт есть — такие решения реально работали, конторы пахали, доход приносили.
Вот только на определенном уровне развития возникает желание делать правильно — с учетом, удобства сотрудников, без нервотрепки и даже, не дай бог, чтобы не повредить интерьеру. В таком случае разводка по комнате и кабель в любом случае кладутся с учетом потенциального числа рабочих мест в комнате, а не из рассчета сколько сотрудников сейчас и сколько возьмем до осени.
«Свитч с бесперебойником — роскош» — даже не знаю что и возразить. Сервер с бэкапом — тоже.
Кабель это разовые затраты, которые размазваются на много лет. Причем, как правило, КС прокладывается одновременно с ремонтом и на его фоне они практически незаметны. Чтобы разместить как следует свитч в комнате без бахромы из проводов, надо в каждой комнате поставить/повесить шкаф и в него купить UPS. Посчитайте — получается по деньгам примерно то же самое. Но этот шкаф еще и место в комнате занимает, пусть даже и немного, посчитайте стоимость арендной платы за несколько лет. И да, гораздо удобней коммутировать когда все все рядом.
Почитать — даже не знаю что посоветовать, почитайте материалы по линейкам свичей у нескольких производителей, у них подходы разные, но суть примерно одна.
Даже если компьютер оформлен как россыпь запчастей, все равно есть гарантия на материнскую плату. Надо менять/ремонтировать ее. Если магазин отказывается обменивать по гарантии, то уже в роспотребнадзор.
А, простите, наверное не совсем понял вопрос. Вас интересует как subdomain2.example.com разрешится в IP? Если для него авторитативным сервером является тот же самый сервер — то он выдаст в DNS-ответе A-запись subdomain2.example.com как авторитативную. Если не является — то все равно можно прописать запись для subdomain2.example.com и она будет выдана как неавторитативная. Если записи не будет или резолвер слишком паронаидален чтобы ей поверить — то резолвер отдельно самостоятельно разрешит subdomain2.example.com в IP. Если у subdomain2.example.com не меняется IP адрес и он Вам известен, то можно в родительской зоне прописать
subdomain2 IN NS ns.subdomain2.
ns.subdomain2 IN A 17.17.17.17
