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.