On 18 Sep 2015, at 13:54, Sebastian Nielsen wrote:

Its the SPF checking that is configured to check against From: header.
The reason it says "envelope-from" is that I use a ready-made library (Mail::SPF) to do the dirty work, while I feed it with the "From:" header value as the adress to do the check against.

That particular misapplication of SPF records is inconsistent with any standardized mechanism. Specifically, that is NOT consistent with a formally correct DMARC implementation. The DMARC specification(RFC7489) clearly says that SPF is to be used ONLY to authenticate the RFC5321.MailFrom (a.k.a. "envelope-from") domain. If that SPF check gets any result other than an explicit "pass" then it is meaningless to DMARC: SPF cannot provide an "Authenticated Identifier" domain for DMARC's use. The DMARC specification *DOES NOT* say that the domain part of the RFC5322.From field (the "From:" header address) should be authenticated using SPF.

Obviously one can run one's mail system by whatever whimsical rules one's magical thinking can generate, but this particular application of SPF records is inconsistent with any standardized mechanism.

The original poster's problem is that he is doing traditional mostly-transparent forwarding yet is somehow managing to break Yahoo's DKIM signatures in the process. Yahoo publishes a DMARC Policy Record with a "p=reject" tag for the domain(s) it uses in From: headers and also honors that declaration on mail it is offered by requiring that mail claiming to be "From:" its users pass either a DKIM validation for an aligned domain OR SPF authentication for an aligned domain. Since any flavor of forwarding eliminates any chance of SPF authentication with a Yahoo domain, DMARC success relies solely on the DKIM check. DKIM signatures should generally resist invalidation by simple forwarding but forwarding isn't always simple.

Reply via email to