On August 6, 2023 11:02:04 AM UTC, Alessandro Vesely <ves...@tana.it> wrote:
>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.
>
It's really not a DMARC problem.
Scott K
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
