[SOLVED] Mail Blocked by 550 5.7.1 Service unavailable; client but already on Whitelist.

[itNGO]

Hi,

wir haben hier einen Absender xy@sbb.rs der geblockt wird durch diverse Blacklists.

Soweit ok. Nun haben wir unter Configuration -> Mail Proxy -> Whitelist die Absender-Adresse als "E-Mail Sender" hinzugefügt.
Es wird aber trotzdem wieder geblockt mit Blacklist.

Wie kann das sein? Sollte PMG nicht nach dem "FROM" schon in den "Durchzug" schalten, weil "globale" Whitelist?

 

[Stoiko Ivanov]

Wie kann das sein? Sollte PMG nicht nach dem "FROM" schon in den "Durchzug" schalten, weil "globale" Whitelist?

Ohne logs nicht zweifelsfrei zu sagen, aber ich nehme mal an, dass die mail rejected wird weil die IP von xy@sbb.rs auf einer DNSBL steht die im mail-proxy eingerichtet ist - in dem Fall _muss_ die IP gewhitelistet werden (in der Mail-proxy whitelist) - da postscreen die connection rejected, ohne etwas von domain-namen, from-adressen, etc. zu wissen

Ich hoffe das erklärt es

 

[itNGO]

Ohne logs nicht zweifelsfrei zu sagen, aber ich nehme mal an, dass die mail rejected wird weil die IP von xy@sbb.rs auf einer DNSBL steht die im mail-proxy eingerichtet ist - in dem Fall _muss_ die IP gewhitelistet werden (in der Mail-proxy whitelist) - da postscreen die connection rejected, ohne etwas von domain-namen, from-adressen, etc. zu wissen

Ich hoffe das erklärt es

Ja das erklärt es, aber das ist natürlich bei vielen Anbietern nicht nur "eine" IP-Adresse sondern ein ganzer Zoo, den man ggf. auch gar nicht kennt.

Das Tracking-Center zeigt ja auch Absender und Empfänger, die Daten sind also prinzipiell vorhanden. Meiner Meinung nach, könnte das System es also durchaus auch schon an der "Sender-Email" festmachen. Andere Systeme schaffen das ja auch, trotz Blacklisten.

 

[itNGO]

Ja das erklärt es, aber das ist natürlich bei vielen Anbietern nicht nur "eine" IP-Adresse sondern ein ganzer Zoo, den man ggf. auch gar nicht kennt.

Das Tracking-Center zeigt ja auch Absender und Empfänger, die Daten sind also prinzipiell vorhanden. Meiner Meinung nach, könnte das System es also durchaus auch schon an der "Sender-Email" festmachen. Andere Systeme schaffen das ja auch, trotz Blacklisten.

Ich verstehe allerdings auch, das "postscreen" das Problem ist, da hier aus "Performance-Gründen" wohl nur mit IP-Adressen/CIDR gearbeitet wird....

 

[itNGO]

Ok, wir haben das jetzt erstmal durch die Integration von postwhite gelöst.
Das führt aber auch unweigerlich dazu das bestimmte "Anbieter" jetzt den DNS-Filter passieren die bisher geblockt worden wären.
Da muss die nachgelagerte SPAM-Prüfung dann hoffentlich greifen..... alles irgendwie SEMI....

 

[Stoiko Ivanov]

Das Tracking-Center zeigt ja auch Absender und Empfänger, die Daten sind also prinzipiell vorhanden.

wenn es durch eine DNSBL in postscreen geblockt wird sind sie das normalerweise nicht - bitte logs mal sharen - vielleicht verstehe ich auch etwas am problem nicht?

 

[itNGO]

wenn es durch eine DNSBL in postscreen geblockt wird sind sie das normalerweise nicht - bitte logs mal sharen - vielleicht verstehe ich auch etwas am problem nicht?

Hab ich leider zu spät gesehen die Antwort... LOGs werden nur 48 Stunden aufbewahrt in unserer Konfiguration... wenn es wieder passiert, reiche ich ggf. LOGs nach....

 

[JoeSix]

Ich klinke mich hier mal ein, es scheint tatsächlich Unterschiede zu geben. (Before-Queue-Filtering: Yes):

1. Fall SMTP-Greeting wird nicht abgewartet:

Jan  4 13:45:07 pmg postfix/postscreen[25011]: CONNECT from [85.209.135.31]:47812 to [192.168.172.14]:25
Jan  4 13:45:07 pmg postfix/postscreen[25011]: PREGREET 11 after 0.02 from [85.209.135.31]:47812: EHLO User\r\n
Jan  4 13:45:07 pmg postfix/dnsblog[25014]: addr 85.209.135.31 listed by domain zen.spamhaus.org as 127.0.0.2
Jan  4 13:45:07 pmg postfix/dnsblog[25014]: addr 85.209.135.31 listed by domain zen.spamhaus.org as 127.0.0.4
Jan  4 13:45:07 pmg postfix/postscreen[25011]: DNSBL rank 2 for [85.209.135.31]:47812
Jan  4 13:45:07 pmg postfix/postscreen[25011]: DISCONNECT [85.209.135.31]:47812

hier gibt es keine verwertbaren Infos.

2. Fall, hier könnte man generell eingreifen:

Jan  4 13:19:38 pmg postfix/postscreen[24718]: CONNECT from [107.179.14.216]:48146 to [192.168.172.14]:25
Jan  4 13:19:38 pmg postfix/dnsblog[24719]: addr 107.179.14.216 listed by domain zen.spamhaus.org as 127.0.0.3
Jan  4 13:19:44 pmg postfix/postscreen[24718]: DNSBL rank 2 for [107.179.14.216]:48146
Jan  4 13:19:45 pmg postfix/tlsproxy[24729]: CONNECT from [107.179.14.216]:48146
Jan  4 13:19:45 pmg postfix/tlsproxy[24729]: Anonymous TLS connection established from [107.179.14.216]:48146: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jan  4 13:19:46 pmg postfix/postscreen[24718]: NOQUEUE: reject: RCPT from [107.179.14.216]:48146: 550 5.7.1 Service unavailable; client [107.179.14.216] blocked using zen.spamhaus.org; from=<giftcard@significant.top>, to=<xxx@yyy.zzz>, proto=ESMTP, helo=<giftcard.significant.top>
Jan  4 13:19:46 pmg postfix/postscreen[24718]: DISCONNECT [107.179.14.216]:48146
Jan  4 13:19:46 pmg postfix/tlsproxy[24729]: DISCONNECT [107.179.14.216]:48146

Diesen Fall sehe ich relativ häufig und wird dann auch im Message-Tracking gelistet

 

[Stoiko Ivanov]

2. Fall, hier könnte man generell eingreifen:

Stimmt - je nach dem wann postscreen blocked logged es alle infos - siehe auch: https://www.postfix.org/POSTSCREEN_README.html#starttls

Dennoch wird hier die Client IP geblockt - und das macht ja sinn den Block auf der Ebene zu machen ohne die Sender Address in betracht zu ziehen
(sonst würden viele Spammer einfach von no-reply@paypal.com - o.Ae. senden in der Erwartung dass es dann whitegelistet ist)

sprich wenn eine IP geblockt wird (via DNSBL), dann muss diese auch gewhitelistet werden

 

[Stoiko Ivanov]

Potentiell wäre es möglich das blocken durch die dnsbl von postscreen weg in den smtpd zu geben und dort dann mit den ACLs zu arbeiten, dass die mail/domain whitelist vor dem dnsbl check kommt..

siehe: https://www.postfix.org/SMTPD_ACCESS_README.html

Allerdings würde ich eher davon abraten - IPs die auf (guten) DNSBL landen tuen das meist nicht ohne Grund, und wenn es mal eine Fehlkonfiguration war, werden sie üblicherweise auch recht schnell wieder delistet.

Dazu kommt noch, dass postscreen prinzipiell darauf ausgelegt genau diese first-line of defense zu sein.