On Sat 05/Aug/2023 21:37:31 +0000 Scott Kitterman wrote:
On Saturday, August 5, 2023 3:59:02 PM EDT John Levine wrote:
It appears that Scott Kitterman <skl...@kitterman.com> said:
When receivers apply the "MUST NOT reject" in Section 8.6 to accept
unauthenticated messages as quarantined messages, receivers SHOULD
carefully review how they forward mail traffic to prevent additional
security risk. That is, this downgrade can enable spoofed messages that
are SPF DMARC authenticated with a fraudulent From identity despite having
an associated strong DMARC policy of "p=reject". ...
We all realize that SPF has problems, but I really do not want to fill
up the DMARC document with text that says "you can authenticate with
SPF, hahaha no just kidding."
The way to fix Microsoft's forwarding SPF problem is for Microsoft to put
the forwarding user's bounce address on the message, not for us to tell
the entire world to use kludgy workarounds.
I agree. We need to be careful to solve protocol problems in the protocol and
leave fixing implementation problems to implementers. We aren't going to
protocol our way out of bad implementation decisions.
I'd also agree that M$ should fix their implementation. However, let's
recall that SMTP still says:
To expand an alias, the recipient mailer simply replaces the pseudo-
mailbox address in the envelope with each of the expanded addresses
in turn; the rest of the envelope and the message body are left
unchanged. The message is then delivered or forwarded to each
expanded address.
Hence, not replacing the bounce address is formally correct. As we aim at
blocking impersonations, we should offer a workaround.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
