On Wed, Jan 27, 2021 at 9:26 AM Alessandro Vesely <ves...@tana.it> wrote:
> AFAIUI, there's no reason why SPF would work with a logic substantially > different than DKIM's. DKIM can provide n identifiers, if one of them is > aligned and "pass", then DMARC is "pass". SPF can provide 2 identifiers > but > one of them is of class B. WTF? > DKIM (in its simplest form) returns N tuples of the form (d= domain, pass/fail). All of them were run through exactly the same check; all of them were attached to the message in exactly the same way; all of them have essentially identical semantics. Giving them equal footing makes sense to me. The two identifiers in SPF hold different places in the SMTP session, and have different semantics. I think treating them differently is also just fine. Can anyone explain why we have a <scope>helo</scope> element in aggregate > reports? > Not off the top of my head. If it's not meaningful, it should go. In addition, as I said, SPF filters are likely to report HELO as helo and > MAIL > FROM as mailfrom. If we want to carry over this quirk, the spec must say > that > a DMARC filter which gathers SPF authentication status from an upstream > filter > MUST make sure that mailfrom is empty before validating based on an > aligned helo. > ...or it doesn't evaluate against SPF at all in such a situation. Dropping that absurd discrimination between SPF identifiers would make for > a > smoother spec. Since non-null mailfroms are in most cases aligned with > either > From: or helo, the differences between existing compliant implementations > and > the smoother spec would be limited to a hardly noticeable set of test > messages. > I don't think we should ignore what those two identifiers mean, how likely they are to contain junk, how they are applied, outside of DMARC, etc. -MSK, participating
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
