Postfix und permanente Rejects

[Thomas Schwenski]

Hallo Patrick,

 > Schön, dass Du es mir nicht krumm genommen hast.

Wieso sollte ich?
Der Einwand war von Deinem Standpunkt aus berechtigt und ihn 
anzubringen, war für Dich ein Ventil um mal was rauszulassen heute.
(Und es hat sich ja dadurch dann nicht aufstauen können, sondern den 
richtigen erwischt.)


 > Mail, die Dein SMTP-Server (in der Rolle als Client) versenden soll,
 > wird permanent abgewiesen. Die Standard-Reaktion *jedes* SMTP-Servers 
 > müsste daraufhin bounce ein sein. Der SMTP-Server muss die Nachricht
 > an den Absender rückabwickeln und ihn/sie dabei informieren, dass die 
 > Nachricht nicht zustellbar war.

Das war mein Gedanke und Grundlage meiner Verwunderung

 > Vielleicht in master.cf? Hast Du besondere Settings für den
 > smtp-Service in der master.cf? Kannst ja mal "postconf -M" posten,
 > damit wir das auch ansehen können.


postconf -m (gleich wieder was gelernt):

smtp       inet  n       -       n       -       -       smtpd
dnsblog    unix  -       -       n       -       0       dnsblog
tlsproxy   unix  -       -       n       -       0       tlsproxy
submission inet  n       -       n       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_type=dovecot
  -o smtpd_sasl_path=private/auth
  -o smtpd_sasl_security_options=noanonymous
  -o 
smtpd_relay_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_mynetworks,permit_sasl_authenticated,reject
  -o smtpd_sender_login_maps=mysql:/etc/postfix/mysql/sender-login-maps
  -o 
smtpd_sender_restrictions=permit_mynetworks,reject_non_fqdn_sender,reject_sender_login_mismatch,permit_sasl_authenticated,reject
  -o 
smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
  -o smtpd_helo_required=no
  -o smtpd_helo_restrictions=
  -o smtpd_recipient_restrictions=
  -o milter_macro_daemon_name=ORIGINATING
pickup     unix  n       -       n       60      1       pickup
cleanup    unix  n       -       n       -       0       cleanup
qmgr       unix  n       -       n       300     1       qmgr
tlsmgr     unix  -       -       n       1000?   1       tlsmgr
rewrite    unix  -       -       n       -       -       trivial-rewrite
bounce     unix  -       -       n       -       0       bounce
defer      unix  -       -       n       -       0       bounce
trace      unix  -       -       n       -       0       bounce
verify     unix  -       -       n       -       1       verify
flush      unix  n       -       n       1000?   0       flush
proxymap   unix  -       -       n       -       -       proxymap
proxywrite unix  -       -       n       -       1       proxymap
smtp       unix  -       -       n       -       -       smtp
relay      unix  -       -       n       -       -       smtp
showq      unix  n       -       n       -       -       showq
error      unix  -       -       n       -       -       error
retry      unix  -       -       n       -       -       error
discard    unix  -       -       n       -       -       discard
local      unix  -       n       n       -       -       local
virtual    unix  -       n       n       -       -       virtual
lmtp       unix  -       -       n       -       -       lmtp
anvil      unix  -       -       n       -       1       anvil
scache     unix  -       -       n       -       1       scache

Sieht für mich erstmal unauffällig aus (darum fragte ich ja hier bei den 
Profis nach).

 > Ansonsten hilft natürlich auch LOG, das sich auf einer der Nachrichten
 > bezieht, die in der Queue rumgammeln.

Der Hinweis war gut - schaue ich in das Logfile rein findet sich für 
eine entsprechende Mail sinngemäß diese Meldung:

B4E29C1FDA: to=<... at gmx.de>, relay=none, delay=1097, 
delays=1096/1.4/0/0.03, dsn=4.0.0, status=deferred (delivery temporarily 
suspended: host mx01.emig.gmx.net[212.227.17.5] refused to talk to me: 
554-gmx.net (mxgmx110) Nemesis ESMTP Service not available 554-No SMTP 
service 554-IP address is black listed. 554 For explanation visit 
http://postmaster.gmx.com/en/error-messages?ip=xxx.xxx.xxx.xxx&c=bl)

Ich habe mir mal erlaubt die Logzeile der Lesbarkeit wegen auf den 
relevanten Teil zu beschränken.

Das System hat es leider (aber berechtigterweise) Dank eines Users* bei 
GMX auf den Index geschafft - dadurch fiel mir das Thema erst auf.

Schaue ich mir nun das ganze an, dann scheint es so, als würde GMX einen 
400-er SMTP-Code zurückgeben und das Problem im Meldungsteil mit einer 
554 beschreiben.

Das würde auch zu Deiner anfänglichen Einschätzung passen.

ABER ...
Baue ich mit telnet eine manuelle Verbindung von der 
Source-IP-Adresse-Adresse auf, dann kriege ich tatsächlich sofort eine 
554 von GMX angezeigt.

Wieso nimmt Postfix daher also eine dsn=4.0.0 im Log auf und lässt die 
Mail in der Queue?


Thomas

P.S.:
* der User wird bald noch viel Freude mit mir haben.


Thomas