[Postfixbuch-users] Mails in Queue statt "Relay Access Denied"

[Ralf Hildebrandt]

* Hubertus Wegener <hubertus.wegener at rp-online.de>:

> Wenn ich es richtig verstanden habe, lässt sich das Ganze eindampfen auf:

Jo, viel lesbarer

> smtpd_client_restrictions =
> smtpd_helo_restrictions =
> smtpd_sender__restrictions =
> 
> smtpd_recipient_restrictions =
>  reject_unauth_pipelining,
>  reject_unknown_sender_domain,
>  reject_unknown_recipient_domain,
>  reject_non_fqdn_sender,
>  check_client_access hash:/etc/postfix/access,
>  check_sender_access regexp:/etc/postfix/sender_access,
>  check_recipient_access regexp:/etc/postfix/recipient_checks,
>  permit_mynetworks,
>  permit_sasl_authenticated,
>  check_client_access mysql:/etc/postfix/relay-ip.cf,
>  reject_maps_rbl,
>  permit_mx_backup,
>  reject_unauth_destination,
>  reject

Besser:

permit_mynetworks
check_client_access mysql:/etc/postfix/relay-ip.cf
permit_sasl_authenticated
permit_mx_backup
reject_unauth_destination
reject_maps_rbl
permit

Evtl. haut dir permit_mx_backup das Loch rein!

> Da weder die IP noch der envelope-recipient @prodigy.com freigeschaltet 
> war/ist, stellt sich mir die Frage, ob der seltsame prodigy.com-MXer 
> 127.0.0.1.prodigy.com (laut DNS) hier einen Fehler verursacht hat, so dass 
> die Mail in die Queue gelangen konnte.

Das könnte sein (permit_mx_backup?)

-- 
Ralf Hildebrandt (i.A. des IT-Zentrum)          Ralf.Hildebrandt at charite.de
Charite - Universitätsmedizin Berlin            Tel.  +49 (0)30-450 570-155
Gemeinsame Einrichtung von FU- und HU-Berlin    Fax.  +49 (0)30-450 570-962
IT-Zentrum Standort CBF                 send no mail to spamtrap at charite.de