У нашей компании было 4 домена, чьи почта и DNS размещались на usintegration.com, а затем мы перенесли почта и хостинг DNS для 3 из 4 доменов в новую компанию. Теперь, 3 домена, которые были перемещеныне могу отправлять и получать электронные письма с единственного домена, который все еще остался на старом сервере. Все остальные функции электронной почты работают нормально для всех 4 доменов. Нет никаких возвратов, сообщений об ошибках или писем, застрявших в очереди, и нет никаких доказательств того, что эти отсутствующие письма попали на новые серверы.
Новая хостинговая компания (logixcom.com) подтверждает, что с их стороны все в порядке, и уверяет меня, что, скорее всего, это старый файл зоны, все еще остающийся на сервере имен US Integration, и поэтому электронные письма, отправленные из US Integration, направляются на то, что она считает все еще авторитетным сервером имен (его собственный). Поскольку записи MX старого файла зоны все еще содержат старый ресурс, запросы никогда не покидают старый сервер имен, чтобы выйти в сеть и выполнить новый поиск настоящего (нового) авторитетного сервера имен. Усугубляет проблему то, что US Integration не может определить проблему, не говоря уже о том, чтобы исправить ее.
Действительно ли проблема в том, что этот старый файл зоны нужно просто удалить с сервера имен US Integration? Если да, то как мне лучше всего это им описать? Если нет, то в чем, по-вашему, может быть проблема? Любая помощь будет высоко оценена. Я не работаю в сфере ИТ, поэтому все это для меня в новинку. Я знаю, что мне (клиенту) кажется странным заниматься этой беготней, но я просто хочу решить эту проблему.
Вот что я сделал:
Запустил dig, чтобы убедиться, что записи MX US Integration по-прежнему указывают на старый авторитетный сервер имен, вместо того чтобы выйти в Интернет и выполнить новый поиск:
~$ dig @bart.usintegration.com courycollection.com mx ; <<>> DiG 9.6.0-APPLE-P2 <<>> @bart.usintegration.com courycollection.com mx ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61227 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;courycollection.com. IN MX ;; ANSWER SECTION: courycollection.com. 3600 IN MX 10 mail.usintegration.com. ;; ADDITIONAL SECTION: mail.usintegration.com. 3600 IN A 65.198.191.5 ;; Query time: 29 msec ;; SERVER: 65.198.191.5#53(65.198.191.5) ;; WHEN: Sun Dec 26 16:59:22 2010 ;; MSG SIZE rcvd: 88Запустил dig, чтобы попытаться узнать, куда смотрят серверы Logix при отправке писем с трех перенесенных доменов, и получил отказ:
~$ dig @faith.logixcom.net.net colcordhotel.com mx ; <<>> DiG 9.6.0-APPLE-P2 <<>> @faith.logixcom.net colcordhotel.com mx ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 31599 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;colcordhotel.com. IN MX ;; Query time: 31 msec ;; SERVER: 216.201.128.10#53(216.201.128.10) ;; WHEN: Sun Dec 26 17:00:14 2010 ;; MSG SIZE rcvd: 34
ОБНОВЛЕНИЕ 28.12.10:US Integration заявили, что удалили файлы зоны, и последующее копание показало, что их резолверы теперь указывают на правильный сервер имен Logix, но проблемы остались. Забавно, что владелец US Integration (у которого есть адрес электронной почты @usintegration.com) может обмениваться электронными письмами со мной (у которого есть адрес электронной почты @courycollection.com), но наш родственный объект (colcordhotel.com, размещенный US Integration) по-прежнему не может отправлять нам сообщения.
решение1
Старые домены были полностью удалены со старого почтового сервера? Во многих почтовых серверах, если домен определен как имя, обслуживаемое этим сервером, он даже не будет обращаться к DNS, чтобы узнать, куда следует доставлять почту (поскольку он уже размещает этот домен, нет необходимости его искать). Почта с old-domain.com на other-domains.com будет просто доставляться локально, если они все еще настроены на почтовом сервере, независимо от того, что DNS говорит с ней делать.
Что касается входящей почты, это тоже может быть связано. Если принимающий сервер видит почту, приходящую из Интернета на домены, которые должны быть локальными (т. е. входящие SMTP без какой-либо аутентификации или с известного диапазона IP-адресов), то он может рассматривать их как подозрительные и фильтровать как спам.
Подобные вещи также легче диагностировать, когда используются реальные домены. Примеры доменов хороши для теоретических или общих проблем, но конкретика работает гораздо лучше для конкретных проблем.