RBL schlägt an - remote client steht in whitelist

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

RBL schlägt an - remote client steht in whitelist

Friedrich Strohmaier
Hallo Leute,

das ist meine erste Mail an diese Liste.

Die meisten postfix-Kenntnisse habe ich von einem Workshop für Libreoffice
Admins mit Patrick in München. Ich hoffe, Patrick, ich mach' Dir keine Schande.
;o))

Jetzt zu meinem Anliegen:

Unser Postfix schert sich nicht darum, dass ich ihm die t-online mailouts in
meiner bypass_access als gut gekennzeichnet habe. Mails von diesen fängt immer
wieder mal der hostkarma Blacklistdienst ab.

Logmeldung:

Jul  5 00:22:16 tesla postfix/smtpd[6725]: connect from mailout09.t-online.de[194.25.134.84]
Jul  5 00:22:16 tesla postfix/smtpd[6725]: NOQUEUE: reject: RCPT from mailout09.t-online.de[194.25.134.84]: 554 5.7.1 Service unavailable; Client host [194.25.134.84] blocked using hostkarma.junkemailfilter.com; Black listed at hostkarma http://ipadmin.junkemailfilter.com/remove.php?ip=194.25.134.84; from=<[hidden email]> to=<[hidden email]> proto=ESMTP helo=<mailout09.t-online.de>

# postconf -n | grep restrictions
smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated check_client_access hash:/etc/postfix/bypass_access reject_unauth_pipelining reject_unknown_client_hostname
smtpd_helo_restrictions = permit_mynetworks permit_sasl_authenticated check_helo_access hash:/etc/postfix/bypass_access reject_invalid_helo_hostname reject_non_fqdn_helo_hostname reject_unknown_helo_hostname
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated check_recipient_access hash:/etc/postfix/bypass_access reject_unauth_destination reject_unauth_pipelining reject_non_fqdn_recipient reject_invalid_helo_hostname reject_non_fqdn_helo_hostname reject_unknown_recipient_domain reject_unlisted_recipient reject_unknown_address reject_rbl_client ix.dnsbl.manitu.net reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2
smtpd_sender_restrictions = permit_mynetworks permit_sasl_authenticated check_sender_access hash:/etc/postfix/bypass_access reject_non_fqdn_sender reject_unknown_sender_domain reject_unverified_sender

Meine (gekürzte) /etc/postfix/bypass_access:
...
t-online.de                     OK

# Telekom lt. Website
..
194.25.134.84                   OK
...

Was hindert den postfix die Auswertung der bypass_access in meinem Sinne
auszuführen?
Weitere Anregungen, Kritik oder RTFM sind hochwillkommen.

Reichen die Auszüge oder wird mehr gebraucht?

Gruß
--
Friedrich Strohmaier
Koordination AK-Technik
***
Freies Radio Wüste Welle
Tübingen/Reutlingen
- im Sudhaus -
Hechinger Str. 203, 72072 Tübingen
http://www.wueste-welle.de


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RBL schlägt an - remote client steht in whitelist

Markus Winkler
Hallo Friedrich,

On 05.07.19 01:42, Friedrich Strohmaier wrote:
> Unser Postfix schert sich nicht darum, dass ich ihm die t-online mailouts in
> meiner bypass_access als gut gekennzeichnet habe.

nur zur Sicherheit: die Map hast Du aber gebaut, oder?

Gruß
Markus
Reply | Threaded
Open this post in threaded view
|

Re: RBL schlägt an - remote client steht in whitelist

Friedrich Strohmaier
Hi Markus, *,

Am 05.07.19 um 22:17 schrieb Markus Winkler:> On 05.07.19 01:42, Friedrich Strohmaier wrote:

>> Unser Postfix schert sich nicht darum, dass ich ihm die t-online mailouts in
>> meiner bypass_access als gut gekennzeichnet habe.

> nur zur Sicherheit: die Map hast Du aber gebaut, oder?

Ja, und den postfix neu laden lassen - immer wieder.


Gruß
--
Friedrich Strohmaier
Koordination AK-Technik
***
Freies Radio Wüste Welle
für Tübingen/Reutlingen
http://www.wueste-welle.de


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RBL schlägt an - remote client steht in whitelist

Markus Winkler
Hi Friedrich,

On 05.07.19 23:15, Friedrich Strohmaier wrote:
> Ja, und den postfix neu laden lassen - immer wieder.

OK, wenngleich ich damit erst mal etwas ratlos bin und hoffe, ich habe an
Deinem Config-Auszug nix übersehen.

Was ich Dir generell und um den Fehler evtl. besser eingrenzen zu können,
empfehlen würde:

1) Ersetze mal die ganzen bisher einzelnen smtpd_*_restrictions zumindest
testhalber/temporär durch _eine_ in dieser Art:

smtpd_relay_restrictions =
     permit_sasl_authenticated,
     permit_mynetworks,
     check_client_access hash:/etc/postfix/access_client,
     check_helo_access hash:/etc/postfix/access_helo,
     check_sender_access hash:/etc/postfix/access_sender,
     check_recipient_access hash:/etc/postfix/access_recipient,
     reject_non_fqdn_sender,
     reject_non_fqdn_recipient,
     reject_unknown_sender_domain,
     reject_unknown_recipient_domain,
     reject_unknown_client_hostname,
     reject_unauth_destination,
     reject_unauth_pipelining,
     reject_invalid_hostname,
     reject_rbl_client ix.dnsbl.manitu.net,
     reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2,
     permit

und

2) splitte Deine bypass_access, wie oben zu sehen, in einzelne Maps auf und
dort dann _nur_ die patterns der jeweils zu prüfenden Information (host
name, envelope sender, helo etc.). Ist m. E. gezielter
konfigurier-/prüfbar, als wenn das alles in einem Topf liegt (gerade wenn
man Fehler wie Deinen untersuchen will).

Und als weiteren Gedanke noch ein Hinweis dazu:

> Meine (gekürzte) /etc/postfix/bypass_access:
> ...
> t-online.de                     OK
>
> # Telekom lt. Website
> ..
> 194.25.134.84                   OK
> ...

Das 'OK' bei den accept actions versuche ich generell zu vermeiden - zu
schnell ist man dabei ein open relay. Ich schaue immer, dass ich sowas
verwende:

whitelist:

t-online.de                  permit_auth_destination,reject
194.25.134.84                permit_auth_destination,reject

blacklist:

example.com                  reject


HTH und Gruß
Markus
Reply | Threaded
Open this post in threaded view
|

Re: RBL schlägt an - remote client steht in whitelist

Friedrich Strohmaier
Hi Markus, *,

hat bisschen gedauert - da ist was dazwischengekommen - sorry..

Am 06.07.19 um 11:21 schrieb Markus Winkler:
> On 05.07.19 23:15, Friedrich Strohmaier wrote:

>> Ja, und den postfix neu laden lassen - immer wieder.

> OK, wenngleich ich damit erst mal etwas ratlos bin

so gehts mir auch ;o))

> und hoffe, ich habe an Deinem Config-Auszug nix übersehen.

> Was ich Dir generell und um den Fehler evtl. besser eingrenzen zu können,
> empfehlen würde:

> 1) Ersetze mal die ganzen bisher einzelnen smtpd_*_restrictions zumindest
> testhalber/temporär durch _eine_ in dieser Art:

> smtpd_relay_restrictions =
>     permit_sasl_authenticated,
>     permit_mynetworks,
>     check_client_access hash:/etc/postfix/access_client,
>     check_helo_access hash:/etc/postfix/access_helo,
>     check_sender_access hash:/etc/postfix/access_sender,
>     check_recipient_access hash:/etc/postfix/access_recipient,
>     reject_non_fqdn_sender,
>     reject_non_fqdn_recipient,
>     reject_unknown_sender_domain,
>     reject_unknown_recipient_domain,
>     reject_unknown_client_hostname,
>     reject_unauth_destination,
>     reject_unauth_pipelining,
>     reject_invalid_hostname,
>     reject_rbl_client ix.dnsbl.manitu.net,
>     reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2,
>     permit
nun ja, an dem Mailserver hängt einiges dran und ich fürchte mit einer so
weitreichenden Änderung ein Problem durch das nächste zu ersetzen..

Wenn ich mal einen guten Tag und vergessen habe, dass ich in dieser Sache ein
Feigling bin, dann.. :o))

> und

> 2) splitte Deine bypass_access, wie oben zu sehen, in einzelne Maps auf und
> dort dann _nur_ die patterns der jeweils zu prüfenden Information (host name,
> envelope sender, helo etc.). Ist m. E. gezielter konfigurier-/prüfbar, als
> wenn das alles in einem Topf liegt (gerade wenn man Fehler wie Deinen
> untersuchen will).

nun ja ich gebe freimütig zu, dass die "Mischung" genau darin ihre Ursache hat,
dass die verschiedenen Blöcke bei Einzelbehandlung nicht die Ergebnisse
brachten, die ich erwartet hatte. Ich versteh' wohl nicht gut genug, was genau
da behandelt wird.

Wenn ich im Workshop richtig aufgepasst habe, ist es so, dass innerhalb der
Blöcke die Bedingungen strikt nach Reihenfolge abgearbeitet werden. Das hat bei
meiner Schrotflintenmethode bislang recht gut funktioniert. ;o))

Nochmal zur Erinnerung der Block, der für mich nicht nachvollziehbares Zeug
macht:

smtpd_recipient_restrictions =
        permit_mynetworks
        permit_sasl_authenticated
        check_recipient_access hash:/etc/postfix/bypass_access
        reject_unauth_destination
        reject_unauth_pipelining
        reject_non_fqdn_recipient
        reject_invalid_helo_hostname
        reject_non_fqdn_helo_hostname
        reject_unknown_recipient_domain
        reject_unlisted_recipient
        reject_unknown_address
        reject_rbl_client ix.dnsbl.manitu.net
        reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2

Ich versteh' nicht, was das Whitelisting an früher Stelle verhindert, aber
später die Blacklist zuschlagen lässt.
Insgeheim hatte ich gehofft, dass ich nur Tomaten auf den Augen habe und
weitere Augenpaare einen offensichtlichen Fehler sehen.

[..]

> Das 'OK' bei den accept actions versuche ich generell zu vermeiden - zu
> schnell ist man dabei ein open relay. Ich schaue immer, dass ich sowas
> verwende:

> whitelist:

> t-online.de                  permit_auth_destination,reject
> 194.25.134.84                permit_auth_destination,reject

> blacklist:

> example.com                  reject

Danke für den Tipp. Werde nachforschen, ob mein betagter Postfix 2.9.6 das
schon kann.

> HTH

auf jeden Fall, auch wenn sich der Tomatenverdacht nicht bestätigt hat :-\

Vielen Danke für's Mitdenken und nochmal sorry für den Verzug
--
Friedrich Strohmaier
Koordination AK-Technik
***
Freies Radio Wüste Welle
für Tübingen/Reutlingen
http://www.wueste-welle.de


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RBL schlägt an - remote client steht in whitelist

Markus Winkler
Hi Friedrich,

danke für die Infos.

Und zuerst ein Hinweis zu meiner vorigen Mail:

On 20.07.19 00:22, Friedrich Strohmaier wrote:
>> 1) Ersetze mal die ganzen bisher einzelnen smtpd_*_restrictions zumindest
>> testhalber/temporär durch _eine_ in dieser Art:
>
>> smtpd_relay_restrictions =
[...]

und da Du schreibst:

 > mein betagter Postfix 2.9.6

smtpd_relay_restrictions gibt es erst ab 2.10. Falls Du das also doch mal
testen solltest und bei dieser Postfix-Version bleibst, dann bitte durch
smtpd_recipient_restrictions ersetzen.

> nun ja, an dem Mailserver hängt einiges dran und ich fürchte mit einer so
> weitreichenden Änderung ein Problem durch das nächste zu ersetzen..

Naja, das ist eigentlich unkritisch. Aber die Entscheidung musst Du
natürlich selbst treffen. ;-)

> Nochmal zur Erinnerung der Block, der für mich nicht nachvollziehbares Zeug
> macht:

Gut, das Du's noch mal aufführst, denn ...

> smtpd_recipient_restrictions =
> permit_mynetworks
> permit_sasl_authenticated
> check_recipient_access hash:/etc/postfix/bypass_access
> reject_unauth_destination
> reject_unauth_pipelining
> reject_non_fqdn_recipient
> reject_invalid_helo_hostname
> reject_non_fqdn_helo_hostname
> reject_unknown_recipient_domain
> reject_unlisted_recipient
> reject_unknown_address
> reject_rbl_client ix.dnsbl.manitu.net
> reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2
>
> Ich versteh' nicht, was das Whitelisting an früher Stelle verhindert, aber
> später die Blacklist zuschlagen lässt.

... ich glaube, ich habe in Deiner ursprünglichen Mail etwas übersehen, was
mit meiner Empfehlung aus meiner letzten zu tun hat und was mir tatsächlich
erst jetzt aufgefallen ist (betriebsblind, da ich diese separaten
smtpd_*_restrictions einfach seit ewigen Zeiten nicht mehr verwende):

Du hast in Deinen smtpd_recipient_restrictions ja ausschließlich
check_recipient_access (Check auf Empfängeradresse) drin, am Ende dieses
Blocks allerdings zwei RBL-Checks, die jedoch Clients abfragen. Damit hast
Du (_nur_ innerhalb der smtpd_recipient_restrictions wohlgemerkt!) diese
beiden Client-Whitelists nicht drin:

t-online.de                     OK
194.25.134.84                   OK

da Du nämlich vor den RBL-Abfragen gar nicht auf Clients checkst
(check_client_access). Damit führt, wenn einer der genannten Clients auf
der RBL steht, dies zum REJECT in diesem Restrictions-Block und somit zum
beobachteten:

> reject: RCPT from mailout09.t-online.de[194.25.134.84]: 554 5.7.1 Service unavailable; Client host [194.25.134.84] blocked using hostkarma.junkemailfilter.com;

Lösung:

Verfrachte (verschiebe!) diesen beiden Zeilen aus dem o. g.
smtpd_recipient_restrictions-Block:

reject_rbl_client ix.dnsbl.manitu.net
reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2

folgendermaßen in diesen:

smtpd_client_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    check_client_access hash:/etc/postfix/bypass_access
    reject_unauth_pipelining
    reject_unknown_client_hostname
    reject_rbl_client ix.dnsbl.manitu.net                       <-------
    reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2   <-------

Nach einem postfix reload sollte das nun wie gewünscht funktionieren.

Du kannst das korrekte Verhalten übrigens mit XCLIENT testen:

Einfach mal ein

smtpd_authorized_xclient_hosts = localhost

in die main.cf, dann kannst Du von Deinem Server aus lokal anhand dieser
Readme:

http://www.postfix.org/XCLIENT_README.html

den Mailempfang von einem T-Online-Host aus simulieren und schauen, ob die
Restrictions nun wie gewünscht greifen (ggf. sogar mal gezielt vor und nach
der Änderung).


Übrigens:

 >> whitelist:
 >>
 >> t-online.de                  permit_auth_destination,reject
 >> 194.25.134.84                permit_auth_destination,reject
 >>
 >> blacklist:
 >> example.com                  reject

> Danke für den Tipp. Werde nachforschen, ob mein betagter Postfix 2.9.6 das
> schon kann.

Das kann der. ;-)


Meine Empfehlung hinsichtlich Eindampfen auf nur noch
smtpd_recipient_restrictions bleibt - auch damit wäre nämlich dieses
Problem beseitigt worden. Es ist wirklich kein Risiko dabei. ;-)

Viel Erfolg und viele Grüße
Markus
Reply | Threaded
Open this post in threaded view
|

Gelöst: RBL schlägt an - remote client steht in whitelist

Friedrich Strohmaier
Hi Markus, *,

Am 20.07.19 um 18:12 schrieb Markus Winkler:
> Hi Friedrich,

> danke für die Infos.

> Und zuerst ein Hinweis zu meiner vorigen Mail:

> On 20.07.19 00:22, Friedrich Strohmaier wrote:
>>> 1) Ersetze mal die ganzen bisher einzelnen smtpd_*_restrictions zumindest
>>> testhalber/temporär durch _eine_ in dieser Art:

>>> smtpd_relay_restrictions =
> [...]

> und da Du schreibst:

>> mein betagter Postfix 2.9.6

> smtpd_relay_restrictions gibt es erst ab 2.10. Falls Du das also doch mal
> testen solltest und bei dieser Postfix-Version bleibst, dann bitte durch
> smtpd_recipient_restrictions ersetzen.

O.K. Danke für die Info.

[..]

> Gut, das Du's noch mal aufführst, denn ...

>> smtpd_recipient_restrictions =
>>     permit_mynetworks
>>     permit_sasl_authenticated
>>     check_recipient_access hash:/etc/postfix/bypass_access
>>     reject_unauth_destination
>>     reject_unauth_pipelining
>>     reject_non_fqdn_recipient
>>     reject_invalid_helo_hostname
>>     reject_non_fqdn_helo_hostname
>>     reject_unknown_recipient_domain
>>     reject_unlisted_recipient
>>     reject_unknown_address
>>     reject_rbl_client ix.dnsbl.manitu.net
>>     reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2

>> Ich versteh' nicht, was das Whitelisting an früher Stelle verhindert, aber
>> später die Blacklist zuschlagen lässt.

[..]

> Du hast in Deinen smtpd_recipient_restrictions ja ausschließlich
> check_recipient_access (Check auf Empfängeradresse) drin, am Ende dieses
> Blocks allerdings zwei RBL-Checks, die jedoch Clients abfragen. Damit hast Du
> (_nur_ innerhalb der smtpd_recipient_restrictions wohlgemerkt!) diese beiden
> Client-Whitelists nicht drin:

> t-online.de                     OK
> 194.25.134.84                   OK

> da Du nämlich vor den RBL-Abfragen gar nicht auf Clients checkst
> (check_client_access). Damit führt, wenn einer der genannten Clients auf der
> RBL steht, dies zum REJECT in diesem Restrictions-Block und somit zum
> beobachteten:

>> reject: RCPT from mailout09.t-online.de[194.25.134.84]: 554 5.7.1 Service unavailable; Client host [194.25.134.84] blocked using hostkarma.junkemailfilter.com;

> Lösung:

> Verfrachte (verschiebe!) diesen beiden Zeilen aus dem o. g. smtpd_recipient_restrictions-Block:

> reject_rbl_client ix.dnsbl.manitu.net
> reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2

> folgendermaßen in diesen:

> smtpd_client_restrictions =
>    permit_mynetworks
>    permit_sasl_authenticated
>    check_client_access hash:/etc/postfix/bypass_access
>    reject_unauth_pipelining
>    reject_unknown_client_hostname
>    reject_rbl_client ix.dnsbl.manitu.net                       <-------
>    reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2   <-------

> Nach einem postfix reload sollte das nun wie gewünscht funktionieren.

Super! Habe ich als erste Sofortmaßnahme eingebaut. Ein erster kurzer Test lief
durch. Dann waren es also doch die Tomaten :o))

> Du kannst das korrekte Verhalten übrigens mit XCLIENT testen:

> Einfach mal ein

> smtpd_authorized_xclient_hosts = localhost

> in die main.cf, dann kannst Du von Deinem Server aus lokal anhand dieser Readme:

> http://www.postfix.org/XCLIENT_README.html

> den Mailempfang von einem T-Online-Host aus simulieren und schauen, ob die
> Restrictions nun wie gewünscht greifen (ggf. sogar mal gezielt vor und nach
> der Änderung).

Ui, das klingt interessant - da nehm' ich mir mal einen "statt Fernsehabend"
Zeit, um das anzuschauen.

> Übrigens:

>>> whitelist:

>>> t-online.de                  permit_auth_destination,reject
>>> 194.25.134.84                permit_auth_destination,reject

>>> blacklist:
>>> example.com                  reject

>> Danke für den Tipp. Werde nachforschen, ob mein betagter Postfix 2.9.6 das
>> schon kann.

> Das kann der. ;-)

Gut!

> Meine Empfehlung hinsichtlich Eindampfen auf nur noch
> smtpd_recipient_restrictions bleibt - auch damit wäre nämlich dieses Problem
> beseitigt worden. Es ist wirklich kein Risiko dabei. ;-)

Du hast mich überzeugt - ich werde das so in Angriff nehmen.

Der Weg in eine überschaubarere Konfiguration ist geebnet und vor allem das
Problem gelöst!

Vielen Dank für Deine Hilfe.
--
Friedrich Strohmaier
Koordination AK-Technik
***
Freies Radio Wüste Welle
für Tübingen/Reutlingen
http://www.wueste-welle.de


signature.asc (201 bytes) Download Attachment