Назад | Перейти на главную страницу

Postfix отклоняет всю входящую почту (клиентский хост отклонен: доступ запрещен)

Я установил рабочий постфиксный сервер, за исключением того, что вся входящая почта отклоняется.

Когда я пытаюсь отправить почту через telnet:

MAIL FROM: <tom@valid.domain.com>
250 2.1.0 Ok
RCPT TO: <tom@mydomain.com>
554 5.7.1 <my.host.name[1.2.3.4]>: Client host rejected: Access denied

Мой postconf -n

alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = no
config_directory = /etc/postfix
delay_warning_time = 4h
inet_interfaces = all
mailbox_size_limit = 0
masquerade_domains = mail.mydomain.com www.mydomain.com
maximal_backoff_time = 8000s
maximal_queue_lifetime = 7d
minimal_backoff_time = 1000s
mydestination = 
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin = techxonline.net
readme_directory = no
recipient_delimiter = +
relayhost = 
smtp_helo_timeout = 60s
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_client_restrictions = reject_rbl_client sbl.spamhaus.org,         reject_rbl_client blackholes.easynet.nl,        reject_rbl_client dnsbl.njabl.org
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_hard_error_limit = 12
smtpd_helo_restrictions = permit_mynetworks, warn_if_reject reject_non_fqdn_hostname,       reject_invalid_hostname, permit
smtpd_recipient_limit = 16
smtpd_recipient_restrictions = reject_unauth_pipelining, permit_mynetworks,         permit_sasl_authenticated, reject_non_fqdn_recipient, reject_unknown_recipient_domain,      reject_unauth_destination, check_policy_service inet:127.0.0.1:10023, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = 
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks,       warn_if_reject reject_non_fqdn_sender, reject_unknown_sender_domain,        reject_unauth_pipelining, permit
smtpd_soft_error_limit = 3
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
unknown_local_recipient_reject_code = 450
virtual_alias_maps = mysql:/etc/postfix/mysql_alias.cf
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/spool/mail/virtual
virtual_mailbox_domains = mysql:/etc/postfix/mysql_domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql_mailbox.cf
virtual_uid_maps = static:5000

В /var/log/syslog после отправки из Gmail:

Oct 18 21:30:01 appman postfix/smtpd[25307]: connect from mail-gx0-f181.google.com[209.85.161.181]
Oct 18 21:30:01 appman postfix/smtpd[25307]: NOQUEUE: reject: RCPT from mail-gx0-f181.google.com[209.85.161.181]: 554 5.7.1 <mail-gx0-f181.google.com[209.85.161.181]>: Client host rejected: Access denied; from=<tom@valid.domain.com> to=<tom@mydomain.com> proto=ESMTP helo=<mail-gx0-f181.google.com>
Oct 18 21:30:01 appman postfix/smtpd[25307]: disconnect from mail-gx0-f181.google.com[209.85.161.181]

Как я могу заставить мой почтовый сервер принимать почту? Если я могу предоставить какую-либо другую информацию, пожалуйста, дайте мне знать.

EDIT: похоже, что сервер требует аутентификации для получения почты здесь. Кажется, что это не ограничено хостом - использование telnet с самого сервера по-прежнему приводит к отклонению почты. Аутентификация с помощью SASL и последующая отправка электронной почты работают нормально.

Итак, похоже, проблема в том, что сервер ожидает аутентификации для почты, которая будет доставлена ​​в конечный пункт назначения, чего не должно быть. Идеи?

Думаю тебе нужно поставить mydestination = mydomain.com в вашем конфиге.


Следующее предположение: мы знаем, что домен правильный и что SASL работает ... так что теперь я подозреваю, что мы видим ошибку в ваших ограничениях. Я бы начал с recipient_restrictions и удалил все отклонения после разрешения_sasl_authenticated. Если это сработает, добавляйте их по одному. Если нет, ваш следующий тест - sender_restrictions.

Сначала удалите механизм делегирования политики check_policy_service inet:127.0.0.1:10023. Затем попробуйте еще раз. Скорее всего, это блокирует вашу доставку.