wieso SPF_FAIL bei ausgehender Mail?

fotofreund

New Member
Aug 5, 2019
3
0
1
Hallo,

ich hatte jetzt einen Fall von blocked outgoing Spam, den ich nicht verstehe. Neben Userfehler (falsches Rechnerdatum) tauchte u.a. auch SPF_FAIL mit einem Score von 0.919 auf, so dass die Mail im Endeffekt geblockt wurde.

Ist ja irgendwie logisch, der interne Mailserver taucht nicht im DNS auf ("v=spf1 mx -all"). Aber bei ausgehender Mail, die über den internen Port 26 geschickt wird, sollte m.E. gar keine SPF-Prüfung stattfinden.

Habe ich einen Denkfehler, kann man es konfigurieren oder ist es ein Fehler im PMG (noch Version 5.2-7)?


Danke im voraus!
 
Ist die Mail wirklich auf Port 26 angekommen? Evtl. im /var/log/mail.log oder auch im Tracking Center mal nachschauen.
AFAIK sollte das auch kein Bug in einer alten Version sein, aber ich kann mich natürlich auch irren.
 
Habe mich nicht mehr gemeldet, weil ich dachte, es sei ein Einzelfall. Aber heute hatte ich wieder eine. Der Port wird nicht geloggt, aber da ich die Konfiguration des sendenden Servers kenne, weiß ich, dass PMG als Relay mit Port 26 eingetragen ist.

Code:
Aug 20 09:17:56 PMG01 postfix/smtpd[19663]: connect from mail.example.com[78.xx.xx.xx]
Aug 20 09:17:56 PMG01 postfix/smtpd[19663]: Anonymous TLS connection established from mail.example.com[78.xx.xx.xx]: TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
Aug 20 09:17:56 PMG01 postfix/smtpd[19663]: F1DCA1989049: client=mail.example.com[78.xx.xx.xx]
Aug 20 09:17:56 PMG01 postfix/cleanup[19584]: F1DCA1989049: message-id=<f6f137bf-956c-4480-9579-3aaa609fa0cc@absender.de>
Aug 20 09:17:57 PMG01 postfix/qmgr[957]: F1DCA1989049: from=<info@absender.de>, size=7647, nrcpt=1 (queue active)
Aug 20 09:17:57 PMG01 postfix/smtpd[19663]: disconnect from mail.example.com[78.xx.xx.xx] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7
Aug 20 09:17:57 PMG01 pmg-smtp-filter[7690]: 19903675F3E23A50E759: new mail message-id=<f6f137bf-956c-4480-9579-3aaa609fa0cc@absender.de>
Aug 20 09:18:03 PMG01 pmg-smtp-filter[7690]: 19903675F3E23A50E759: SA score=4/5 time=6.084 bayes=undefined autolearn=disabled hits=AWL(-0.193),FRNAME_IN_MSG_XPRIO_NO_SUB(1),HTML_MESSAGE(0.001),RCVD_IN_MSPIKE_H3(0.001),RCVD_IN_MSPIKE_WL(0.001),SPF_FAIL(0.919),SPF_HELO_NONE(0.001),T_FILL_THIS_FORM_SHORT(0.01),XPRIO_SHORT_SUBJ(2.494)
Aug 20 09:18:03 PMG01 pmg-smtp-filter[7690]: 19903675F3E23A50E759: notify <admin@example.com> (rule: Block outgoing Spam, 576851990369)
Aug 20 09:18:03 PMG01 pmg-smtp-filter[7690]: 19903675F3E23A50E759: notify <info@absender.de> (rule: Block outgoing Spam, 662E5199036A)
Aug 20 09:18:03 PMG01 pmg-smtp-filter[7690]: 19903675F3E23A50E759: moved mail for <empfaenger@xxx.com> to spam quarantine - 199036D5F3E23AB73063 (rule: Block outgoing Spam)
Aug 20 09:18:03 PMG01 pmg-smtp-filter[7690]: 19903675F3E23A50E759: processing time: 6.43 seconds (6.084, 0.152, 0)
Aug 20 09:18:03 PMG01 postfix/lmtp[19585]: F1DCA1989049: to=<empfaenger@xxx.com>, relay=127.0.0.1[127.0.0.1]:10023, delay=6.5, delays=0.01/0/0.05/6.4, dsn=2.5.0, status=sent (250 2.5.0 OK (19903675F3E23A50E759))
Aug 20 09:18:03 PMG01 postfix/qmgr[957]: F1DCA1989049: removed

Mich wundern auch etwas die hohen XPRIO-Werte. Da muss man wohl etwas am Spamassassin "drehen".
Bin aber nun endlich mal am Upgraden und werde dann beobachten, ob das Problem mit dem 6er PMG auch noch auftritt.
 
Ist ja irgendwie logisch, der interne Mailserver taucht nicht im DNS auf ("v=spf1 mx -all"). Aber bei ausgehender Mail, die über den internen Port 26 geschickt wird, sollte m.E. gar keine SPF-Prüfung stattfinden.
Das stimmt so leider nicht ganz - die mail wird (je nach Regelsystem) im allgemeinen durch SpamAssassin analysiert (und dieser macht die SPF-checks) - deswegen auch die SpamAssassin hits mit SPF_FAIL (da die mail ja nicht von einer erlaubten IP kommt und ein '-all' in der policy ist)

Eine saubere Möglichkeit das zu umgehen wäre es dem DNS-Server des PMG beizubringen einen anderen SPF record zu liefern (in dem die interne IP enthalten ist).
Ansonsten können auch die SPF rules mit einem custom score von 0 bewertet werden (das gilt dann allerdings auch für inbound mails)

Ich hoffe das hilft!
 
Eine saubere Möglichkeit das zu umgehen wäre es dem DNS-Server des PMG beizubringen einen anderen SPF record zu liefern (in dem die interne IP enthalten ist).
Ansonsten können auch die SPF rules mit einem custom score von 0 bewertet werden (das gilt dann allerdings auch für inbound mails)
Danke, es hilft zumindest beim Denken. Ob es sich dann so umsetzen lässt, muss ich noch klären.

Habe erst mal die Regeln so angepasst, dass für outgoing spam (den es bei uns eigentlich gar nicht geben dürfte) ein höherer Schwellwert gilt.
 
Das stimmt so leider nicht ganz - die mail wird (je nach Regelsystem) im allgemeinen durch SpamAssassin analysiert (und dieser macht die SPF-checks) - deswegen auch die SpamAssassin hits mit SPF_FAIL (da die mail ja nicht von einer erlaubten IP kommt und ein '-all' in der policy ist)

Eine saubere Möglichkeit das zu umgehen wäre es dem DNS-Server des PMG beizubringen einen anderen SPF record zu liefern (in dem die interne IP enthalten ist).
Ansonsten können auch die SPF rules mit einem custom score von 0 bewertet werden (das gilt dann allerdings auch für inbound mails)

Ich hoffe das hilft!

Hmm, wieder eine Bestätigung, dass SPF unbrauchbar ist. An sich macht es ja Sinn, dass ausgehende Mails auch auf Spam geprüft werden, um sicherzustellen, selbst nicht Spams im großen Stil zu versenden (gerade bei ISPs bezüglich bspw. gehackter Konten oder Server, aber auch im Unternehmensumfeld, um sein eigenes Image nicht zu gefährden). Trotzdem sollten aber hier diverse Regeln "deaktivierbar" sein, beispielsweise SPF, DKIM, DMARC machen hier wenig Sinn. Da ausgehende Mails über einen speziellen Port kommen, könnte man sicher den SpamAssassin bzw. den PMG-SMTP-Filter mit einem anderen Flag invoken?
 
Da ausgehende Mails über einen speziellen Port kommen, könnte man sicher den SpamAssassin bzw. den PMG-SMTP-Filter mit einem anderen Flag invoken?
pmg-smtp-filter verwendet die selben child-prozesse fuer beide ports - und lädt SpamAssassin auch nur bei einem neustart neu - bis auf ein paar Grenzfaelle (z.b. SPF records, die bei internen systemen nicht mit den internen Systemen aligned sind) macht das auch Sinn (da die empfangenden Mailserver zu einem ähnlichen Ergebnis kommen wenn sie spamassassin verwenden)
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!