greylisting, "lost connection after UNKNOWN" -> kein mail von sender

[IEM]

wir haben ein kleines problem mit einem sender network, wodurch von unser "Community Subscription" PMG installtionen keine emails von dort angenommen werden.

der sender ist "editorialmanager.com" (ein publisher für akademische journals), deren outgoing mailserver sind:

nssmtp1.editorialmanager.com	216.205.0.77
nssmtp2.editorialmanager.com	216.205.0.78
nssmtp3.editorialmanager.com	216.205.0.79
nssmtp4.editorialmanager.com	216.205.0.80
nssmtp5.editorialmanager.com	216.205.0.69

für eine akademische institution wie uns sind emails vom publisher natürlich wichtig.

prinzipiell habe ich folgende probleme:

1. der sender verschickt emails auf eine weise, die greylisting-untauglich ist
2. wenn ich den sender für greylisting whiteliste, bekomme ich "lost connection after UNKNOWN" fehler

greylisting
wir haben prinzipiell greylisting aktiviert (ich habe damit fast nur positive erfahrung gemacht).
leider haben die editorialmanager.com-mailserver eine schlechte angewohnheit: bei einem temporären fehler (4xx) wird genau 2x (zwei mal) versucht, das mail zuzustellen, und zwar im abstand von jeweils einer minute.

z.b. so ("user@example.com" ist der lokale empfänger):

Jun 29 15:08:27 mailgate postfix/smtpd[1319]: connect from nssmtp4.editorialmanager.com[216.205.0.80] Jun 29 15:08:27 mailgate postfix/smtpd[1319]: NOQUEUE: reject: RCPT from nssmtp4.editorialmanager.com[216.205.0.80]: 450 4.7.1 <user@example.com>: Recipient address rejected: Service is unavailable (try later); from=<ab.cdefg.0.6c47ea.b150bfa2@editorialmanager.com> to=<user@example.com> proto=ESMTP helo=<nssmtp4.editorialmanager.com> Jun 29 15:08:27 mailgate postfix/smtpd[1319]: disconnect from nssmtp4.editorialmanager.com[216.205.0.80] ehlo=1 mail=1 rcpt=0/1 rset=1 quit=1 commands=4/5 Jun 29 15:09:27 mailgate postfix/smtpd[1080]: connect from nssmtp4.editorialmanager.com[216.205.0.80] Jun 29 15:09:27 mailgate postfix/smtpd[1080]: NOQUEUE: reject: RCPT from nssmtp4.editorialmanager.com[216.205.0.80]: 450 4.7.1 <user@example.com>: Recipient address rejected: Service is unavailable (try later); from=<ab.cdefg.0.6c47ea.b150bfa2@editorialmanager.com> to=<user@example.com> proto=ESMTP helo=<nssmtp4.editorialmanager.com> Jun 29 15:09:27 mailgate postfix/smtpd[1080]: disconnect from nssmtp4.editorialmanager.com[216.205.0.80] ehlo=1 mail=1 rcpt=0/1 rset=1 quit=1 commands=4/5 Jun 29 15:10:27 mailgate postfix/smtpd[1319]: connect from nssmtp4.editorialmanager.com[216.205.0.80] Jun 29 15:10:27 mailgate postfix/smtpd[1319]: NOQUEUE: reject: RCPT from nssmtp4.editorialmanager.com[216.205.0.80]: 450 4.7.1 <user@example.com>: Recipient address rejected: Service is unavailable (try later); from=<ab.cdefg.0.6c47ea.b150bfa2@editorialmanager.com> to=<user@example.com> proto=ESMTP helo=<nssmtp4.editorialmanager.com> Jun 29 15:10:27 mailgate postfix/smtpd[1319]: disconnect from nssmtp4.editorialmanager.com[216.205.0.80] ehlo=1 mail=1 rcpt=0/1 rset=1 quit=1 commands=4/5

soweit ich das verstehe, hat der PMG/postfix ein hardgecodetes greylist timeout von 3 minuten. da in meinem fall der letzte zustellversuch schon nach 2 minuten passiert, bleiben die email im greylisting hängen.

erschwerend kommt hinzu, dass der envelope-sender offenbar für jedes email neu generiert wird (d.h. während der 3 zustellversuche bleibt der sender gleich; wird ein neues email erstellt/gesendet, gibt's einen neuen sender) - also lernt das system auch nicht aus vorhergegangenen mails an den empfänger.

also habe ich die sender-IPs gewhitelistet:

IP network

Sender

216.205.0.64/27

"lost connection after UNKNOWN"
leider ist das aber auch nicht die lösung.

die SMTP-server werden nun zwar durchgelassen, aber die verbindung bricht mit einem "lost connection after UNKNOWN" ab:

Jul 27 07:56:26 mailgate postfix/postscreen[13572]: CONNECT from [216.205.0.80]:51561 to [192.168.1.25]:25 Jul 27 07:56:26 mailgate postfix/postscreen[13572]: WHITELISTED [216.205.0.80]:51561 Jul 27 07:56:26 mailgate postfix/smtpd[13700]: connect from nssmtp4.editorialmanager.com[216.205.0.80] Jul 27 07:56:26 mailgate postfix/smtpd[13700]: NOQUEUE: client=nssmtp4.editorialmanager.com[216.205.0.80] Jul 27 07:56:29 mailgate postfix/smtpd[13700]: lost connection after UNKNOWN from nssmtp4.editorialmanager.com[216.205.0.80] Jul 27 07:56:29 mailgate postfix/smtpd[13700]: disconnect from nssmtp4.editorialmanager.com[216.205.0.80] ehlo=1 mail=1 rcpt=1 unknown=0/13 commands=3/16


wtf?

ich nehme an, dass der remote host ein non-announced SMTP-verb verwendet (was er aber offensichtlich nicht tut, wenn er nicht gewhitelistet wurde).
postfix scheint verschiedene verbs zu announcen, je nachdem ob ein host gewhitelistet ist oder nicht:

non-whitelisted	whitelisted
SIZE 26214400	PIPELINING
VRFY	SIZE 26214400
ETRN	VRFY
STARTTLS	ETRN
ENHANCEDSTATUSCODES	STARTTLS
8BITMIME	ENHANCEDSTATUSCODES
DSN	8BITMIME
SMTPUTF8	SMTPUTF8
CHUNKING	CHUNKING

ich bin leider kein wirklicher postfix guru und habe keine idee, wie ich das debuggen sollte.
(ein mail an postmaster@editorialmanager.com ist soweit unbeantwortet.)

was kann ich tun?

• gibt es mittlerweile eine möglichkeit, das greylist timeout zu konfigurieren?
• wie kann ich herausfinden, was der remote sender schickt um den "UNKNOWN" zu triggern?

andere institutionen haben offenbar kein problem, mails von diesem sender zu empfangen.

 

[Stoiko Ivanov]

gibt es mittlerweile eine möglichkeit, das greylist timeout zu konfigurieren?

Nein dieses ist hardcoded (und funktioniert wirklich gut fuer die meisten server) - ein smtp server, der nur 2 minuten lang versucht eine mail zuzustellen klingt aber etwas seltsam.

es wuerde unter Umstaenden helfen das debugging vom smtpd von postfix aufzudrehen - siehe http://www.postfix.org/DEBUG_README.html

Ich nehme an, dass das whitelisting unter GUI->Configuration->Mail Proxy->Whitelist gemacht wurde (dort ist die Whitelist fürs greylisting)

Ich hoffe das hilft

 

[IEM]

ja, das whitelisting wurde über "GUI->Configuration->Mail Proxy->Whitelist" gemacht.
ich werde mir mal debug_peer_list ansehen (blöderweise kann ich keine mails vom sender triggern...)

und ja, ein SMTP server der nur 2 minuten lang probiert ist "etwas seltsam", aber was soll ich tun ;-)

 

[IEM]

@Stoiko Ivanov ich glaube, ich habe jetzt (nachdem ich debugging hochgedreht habe) eine spur, leider noch keine lösung...

• remote verwendet Microsoft SMTPSVC als outgoing SMTP-server
• scheinbar bevorzugen MS-SMTP-server BDAT anstelle von DATA
• PMG/postfix announced CHUNKING (also BDAT-support)
• unser upstream-provider (die Universität) hat eine SPI-firewall, die ein paar SMTP-verbs schwärzt
  • z.b. BDAT aber nicht CHUNKING
  • (don't ask...)
• da der remote SMTP-server sieht, dass unser server CHUNKING erlaubt, versucht er die payload über BDAT zu übertragen
• das PMG sieht aber nur XXXX, was natürlich einen fehler verursacht.

bis ich unseren upstream überzeugt habe, dass sie entweder CHUNKING und BDAT disablen sollen oder keines von beiden, werden wohl ein paar tage vergehen.

deswegen habe ich versucht, am postfix CHUNKING abzudrehen, indem ich in der /etc/postfix/main.cf (zum testen, bevor ich es in die /etc/pmg/templates/main.cf.in eintrage) folgende zeile hinzugefügt habe:

smtpd_discard_ehlo_keywords = chunking

das wird aber offenbar ignoriert, PMG announced noch immer CHUNKING (ich habe sowohl postfix reload als auch systemctl restart postfix ausgeführt).

liegt das daran, dass in der /etc/postfix/master.cf der smtp-server mit den cmdline parametern -o smtpd_discard_ehlo_keywords=silent-discard,dsn aufegrufen wird (wodurch mein eintrag überschrieben wird)?

wie kann ich also zusätzliche ehlo_keywords abdrehen?

 

[Stoiko Ivanov]

liegt das daran, dass in der /etc/postfix/master.cf der smtp-server mit den cmdline parametern -o smtpd_discard_ehlo_keywords=silent-discard,dsn aufegrufen wird (wodurch mein eintrag überschrieben wird)?

das wuerde ich mal annehmen (ohne es explizit getestet zu haben):
* einfach das template fuer die master.cf.in von '/var/lib/pmg/templates/master.cf.in' nach '/etc/pmg/templates/' kopieren und dort editieren.

Nach dem editieren muss die Konfiguration noch rausgeschrieben werden:
`pmgconfig sync`
und danach den postfix neu starten

und chunking von den ehlo keywords entfernen sollte auch korrekt sein - siehe : http://www.postfix.org/BDAT_README.html#disable

Ich hoffe das hilft!