On 14/11/22 22:12, Alessandro Vesely wrote:
On Mon 14/Nov/2022 01:26:29 +0100 Scott Kitterman wrote:
>
>> Because of DKIM’s broad deployment, compatibility with existing
>> deployments will be a critical factor, and it is unlikely that proposals
>> that lack compatibility will proceed to publication.
>
> Is compatibility with DKIM sufficient for the charter or should there be
> broader language about compatibility with existing email architecture? I'm
> inclined to say "Yes", but I'm unsure about wording.
What most approaches seem to imply is that a message which passes DMARC is
acceptable when the recipient can be derived from one of the mailboxes in the
To: and Cc: header fields —let's call *blindfolded messages* those which miss
this feature. Email arch only authorizes to read To: and Cc: fields on
sending, along with non-copied Bcc:, in order to derive the RCPT part of the
envelope.
I don't believe that any of the standards include such a derivation
constraint. It is normal practice for MUAs to submit a copy of a message
with each recipient listed in To:, CC:, etc. listed in the envelope(s).
It is also normal practice for MUAs to provide a BCC interface which is
implemented by adding those addresses to the envelope and *not*
including them in any message header. There are also MDAs which
synthesise a limited BCC header.
The solution we seek would imply to reject or quarantine non-whitelisted
blindfolded messages, even if they pass DMARC. This can be thought of as a
further tightening of policies. It would disrupt email architecture in a way
similar to what DMARC itself does. Indeed, DMARC charter does say that it is
problematic for email architecture at large. We should say the same here.
Abuse prevention is specifically intended to disrupt the normal
operation of protocols. I suspect that the DMARC charter arises from the
unique circumstances of its adoption (i.e. widespread adoption before
IETF worked on it). Perhaps there is benefit in acknowledging that the
WG might adopt techniques which are known to cause harm in some
circumstances, but that this should only occur where there reason to
believe that there is substantial beneficial use and with a clear
statement of the considerations for use.
(There a very rough analogy in the requirement to include "security
considerations" in most/all RFCs. We acknowledge that stuff can go
wrong, but we've thought about that carefully too, and documented
relevant things to think about.)
- Roland
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
