Нет, почтовый клиент готовит одно письмо и список получателей. Сначала клиент авторизуется (при необходимости) и передает на сервер сведения об отправителе (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
Точно так же, как и при всех остальных нерекурсивных запросах. Если разрешается, например A-запись из дочернего домена — запрос получает сервер родительской зоны и дает в ответе, что у него авторитативной записи нет, но ее можно получить по такому-то адресу (адрес определяется NS-записью). Естественно, что в родительском домене должна быть эта NS-запись. Если требуемая запись есть в самой родительской зоне — то сервер родительской зоны ее отдаст как авторитативную и обращений к дочерней зоне не будет.
аппаратный роутер у топикстартера есть, а судя по тому, какой именно у него есть аппаратный роутер, у него есть еще и виндоусовая ентерпрайз-сеть и нет необходимости поднимать что-то на «этой же семерке», а есть возможность настроить штатный NPS/IAS на Windows Server.
Со стороны пользователя особого геммороя нет, любой аппаратный роутер поддерживает RADIUS-авторизацию, со стороны Windows-сети поднимается NPS, задаются политики и вся авторизация становится прозрачной. Доступ к локальной сети и к требуемым ресурсам можно оставить и без авторизации.
Скорее всего, имелись ввиду политики IPSec, ими можно и нешифрованным трафиком управлять, но они на пользователей не назначаются, только на компьютеры.
