Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Scott Kitterman <[e-mail]>]

On April 18, 2023 10:00:45 PM UTC, Jim Fenton <[e-mail]> wrote:
>On 9 Apr 2023, at 0:50, Murray S. Kucherawy wrote:
>
>> (Note, here, that Barry has in his proposed text limited the constraint to
>> those types of deployments where the damage is likely.  I concur.  DMARC,
>> as currently defined, works just fine when deployed in transactional
>> situations.  Or, at least, I haven't seen that identified as a problem
>> case.)
>
>I have been trying to point out a problem in even for transactional messages. Some receive-side forwarders that people use break DKIM signatures, and of course break SPF. So a transactional message sent to a forwarded address might be rejected if the address to which it is forwarded enforces DMARC.
>
>IMO, receive-side forwarding is an important use case. It allows people to maintain a consistent email address if they change mail providers. For people whose email provider is their ISP, that keeps them from being locked into that ISP.
>
>It’s possible that this might be solved if the forwarder implements ARC, but only if the address to which it is forwarded knows how to implement ARC. I suspect that many DMARC enforcers currently don’t.
>
I think this is correct, but I also think the consequences for these failures are different enough that they don't carry the same degree of importance.

1.  Unlike on mailing lists, if you have set up a forwarder and you decline to accept mail from the forwarder and the forwarder unsubscribes you from their service, that's entirely a local problem.  I realize that this may not be very tractable for users of large mail services, but the simple answer is either whitelist such sources from DMARC checks and use ARC data if it's available (or parse the AR header field the forwarder includes) to find out if the message was spoofed when received by the forwarder.

There's no third-party damages as there can be with between ADMD mediators.

2.  The forwarder is the receiver's ADMD boundary with the Internet.  Internal forwarding beyond the border MTA is really an Internal problem.  I don't think it's technically an Internet interoperability problem in the way the IETF would normally think of it for mail services.  You're free to lose your own mail and no RFC will save you.

Scott K