AMaViS: score_sender_maps
HI Joda, HI Mailingliste!
Wie sieht es denn mit der score_sender_maps aus? Ist der Einsatz von softwhite- und blacklisten aktuell (noch) zu empfehlen, oder kann man sich das sparen und das Ganze gleich direkt in der local.cf des Spamassassin eintragen?
Die amavisd.conf liefert dazu ja ein Beispiel mit:
@score_sender_maps = ({ # a by-recipient hash lookup table, # results from all matching recipient tables are summed
# ## per-recipient personal tables (NOTE: positive: black, negative: white) # 'user1@example.com' => [{'bla-mobile.press@example.com' => 10.0}], # 'user3@example.com' => [{'.ebay.com' => -3.0}], # 'user4@example.com' => [{'cleargreen@cleargreen.com' => -7.0, # '.cleargreen.com' => -5.0}],
## site-wide opinions about senders (the '.' matches any recipient) '.' => [ # the _first_ matching sender determines the score boost
new_RE( # regexp-type lookup table, just happens to be all soft-blacklist [qr'^(bulkmail|offers|cheapbenefits|earnmoney|foryou)@'i => 5.0], [qr'^(greatcasino|investments|lose_weight_today|market.alert)@'i=> 5.0], [qr'^(money2you|MyGreenCard|new.tld.registry|opt-out|opt-in)@'i=> 5.0], [qr'^(optin|saveonlsmoking2002k|specialoffer|specialoffers)@'i => 5.0], [qr'^(stockalert|stopsnoring|wantsome|workathome|yesitsfree)@'i => 5.0], [qr'^(your_friend|greatoffers)@'i => 5.0], [qr'^(inkjetplanet|marketopt|MakeMoney)\d*@'i => 5.0], ),
# read_hash("/var/amavis/sender_scores_sitewide"),
{ # a hash-type lookup table (associative array) 'nobody@cert.org' => -3.0, 'cert-advisory@us-cert.gov' => -3.0, 'owner-alert@iss.net' => -3.0, 'slashdot@slashdot.org' => -3.0, 'securityfocus.com' => -3.0, 'ntbugtraq@listserv.ntbugtraq.com' => -3.0, 'security-alerts@linuxsecurity.com' => -3.0, 'mailman-announce-admin@python.org' => -3.0, 'amavis-user-admin@lists.sourceforge.net'=> -3.0, 'amavis-user-bounces@lists.sourceforge.net' => -3.0, 'spamassassin.apache.org' => -3.0, 'notification-return@lists.sophos.com' => -3.0, 'owner-postfix-users@postfix.org' => -3.0, 'owner-postfix-announce@postfix.org' => -3.0, 'owner-sendmail-announce@lists.sendmail.org' => -3.0, 'sendmail-announce-request@lists.sendmail.org' => -3.0, 'donotreply@sendmail.org' => -3.0, 'ca+envelope@sendmail.org' => -3.0, 'noreply@freshmeat.net' => -3.0, 'owner-technews@postel.acm.org' => -3.0, 'ietf-123-owner@loki.ietf.org' => -3.0, 'cvs-commits-list-admin@gnome.org' => -3.0, 'rt-users-admin@lists.fsck.com' => -3.0, 'clp-request@comp.nus.edu.sg' => -3.0, 'surveys-errors@lists.nua.ie' => -3.0, 'emailnews@genomeweb.com' => -5.0, 'yahoo-dev-null@yahoo-inc.com' => -3.0, 'returns.groups.yahoo.com' => -3.0, 'clusternews@linuxnetworx.com' => -3.0, lc('lvs-users-admin@LinuxVirtualServer.org') => -3.0, lc('owner-textbreakingnews@CNNIMAIL12.CNN.COM') => -5.0,
# soft-blacklisting (positive score) 'sender@example.net' => 3.0, '.example.net' => 1.0,
}, ], # end of site-wide tables });
Verwenden oder rauswerfen?
Servus Django
* django@nausch.org django@nausch.org:
HI Joda, HI Mailingliste!
Wie sieht es denn mit der score_sender_maps aus? Ist der Einsatz von softwhite- und blacklisten aktuell (noch) zu empfehlen, oder kann man sich das sparen und das Ganze gleich direkt in der local.cf des Spamassassin eintragen?
Ich weiß es nicht und das bedeutet für mich: Messen! Also auskommentieren und Spamrate erfassen. Dann einkommentieren und Spamrate erfassen. Dann entscheiden.
Und nebenbei: Bei $Kunde waren die RBLs ausgefallen. Das hatte eine Load von 42 (sic!) und mehr pro inbound-Server zur Folge und alle 256 SMTP-Server-Prozesse waren belegt. Self induced DOS. :/
Monitoring hat es bemerkt und wir haben das umgehend gefixed. Anschliessend sank die Load wieder auf 4 und der Dienst hat wieder gut Platz nach oben.
Das war einer der Moment wo mir wieder mal deutlich vor Augen geführt wurde, wie wichtig gute, funktionierende RBLs für Green IT, niedrige Spamrate und hohe Verfügbarkeit sind.
Du kannst mit score_sender_maps bestimmt was rausholen. Ich frage mich, ob Du damit auf der linken oder der rechten Seite der 80/20-Regel bist. Lohnt es sich?
p@rick
Die amavisd.conf liefert dazu ja ein Beispiel mit:
@score_sender_maps = ({ # a by-recipient hash lookup table, # results from all matching recipient tables are summed
# ## per-recipient personal tables (NOTE: positive: black, negative: white) # 'user1@example.com' => [{'bla-mobile.press@example.com' => 10.0}], # 'user3@example.com' => [{'.ebay.com' => -3.0}], # 'user4@example.com' => [{'cleargreen@cleargreen.com' => -7.0, # '.cleargreen.com' => -5.0}],
## site-wide opinions about senders (the '.' matches any recipient) '.' => [ # the _first_ matching sender determines the score boost
new_RE( # regexp-type lookup table, just happens to be all soft-blacklist [qr'^(bulkmail|offers|cheapbenefits|earnmoney|foryou)@'i => 5.0], [qr'^(greatcasino|investments|lose_weight_today|market.alert)@'i=> 5.0], [qr'^(money2you|MyGreenCard|new.tld.registry|opt-out|opt-in)@'i=> 5.0], [qr'^(optin|saveonlsmoking2002k|specialoffer|specialoffers)@'i => 5.0], [qr'^(stockalert|stopsnoring|wantsome|workathome|yesitsfree)@'i => 5.0], [qr'^(your_friend|greatoffers)@'i => 5.0], [qr'^(inkjetplanet|marketopt|MakeMoney)\d*@'i => 5.0], ),
# read_hash("/var/amavis/sender_scores_sitewide"),
{ # a hash-type lookup table (associative array) 'nobody@cert.org' => -3.0, 'cert-advisory@us-cert.gov' => -3.0, 'owner-alert@iss.net' => -3.0, 'slashdot@slashdot.org' => -3.0, 'securityfocus.com' => -3.0, 'ntbugtraq@listserv.ntbugtraq.com' => -3.0, 'security-alerts@linuxsecurity.com' => -3.0, 'mailman-announce-admin@python.org' => -3.0, 'amavis-user-admin@lists.sourceforge.net'=> -3.0, 'amavis-user-bounces@lists.sourceforge.net' => -3.0, 'spamassassin.apache.org' => -3.0, 'notification-return@lists.sophos.com' => -3.0, 'owner-postfix-users@postfix.org' => -3.0, 'owner-postfix-announce@postfix.org' => -3.0, 'owner-sendmail-announce@lists.sendmail.org' => -3.0, 'sendmail-announce-request@lists.sendmail.org' => -3.0, 'donotreply@sendmail.org' => -3.0, 'ca+envelope@sendmail.org' => -3.0, 'noreply@freshmeat.net' => -3.0, 'owner-technews@postel.acm.org' => -3.0, 'ietf-123-owner@loki.ietf.org' => -3.0, 'cvs-commits-list-admin@gnome.org' => -3.0, 'rt-users-admin@lists.fsck.com' => -3.0, 'clp-request@comp.nus.edu.sg' => -3.0, 'surveys-errors@lists.nua.ie' => -3.0, 'emailnews@genomeweb.com' => -5.0, 'yahoo-dev-null@yahoo-inc.com' => -3.0, 'returns.groups.yahoo.com' => -3.0, 'clusternews@linuxnetworx.com' => -3.0, lc('lvs-users-admin@LinuxVirtualServer.org') => -3.0, lc('owner-textbreakingnews@CNNIMAIL12.CNN.COM') => -5.0,
# soft-blacklisting (positive score) 'sender@example.net' => 3.0, '.example.net' => 1.0,}, ], # end of site-wide tables });
Verwenden oder rauswerfen?
Servus Django
HI p@rick!
Am 21.11.2014 23:02, schrieb Patrick Ben Koetter:
Ich weiß es nicht und das bedeutet für mich: Messen! Also auskommentieren und Spamrate erfassen. Dann einkommentieren und Spamrate erfassen. Dann entscheiden.
Hmmm, lass es mich mal anders formulieren: Wo sind den Headerchecks besser "aufgehoben"? Im postfix via header_checks, im Spamassassin in der loacal.cf oder in der amavisd.conf
Rein funktionell ist es ja egal, wer den check macht, es wäre IMHO nur kontraproduktiv wenn alle 3 den gleichen check hintereinander machen würden.
Und nebenbei: Bei $Kunde waren die RBLs ausgefallen. Das hatte eine Load von 42 (sic!) und mehr pro inbound-Server zur Folge und alle 256 SMTP-Server-Prozesse waren belegt. Self induced DOS. :/
Aus dem Grund lass ich auch nagios checken, ob und wie lange es dauert von außen eine eMail einzukippen und dann hinten im IMAP-Konto zu kucken, ob die eMail auch angekommen ist. Das hat mich schon ein paar mal vor schlaflosen Nächten gerettet!
... funktionierende RBLs für Green IT, ...
Aha, das war dann wohl der ...eo.de :/
Du kannst mit score_sender_maps bestimmt was rausholen. Ich frage mich, ob Du damit auf der linken oder der rechten Seite der 80/20-Regel bist. Lohnt es sich?
Da gebe ich Dir Recht, ich werd' es daher meim Postfix'schen Headertest belassen.
BTW, wann genau springt eigentlich der header_check an? Bevor der SMTPD die Mail an den MILTER übergibt, oder nachher? Da habe ich noch ein kleines "?" in meiner Birne [1].
Vielleich kann Joda "wenigstens" das beantworten. Hmmmm, wenn Joda == p@rick, wer oder was ist dann Wietse? ;)
Servus Django
[1] http://dokuwiki.nausch.org/doku.php/centos:mail_c7:spam_6#grundlagen
Hi!
* Django [BOfH] django@nausch.org:
Am 21.11.2014 23:02, schrieb Patrick Ben Koetter:
Ich weiß es nicht und das bedeutet für mich: Messen! Also auskommentieren und Spamrate erfassen. Dann einkommentieren und Spamrate erfassen. Dann entscheiden.
Hmmm, lass es mich mal anders formulieren: Wo sind den Headerchecks besser "aufgehoben"? Im postfix via header_checks, im Spamassassin in der loacal.cf oder in der amavisd.conf
Postfix sieht sie zuerst. Spamassassin kann mehr.
Rein funktionell ist es ja egal, wer den check macht, es wäre IMHO nur kontraproduktiv wenn alle 3 den gleichen check hintereinander machen würden.
ACK
Und nebenbei: Bei $Kunde waren die RBLs ausgefallen. Das hatte eine Load von 42 (sic!) und mehr pro inbound-Server zur Folge und alle 256 SMTP-Server-Prozesse waren belegt. Self induced DOS. :/
Aus dem Grund lass ich auch nagios checken, ob und wie lange es dauert von außen eine eMail einzukippen und dann hinten im IMAP-Konto zu kucken, ob die eMail auch angekommen ist. Das hat mich schon ein paar mal vor schlaflosen Nächten gerettet!
... funktionierende RBLs für Green IT, ...
Aha, das war dann wohl der ...eo.de :/
Nein. Es waren andere.
Du kannst mit score_sender_maps bestimmt was rausholen. Ich frage mich, ob Du damit auf der linken oder der rechten Seite der 80/20-Regel bist. Lohnt es sich?
Da gebe ich Dir Recht, ich werd' es daher meim Postfix'schen Headertest belassen.
BTW, wann genau springt eigentlich der header_check an? Bevor der SMTPD die Mail an den MILTER übergibt, oder nachher? Da habe ich noch ein kleines "?" in meiner Birne [1].
Zwischendrin. :D
Postfix gibt ab dem ersten Connect jede SMTP Phase an den/die Milter weiter. Dann kommen die header_checks dran. Dann wird der Content an die Milter Zeile für Zeile abgegeben.
Vielleich kann Joda "wenigstens" das beantworten. Hmmmm, wenn Joda == p@rick, wer oder was ist dann Wietse? ;)
Also wenn, dann bin ich der Jodla, weil ich ja in Bayern wohne. Und tatsächlich besitze ich ein Jodeldiplom von dem da: http://www.jodelseminar.de/ War ein Bruder/Schwester-Geschenk. Nur die dürfen sowas. ;)
p@rick
HI p@rick!
Zitat von Patrick Ben Koetter p@sys4.de:
Postfix gibt ab dem ersten Connect jede SMTP Phase an den/die Milter weiter. Dann kommen die header_checks dran. Dann wird der Content an die Milter Zeile für Zeile abgegeben.
O.K., ich hab dann mal die score_sender_maps (wieder) in meine Konfig gepackt.
https://dokuwiki.nausch.org/doku.php/centos:mail_c7:spam_6
Mal sehen, wie sich das verhält. BTW, passt die Werbung? ;)
Was ist denn eigentlich aus dem Unterstützungprojekt zu Murray S. Kucherawy in Sachen openDMARC geworden? Geht da was weiter, oder ist das auf dem Weg zum Ziel verhungert?
Servus Django
Hi!
* n3rd@sec-mail.guru n3rd@sec-mail.guru:
HI p@rick!
Zitat von Patrick Ben Koetter p@sys4.de:
Postfix gibt ab dem ersten Connect jede SMTP Phase an den/die Milter weiter. Dann kommen die header_checks dran. Dann wird der Content an die Milter Zeile für Zeile abgegeben.
O.K., ich hab dann mal die score_sender_maps (wieder) in meine Konfig gepackt.
https://dokuwiki.nausch.org/doku.php/centos:mail_c7:spam_6
Mal sehen, wie sich das verhält. BTW, passt die Werbung? ;)
Vielen Dank für die Werbung!
Was ist denn eigentlich aus dem Unterstützungprojekt zu Murray S. Kucherawy in Sachen openDMARC geworden? Geht da was weiter, oder ist das auf dem Weg zum Ziel verhungert?
Halb, halb. Nachdem DMARC zurück auf Start gesetzt wurde (zu recht!), fand ich es nicht sinnvoll, das Unterstützungprojekt voranzutreiben. Die Build-Plattform will ich aber immer noch machen.
p@rick
Guten Morgen!
Am 03.12.2014 00:26, schrieb Patrick Ben Koetter:
Halb, halb. Nachdem DMARC zurück auf Start gesetzt wurde (zu recht!), ...
Aha, hast Du da Hintergrundinformationen dazu? Ich würde mich da gerne updaten wollen.
... fand ich es nicht sinnvoll, das Unterstützungprojekt voranzutreiben.
Hatte mich gewundert, arum es plötzlich so still geworden ist auf der openDMARC Mailingliste.
ttyl Django
* Django [BOfH] django@nausch.org:
Guten Morgen!
Am 03.12.2014 00:26, schrieb Patrick Ben Koetter:
Halb, halb. Nachdem DMARC zurück auf Start gesetzt wurde (zu recht!), ...
Aha, hast Du da Hintergrundinformationen dazu? Ich würde mich da gerne updaten wollen.
Im kommenden Linuxmagazin... :)
Man will Senderpolicies. DMARC ist eine Senderpolicy, die auf DKIM und SPF aufsetzt. Die Idee ist gut. Die Umsetzung lückenhaft. Damit DMARC, so wie es (lückenhaft) erdacht wurde, funktioniert darf man den Autor einer Nachricht nicht verändern. Genau das geschieht z.B. bei Mailinglisten. Da oben (in den Headern) steht ja auch nicht p@sys4.de als Absender, sondern die Mailingliste. Das zerstört die Signatur. Dadurch failed die DMARC Policy. Das führt zu rejects. Die führen zu bounces und z.B. zu ungewollten unsubscribes.
Wie man das vermeiden _kann_ steht hier: https://sys4.de/de/blog/2013/08/11/mailman-dmarc-konform-betreiben/ https://sys4.de/de/blog/2013/08/11/dkim-konforme-mailinglisten/
Die Probleme mit DMARC sind noch nicht gelöst. Aufgrund des Ärgers mit Yahoo's plötzlichem Schwenk zu DMARC 'reject' Policy, fand sich endlich eine IETF WG zusammen, die das Problem sauber lösen will. (In IETF 89 in Berlin gab es auch schon den Versuch eine WG zu gründen, aber da waren einige zu beleidigt, um es auch tatsächlich zu tun: "Ihr habt uns vorher auch nicht gebraucht, als ich Euch DMARC ausgedacht habt und jetzt kommt ihr zu uns...")
... fand ich es nicht sinnvoll, das Unterstützungprojekt voranzutreiben.
Hatte mich gewundert, arum es plötzlich so still geworden ist auf der openDMARC Mailingliste.
Ich erwarte, dass DMARC anders funktionieren werden wird und nehme an es wird wieder lebendiger, sobald sie sich auf einen 'guten Standard' geeinigt haben werden.
p@rick
Am 03.12.2014 um 09:13 schrieb Patrick Ben Koetter:
- Django [BOfH] django@nausch.org:
Guten Morgen!
Am 03.12.2014 00:26, schrieb Patrick Ben Koetter:
Halb, halb. Nachdem DMARC zurück auf Start gesetzt wurde (zu recht!), ...
Aha, hast Du da Hintergrundinformationen dazu? Ich würde mich da gerne updaten wollen.
Im kommenden Linuxmagazin... :)
Man will Senderpolicies. DMARC ist eine Senderpolicy, die auf DKIM und SPF aufsetzt. Die Idee ist gut. Die Umsetzung lückenhaft. Damit DMARC, so wie es (lückenhaft) erdacht wurde, funktioniert darf man den Autor einer Nachricht nicht verändern. Genau das geschieht z.B. bei Mailinglisten. Da oben (in den Headern) steht ja auch nicht p@sys4.de als Absender, sondern die Mailingliste. Das zerstört die Signatur. Dadurch failed die DMARC Policy. Das führt zu rejects. Die führen zu bounces und z.B. zu ungewollten unsubscribes.
Wie man das vermeiden _kann_ steht hier: https://sys4.de/de/blog/2013/08/11/mailman-dmarc-konform-betreiben/ https://sys4.de/de/blog/2013/08/11/dkim-konforme-mailinglisten/
Die Probleme mit DMARC sind noch nicht gelöst. Aufgrund des Ärgers mit Yahoo's plötzlichem Schwenk zu DMARC 'reject' Policy, fand sich endlich eine IETF WG zusammen, die das Problem sauber lösen will. (In IETF 89 in Berlin gab es auch schon den Versuch eine WG zu gründen, aber da waren einige zu beleidigt, um es auch tatsächlich zu tun: "Ihr habt uns vorher auch nicht gebraucht, als ich Euch DMARC ausgedacht habt und jetzt kommt ihr zu uns...")
... fand ich es nicht sinnvoll, das Unterstützungprojekt voranzutreiben.
Hatte mich gewundert, arum es plötzlich so still geworden ist auf der openDMARC Mailingliste.
Ich erwarte, dass DMARC anders funktionieren werden wird und nehme an es wird wieder lebendiger, sobald sie sich auf einen 'guten Standard' geeinigt haben werden.
p@rick
Dmarc ist nicht Vergnuegungsteuerpflichtig *g, um die groebsten Probleme kommt man evtl herum wenn man ein selektives DMARC verify macht, das ist aber nur ein tmp Workaround....
Best Regards MfG Robert Schetterer
Ahoi!
Quoting Patrick Ben Koetter p@sys4.de:
Im kommenden Linuxmagazin... :)
Aha und im welchem Heft genau? http://www.linux-magazin.de/Ausgaben/2014/12 oder http://www.linux-magazin.de/Ausgaben/2015/01
Man will Senderpolicies. DMARC ist eine Senderpolicy, die auf DKIM und SPF aufsetzt. Die Idee ist gut. Die Umsetzung lückenhaft. Damit DMARC, so wie es (lückenhaft) erdacht wurde, funktioniert darf man den Autor einer Nachricht nicht verändern. Genau das geschieht z.B. bei Mailinglisten.
Tja, kann man machen, muss man aber nicht. ;)
Das zerstört die Signatur. Dadurch failed die DMARC Policy. Das führt zu rejects. Die führen zu bounces und z.B. zu ungewollten unsubscribes.
Wie man das vermeiden _kann_ steht hier: https://sys4.de/de/blog/2013/08/11/mailman-dmarc-konform-betreiben/ https://sys4.de/de/blog/2013/08/11/dkim-konforme-mailinglisten/
Hmm, also ich "vertrau" da eher dem Gestammel da:
https://dokuwiki.nausch.org/doku.php/centos:mail_c7:spam_9 und http://dokuwiki.nausch.org/doku.php/centos:mail_c6:mta_13
:P
Die Probleme mit DMARC sind noch nicht gelöst.
Ich hoffe aber mal stark, dass daran weiter gearbeitet wird, den die zu grunde liegende Idee finde ich persöhnlich schon charmant.
Aufgrund des Ärgers mit Yahoo's plötzlichem Schwenk zu DMARC 'reject' Policy, fand sich endlich eine IETF WG zusammen, die das Problem sauber lösen will.
Bist Du bei diesewr workgroup dabei, oder wie kann ich mir ggf. selbst Informationen über deren Arbeit verschaffen. Nicht dass mir g'rad langweilig wäre, aber neugfierig bin ich da schon. :)
Ich erwarte, dass DMARC anders funktionieren werden wird und nehme an es wird wieder lebendiger, sobald sie sich auf einen 'guten Standard' geeinigt haben werden.
Na, ich hoffe mal, dass das: a) nicht all zu lange dauern wird 2028 will ich in Pension gehen und b) Du uns berichten wirst, sobald es da etwas nennenswertes Neues geben wird.
Servus Django
Am 03.12.2014 um 15:26 schrieb django@nausch.org:
2028 will ich in Pension gehen
Bis dahin gibts open-telepathie 2.14 *g
Best Regards MfG Robert Schetterer
HI!
Quoting Robert Schetterer rs@sys4.de:
Am 03.12.2014 um 15:26 schrieb django@nausch.org:
2028 will ich in Pension gehen
Bis dahin gibts open-telepathie 2.14 *g
maybe, aber ich hab mich leider vertippt, muss wohl eher mind. bis 2038 malochen ... :/
ttyl Django
* django@nausch.org django@nausch.org:
Ahoi!
Quoting Patrick Ben Koetter p@sys4.de:
Im kommenden Linuxmagazin... :)
Aha und im welchem Heft genau? http://www.linux-magazin.de/Ausgaben/2014/12 oder http://www.linux-magazin.de/Ausgaben/2015/01
Hmmm, keines. Die 2015/01 habe ich schon. Wird wohl 2015/02 werden.
Bist Du bei diesewr workgroup dabei, oder wie kann ich mir ggf. selbst Informationen über deren Arbeit verschaffen. Nicht dass mir g'rad langweilig wäre, aber neugfierig bin ich da schon. :)
List-Id: "Domain-based Message Authentication, Reporting, and Compliance (DMARC)" <dmarc.ietf.org> List-Unsubscribe: https://www.ietf.org/mailman/options/dmarc, mailto:dmarc-request@ietf.org?subject=unsubscribe List-Archive: http://www.ietf.org/mail-archive/web/dmarc/ List-Post: mailto:dmarc@ietf.org List-Help: mailto:dmarc-request@ietf.org?subject=help List-Subscribe: https://www.ietf.org/mailman/listinfo/dmarc, mailto:dmarc-request@ietf.org?subject=subscribe
p@rick
Hallo,
Am 03.12.2014 um 09:13 schrieb Patrick Ben Koetter:
Ich erwarte, dass DMARC anders funktionieren werden wird und nehme an es wird wieder lebendiger, sobald sie sich auf einen 'guten Standard' geeinigt haben werden.
Wenn ich den aktuellen Draft richtig verstehe (ich habe doch ein paar Zweifel bezüglich meiner Genialität ;) ), dann ist DMARC per-se zwar ganz nett, in der Praxis doch aber eher untauglich.
DKIM-Check SPF-Check DMARC-Check (pass, wenn from-address für spf ODER dkim gültig ist)
Die SPF-Checks macht bei mir policyd-spf-perl. Genaugenommen müsste ich das durch opendmarc ersetzen. Ich vermute aber, dass opendmarc Mails mit einem spf-failure zulässt, wenn DKIM gültig ist - und zwar auch dann, wenn kein DMARC-Record existiert. Das würde einen SPF-Check nahezu komplett aushebeln; zumindest sehe ich kaum Mails, zu denen ein DMARC-Record gehört.
Evtl. könnte man policyd-spf-perl auch zusätzlich hinter opendmarc einbinden.
Ich werde wohl (erstmal) dabei bleiben, einen DMARC-Record im DNS zu hinterlegen und mir entsprechende Checks zu verkneifen bzw. die Mails so zu verarbeiten als gäbe es DMARC nicht.
Gruß Florian
Ahoi Florian!
Quoting Florian Schaal mailinglist@schaal-24.de:
Wenn ich den aktuellen Draft richtig verstehe (ich habe doch ein paar Zweifel bezüglich meiner Genialität ;) ),
<bg> Na ich hab da eher Zweifel bei meinem Verständnis des Drafts. Genial bin ich per se schon mal nicht! ;)
Ich werde wohl (erstmal) dabei bleiben, einen DMARC-Record im DNS zu hinterlegen und mir entsprechende Checks zu verkneifen bzw. die Mails so zu verarbeiten als gäbe es DMARC nicht.
Also ich hab mir selbst passende Daten im DNS hinterlegt. Bei einer Domäne habe ich auch bewusst ein "reject" im DMARC-TXT-Record gesetzt. So kann ich bei meinen Tests beobachten, wie andere Systeme darauf reagieren. Auf meinem Haupt-Testsystem habe ich auch Murray's opendmarc im Einsatz, zusammen mit smf-spf und amavisd via milter. Soweit ich das sehe und beurteilen kann, läuft dasd so wie von mir erwartet. gefakte paypal-mails bleiben damit zumindestens aus.
Nachdem mir heute einer "Expertenrunde" einer großen Zentral-Organisation zur Sicherheit in der Informatik vorgelegt wurde, habe ich das sehr interessiert gelesen. Dort wird unter anderem genannt, dass SPF, DKIM und DMARC (!) in Kombination die Möglichkeit bietet, den Missbrauch der eigenen Adressen zu bekämpfen.
Summa Summarum: Einsatz wird empfohlen.
Nun gut, ich hab Dir ja an anderer Stelle schon geschrieben, dass ich mir der Sache die Tage intensiver widmen werde. Meine Erkenntnisse werde ich dann wie immer in meimem BLOG'chen versenken. ;)
Servus Django
participants (6)
-
Django [BOfH] -
django＠nausch.org
-
Florian Schaal -
n3rd＠sec-mail.guru -
Patrick Ben Koetter -
Robert Schetterer