[Postfixbuch-users] UPS/DHL Spam

[Urban Loesch]

Am 06.03.2015 um 12:22 schrieb Andreas Schulze:
> Am 06.03.2015 09:24 schrieb Urban Loesch:
>> 1) Mail auf SPF prüfen und Resultat im Header einfügen
>> 2) Mail auf DKIM prüfen und REsultat im Header einfügen
>> 3) Mail mit den eingefügten Headern dem DMARC Milter übergeben zur weiteren Verarbeitung
> ok
> 
>> Relevante installierete Pakete und Reihenfolge der Checks
>> - postfix-policyd-spf-python
> KNIRSCH

Hatte bis jetzt keine Probleme damit.

> 
>> - opendkim als Milter nur im Verify-Modus
>> - opendmarc als Milter
>> - clamav-milter
>> - amavis-milter mit spamassassin
> 
> es gibt da eine Reihe von ungünstigen Umständen, die so ein Setup sehr wackelig machen können.
> Kann sein, dass es klappt, muss aber nicht :-/
> 
> Das Problem ist der SPF-Checker als Policy Daemon. Zu dem Zeitpunkt, wo der PolicyDaemon
> sein Resultat als Header einfügt, ist möglicherweise der DMARC-Milter schon vorbei und hat seine
> Entscheidung getroffen.
> 
> Das wurde erst in Postfix 2.12 irgendwann im Herbst 2014 bzw. mit Postfix 3.0.0 gefixt.
> Das gemeine an der Geschichte ist die Oder-Verknüpfung von SPF und DKIM.
> Solange SPF *oder* DKIM ein "pass" liefern, ist DMARC zufrieden.

Daher der Workaround wie unten beschrieben mit dem Psuedo-Header.

> 
> Nur bei einigen Mail, wo DKIM kaputt ist, sollte halt SPF noch OK sein und einen DMARC pass erzeugen.
> Und dort wundert man sich dann, dass genau das nicht passiert!
> 
> Daher würde ich einen SPF-Checker in MILTER-Form immer einem Policy-Daemon vorziehen.
> Ich habe mit smf-spf Milter und einigen Patches gute Erfahrungen.
> Quelle und Patches habe ich hier geposted: http://www.trusteddomain.org/pipermail/opendmarc-users/2013-April/000140.html
> 
> 
> Übrigens:
> Aktuelle OpenDMARC Versionen können auch selber die SPF-Prüfung durchführen.
> Leider ist auch dieser Code immernoch nicht fehlerfrei. http://sf.net/p/opendmarc/tickets/95/ 

Das hatte ich auch versucht. Ging aber irgendwie nicht und konnte nicht herausfinden waru.
Ich habe es dann aufgegeben.

> Wer allerdings noch kein IPv6 als MX einsetzt, dem kann das egal sein.
> Dann würde ich opendkim + opendmarc-1.3.x empfehlen.
>
>>
>> Konfiguration:
>> POSTFIX main.cf
>> ...
>> smtpd_data_restrictions =      check_sender_access regexp:/etc/postfix/add_header_to_all.regexp,
>> 				# setzt leeren Pseudo Header, da sonst opendmarc den SPF Header nicht uebertragen bekommt. Details:
>>                                # https://groups.google.com/forum/#!topic/mailing.postfix.users/FyFdakjwZ-s -> mit Postfix 3.0 behoben.
>>                                # Besser in smtpd_data_restrictions, so wird der Header bei mehreren gleichzeitigen Recipients nur 1x gesetzt
>>                                # SPF Policyserver der A+R Header einfuegt.
>>                                check_policy_service unix:private/policyd-spf
> genau, mit einem SPF Chacker als MILTER spart man sich solche undurchsichtigen Krücken.

Naja so undurchsichtig sehe ich das jetzt nicht. Es gibt nun mal mehrere Wege die zum Ziel führen und anderer ist mir zu der Zeit
als ich das implementiert habe keiner eingefallen. Auch habe ich bis jetzt keine Nebenwirkungen feststellen können.
Zudem habe ich Postfix 3.0.0 noch nicht am laufen.


> 
>> # SPF Header werden mit postfix-policyd-spf gesetzt
>> # inet:localhost:8891 = OpenDKIM - ersetzt Amavis Verification
>> # inet:localhost:8892 = OpenDMARC - braucht SPF + DKIM Results im Header für Auswertung
>> smtpd_milters = inet:IPMILTER-SERVER:8891,inet:IPMILTER-SERVER:8892,ANDRE MILTER MAXIMAL 4
> warum "MAXIMAL 4" ??
> es gibt da keine Begrenzung. Ich habe schon Setups mit 7 Miltern gesehen...

Habe ich mal irgendwo gelesen, glaube ich zumindest. Kann mich aber auch auch täuschen.
Egal, je mehr, je besser...

> 
> lesbarer wird das Ganze übrigens, wenn man in der main.cf Macros definiert
> 
>    spf_milter = inet:...
>    opendkim_milter = inet:...
> 
> und diese Macros dann in main- oder master.cf benutzt:
> 
>    smtpd_milters = ${spf_milter},${opendkim_milter}, ..
> 
> 

Urban