Postfix, похоже, игнорирует записи MX домена

Postfix, похоже, игнорирует записи MX домена

На моем выделенном сервере у меня установлен Postfix для отправки почты через веб-сайты. Один из моих клиентов размещает свою почту у третьей стороны, поэтому у нас есть записи MX, настроенные на домене.

Однако при отправке любых писем Postfix с сервера они не получают письма. Я думаю, поскольку домен указывает на сам сервер, он пытается отправить почту самому себе, но на сервере нет ничего, чтобы обработать почту для этого домена. (Есть почтовые учетные записи для другого домена, которые работают нормально.)

Как заставить Postfix использовать MX-записи домена для отправки электронной почты?Сервер — Ubuntu 8.10 со стандартным стеком LAMP. У меня установлен Webmin и панель управления «Matrix», предоставленная хостером.

РЕДАКТИРОВАТЬ: если я пытаюсь отправить электронное письмо со своего собственного адреса, я получаю сообщение об ошибке от почтовой системы доставки со следующей ошибкой:

<[email protected]>: user unknown. Command output: Invalid user specified.

Final-Recipient: rfc822; [email protected]
Action: failed
Status: 5.1.1
Diagnostic-Code: x-unix; Invalid user specified.

Вот записи в журнале:

Jan  6 18:06:52 localhost postfix/pickup[29006]: 0329D3F69: uid=33 from=<[email protected]>
Jan  6 18:06:52 localhost postfix/cleanup[30495]: 0329D3F69: message-id=<[email protected]>
Jan  6 18:06:52 localhost postfix/qmgr[22461]: 0329D3F69: from=<[email protected]>, size=611, nrcpt=2 (queue active)
Jan  6 18:06:52 localhost postfix/pipe[30497]: 0329D3F69: to=<[email protected]>, relay=maildrop, delay=0.15, delays=0.1/0/0/0.04, dsn=5.1.1, status=bounced (user unknown. Command output: Invalid user specified. )
Jan  6 18:06:52 localhost postfix/smtp[30498]: 0329D3F69: to=<[email protected]>, relay=gmail-smtp-in.l.google.com[209.85.227.27]:25, delay=0.61, delays=0.1/0.01/0.06/0.45, dsn=2.0.0, status=sent (250 2.0.0 OK 1294337212 o18si30528441wbo.103)
Jan  6 18:06:52 localhost postfix/cleanup[30495]: 868723F75: message-id=<[email protected]>
Jan  6 18:06:52 localhost postfix/bounce[30500]: 0329D3F69: sender non-delivery notification: 868723F75
Jan  6 18:06:52 localhost postfix/qmgr[22461]: 868723F75: from=<>, size=2553, nrcpt=1 (queue active)
Jan  6 18:06:52 localhost postfix/qmgr[22461]: 0329D3F69: removed
Jan  6 18:06:52 localhost postfix/pipe[30497]: 868723F75: to=<[email protected]>, relay=maildrop, delay=0.06, delays=0.01/0/0/0.05, dsn=2.0.0, status=sent (delivered via maildrop service)
Jan  6 18:06:52 localhost postfix/qmgr[22461]: 868723F75: removed

решение1

Так вот, мне скучно на работе, и я подумал, что стоит сказать следующее. Я никогда раньше не пользовался этим сайтом, так что извините меня.

В одном из ответов вы прокомментировали следующее:

«Хорошо, у меня virtual_mailbox_domains = $transport_maps и transport_maps = hash:/etc/postfix/transport. Внутри этого файла есть строка, которая гласит condorproperties.co.uk maildrop: - мне удалить эту строку? – DisgruntledGoat вчера»

а затем добавил:

«@Devdas: Я пробовал удалить эту строку и перезапустить Postfix, но это не решило проблему. Нужно ли мне изменить «maildrop» на что-то другое? – DisgruntledGoat вчера»

Ответ на ваш первый вопрос: "да". Эта строка в /etc/postfix/transport принудительно запускала локальную доставку почты (через maildrop) для писем, предназначенных для condorproperties.co.uk. Удаление ее является наиболее подходящим решением. Проблема в том, что простого перезапуска postfix недостаточно для применения изменения.

Проблема в том, что карта, настроенная в файле конфигурации, представляет собой хэш: /etc/postfix/transport. Файл /etc/postfix/transport является версией файла, понятной человеку, и должен иметь соответствующий файл /etc/postfix/transport.db - скомпилированный хэш-файл. Вы используете команду postmap для компиляции версии, понятной человеку, в хэшированную версию. Postfix проверяет время модификации и должен громко жаловаться в ваших файлах журналов, что /etc/postfix/transport.db устарел. Все, что вам нужно сделать, это запустить postmap /etc/postfix/transport, чтобы внесенные вами ранее изменения (удаление строки с condorproperties.co.uk) вступили в силу. На самом деле, я не думаю, что вам даже нужно перезагружать postfix, чтобы изменения вступили в силу после того, как вы ввели команду postmap, но это не повредит.

Короче говоря, запустите postmap /etc/postfix/transport, а затем перезагрузите postfix.

Ваше здоровье.

Кстати, важной подсказкой в ​​ваших лог-файлах была эта строка: 6 января 18:06:52 localhost postfix/pipe[30497]: 0329D3F69: to=, relay=maildrop, delay=0.15, delays=0.1/0/0/0.04, dsn=5.1.1, status=bounced (пользователь неизвестен. Вывод команды: указан неверный пользователь.)

обратите внимание, где-то в середине написано relay=maildrop?

решение2

Можете ли вы вставить сюда postconf -n?

Держу пари, что у вас mydomain.co.uk явно указан в одном из mydestination, virtual_mailbox_domains или relay_domains с транспортом maildrop.

У ring0 идея правильная, но он неправильно проанализировал вопрос, насколько я понимаю. Цель — заставить почту для одного из доменов на сервере переходить куда-то еще, но она остается с Postfix.

Любой почтовый сервер будет иметь локальную конфигурацию, переопределяющую DNS. Так что если ваш MTA не смотрит на DNS, у вас есть домен в локальной конфигурации.

решение3

postfixследует стандартам и выполняет разрешение записей MX доменного имени, чтобы узнать, к какому серверу следует обращаться далее для передачи почты.

  • У вас может возникнуть проблема из-за TTL доменного имени (зоны), например, вы обновили записи MX у своего регистратора, но TTL этого домена заставляет ранее разрешенную запись оставаться в кэше сервера доменных имен.

  • Кроме того, доменные имена на целевом сервере не могут быть объявлены какместный, заставляя сервер отклонять почту (см. журналы, например /var/log/mail.log), считая, что ваш отправляющий сервер пытается ретранслировать (спам) через этот целевой сервер ( mydestinationв /etc/postfix/main.cf).

Постарайтесь dig +nocmd mydomain.tld mx +noall +answerполучить легко читаемую информацию, включая TTL, по интересующим вас доменам.

решение4

Также проверьте, что у вас нет каких-либо пользовательских транспортов или транспортных карт, каким-либо образом определенных для удаленного домена, на который вы собираетесь отправлять почту.

Связанный контент