On Friday, December 10, 2021 1:46:34 PM EST Alessandro Vesely wrote:
> On Fri 10/Dec/2021 05:11:28 +0100 Douglas Foster wrote:
> > The language in the quoted document about "multiple from messages are
> > usually rejected" was interesting.   It reflects what I would intend to
> > do, and what I think others should do, but I assumed that we could not
> > explicitly advocate for that, since we could be accused of rewriting
> > RFC5322.
> 
> Indeed!  RFC5322 explicitly allows multiple mailboxes:
> 
>     from            =   "From:" mailbox-list CRLF
> 
>     sender          =   "Sender:" mailbox CRLF
> 
> To completely disallow that syntax seems too harsh.  It is true that finding
> multiple authors is extremely improbable.  However, it may happen to have
> to compose a message with multiple authors, possibly because of legal
> attribution. In that case, being at a loss for proper authentication makes
> DMARC look like a sort of toy specification.
> 
> We can be very stern.  For example, we can require that the domain of the
> first author coincides with the domain of the Sender:, and validate the
> message as if that was the only author domain.  Very stern, but not overly
> stern.
> 
> Can we fix this inadequacy?

Ordering isn't guaranteed to be preserved.  I think the options are:

1.  Do not test for DMARC (current, no backward compatibility issues, but 
incomplete coverage).

2.  Test both and one must not fail (not clear if there are backward 
compatibility or reporting issues, doesn't solve incomplete coverage)

3.  Test both and both must not fail (probably not backward compatible, would 
need to figure out reporting, but does solve the "inadequacy").

Given the rarity of multi-From messages and that anything with backward 
compatibility issues should have a high hurdle to clear for inclusion, I don't 
think there's a good case for anything other than leave it as is.

Scott K


_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to