Проблема, похоже, заключается в том, что MS Outlook 2007 не отправляет SMTP AUTH по какой-то странной причине только для одного конкретного домена.
Я запускаю сервер iRedMail (он использует стандартный debian 7 / wheezy, postfix 2.9.6-2) для своего домена и нескольких десятков клиентских доменов. Проблема в том, что у меня есть клиент, который не может отправить мне письмо (не только мой адрес электронной почты, но и весь домен) - он отклоняется из-за reject_non_fqdn_helo_hostname
но клиент использует SMTP AUTH и правильно настроил его, поэтому он должен обойти проверку FQDN. Похоже, что MUA не использует SMTP AUTH только для моих адресов электронной почты и моих coleaques.
Кто-нибудь видел это раньше? Как я могу обойти эту проблему? Любой вклад приветствуется!
Может быть, это связано с MUA? Она пользуется Outlook (не Express)?
Взгляните на следующие фрагменты журналов, показывающие различные ситуации. Все было поймано в одной конфигурации / тех же MUA / IP, ...:
1) это нормально: мой клиент отправляет электронное письмо на сторонний сервер; с использованием SMTP AUTH
May 28 13:02:13 email2 postfix/smtpd[1191]: connect from <censored> May 28 13:02:13 email2 postfix/smtpd[1191]: 28A5D35E61DC: client=<censored>, sasl_method=LOGIN, sasl_username=<client1@1.example.com> May 28 13:02:26 email2 postfix/cleanup[1435]: 28A5D35E61DC: message-id=<006c01ce5b92$d33805e0$79a811a0$@cz> May 28 13:02:44 email2 postfix/qmgr[376]: 28A5D35E61DC: from=<client1@1.example.com>, size=4392922, nrcpt=7 (queue active) May 28 13:02:44 email2 postfix/smtp[1580]: 28A5D35E61DC: to=<someone@thirdparty.example.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=32, delays=31/0/0/0.88, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as B061435E61DE) May 28 13:02:47 email2 postfix/qmgr[376]: 28A5D35E61DC: removed
2) это нормально: мой клиент отправляет электронное письмо на локальную учетную запись (hers coleque); она использует SMTP AUTH
May 28 13:06:18 email2 postfix/smtpd[2519]: connect from <censored> May 28 13:06:18 email2 postfix/smtpd[2519]: 49CE735E61D4: client=<censored>, sasl_method=LOGIN, sasl_username=<client1@1.example.com> May 28 13:06:18 email2 postfix/cleanup[429]: 49CE735E61D4: message-id=<007201ce5b93$5df069c0$19d13d40$@cz> May 28 13:06:19 email2 postfix/qmgr[376]: 49CE735E61D4: from=<client1@1.example.com>, size=10875, nrcpt=1 (queue active) May 28 13:06:19 email2 postfix/smtp[2295]: 49CE735E61D4: to=<client2@1.example.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=1.6, delays=1.2/0/0/0.43, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as CC61F35E61D7) May 28 13:06:19 email2 postfix/qmgr[376]: 49CE735E61D4: removed
3) проблема, электронная почта отправлена на мою учетную запись (тот же сервер, но другой домен), НЕ с использованием SMTP AUTH ???:
May 28 13:04:38 email2 postfix/smtpd[1433]: connect from <censored> May 28 13:04:38 email2 postfix/smtpd[1433]: NOQUEUE: reject: RCPT from <censored>: 554 5.7.1 <my_email>>: Recipient address rejected: Invalid HELO/EHLO; Must be a FQDN or an address literal, not 'xxx'; from=<client1@1.example.com> to=<my_address> proto=ESMTP helo= May 28 13:04:41 email2 postfix/smtpd[1433]: disconnect from <censored>
Часть конфигурации постфикса:
smtpd_sender_restrictions = permit_mynetworks, reject_authenticated_sender_login_mismatch, permit_sasl_authenticated smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unlisted_recipient, check_policy_service inet:127.0.0.1:7777, check_policy_service inet:127.0.0.1:10031, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, check_helo_access pcre:/etc/postfix/helo_access.pcre
См. Вывод postconf и кошка main.cfg
Проблема была в policyd (cluebringer) ... это не было видно из журнала на первый взгляд, это отклонение было не из-за ограничения постфикса, а из policyd.
Задний план
В группе cluebringers internal_domains был только мой основной домен (после установки), а всех новых доменов там не было ... Чтобы решить проблему, я решил очистить internal_domains, и теперь все работает, как ожидалось.
Спасибо тебе за помощь!
Ваш smtpd_recipient_restrictions
нормальны при условии, что все ваши клиенты хорошо себя ведут. Поскольку они не отправляют (не отправляют правильный HELO), у вас должно быть хотя бы что-то вроде
smtpd_recipient_restrictions = reject_unknown_sender_domain,
reject_unknown_recipient_domain,
permit_sasl_authenticated,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unlisted_recipient,
check_policy_service inet:127.0.0.1:7777,
check_policy_service inet:127.0.0.1:10031,
permit_mynetworks,
reject_unauth_destination
Даже лучше:
smtpd_recipient_restrictions =
check_recipient_access hash:/etc/postfix/access-recipient-rfc,
check_client_access cidr:/etc/postfix/access-client,
check_helo_access hash:/etc/postfix/access-helo,
check_sender_access hash:/etc/postfix/access-sender,
check_recipient_access hash:/etc/postfix/access-recipient,
permit_mynetworks,
permit_sasl_authenticated,
reject_unknown_sender_domain,
reject_non_fqdn_sender,
reject_unknown_recipient_domain,
reject_non_fqdn_recipient,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client ix.dnsbl.manitu.net,
# greylisting
check_policy_service inet:127.0.0.1:10023,
# policyd-weight
check_policy_service inet:127.0.0.1:12525,
reject_unauth_destination,
reject_unverified_recipient,
permit
Кроме того, вы должны интегрировать все ограничения в smtpd_recipient_restrictions
. поскольку HELO идет после аутентификации SASL, его бесполезно разрешать аутентификацию SASL в smtpd_helo_restrictions
.
В целом рекомендуется использовать только smtpd_recipient_restrictions
, поскольку вы можете делать там все, что вам нужно, это избавляет вас от повторяющихся вещей, и накладные расходы на сеть, связанные с подключениями, которые были бы прерваны после этого, незначительны.
HELO / EHLO случается перед аутентификация SMTP. Если ваш сервер настроен с reject_non_fqdn_helo_hostname = yes
, он отклонит любое соединение с недопустимым именем хоста перед переходя к части SMTP AUTH.
Сохранение этого отказа снизит количество спама, но также заблокирует ряд законных писем. Вам следует внимательно изучить документацию Postfix для reject_invalid_helo_hostname и smtp_helo_restrictions чтобы выяснить, как вы хотите, чтобы это работало.