On Wed 27/Jan/2021 21:10:37 +0100 Murray S. Kucherawy wrote:
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.


It is relevant that both identifier come from /the same/ SMTP session. That's not true for many DKIM signatures.


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 SPF altogether is too much. I'm querying about dropping just the idiosyncrasy...


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.


How is that different from d= identifiers?


Best
Ale
--





















_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to