Thanks Kurt. Let me see if I can articulate our reasons for proposing DMARC as the signaling mechanism more clearly.
1. Although this proposal appears to be an MUA feature, it has meaningful relevance to the typical transfer agent as well. If it is fair to summarize DMARC as a means for reducing the delivery of forged email then this proposal fits in nicely. If an MTA can determine for example that a domain enforces a policy of signing all outbound messages (by the email sender, not using DKIM) and can easily locate the sender’s signing key with an appropriate chain of trust then the MTA can make a reliable decision about whether that email originated from the sender’s domain. This “feels” very similar to the way we use SPF and DKIM now. 2. Signaling mechanisms are most effective when they can leverage a beachhead already established by a deployed technology. DMARC has a growing deployed base with building momentum so it makes an attractive mechanism for signaling. If a domain originating email signals a policy that all outbound messages are signed and the recipient is unable to validate that signature then the recipient should do something interesting with the message. Bear in mind that the domain originating the records will have published the keys using a DNSSEC signed domain and will have published keys/certs for the users who originate mail from the domain. There would need to be a DNS resolution failure in order for a recipient to not be able to locate the key. Although there are currently still some deficiencies in the DNSSEC deployment, the operational picture for DNSSEC is continuing to improve. This proposal anticipates DNSSEC reaching critical mass. -- Glen Wiley Principal Engineer Verisign, Inc. (571) 230-7917 A5E5 E373 3C75 5B3E 2E24 6A0F DC65 2354 9946 C63A From: "Kurt Andersen (b)" <[email protected]<mailto:[email protected]>> Date: Tuesday, February 2, 2016 at 7:51 PM To: Wiley Glen <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [dmarc-ietf] using DMARC to signal policy for email canonicalization, signing and encryption On Tue, Feb 2, 2016 at 3:56 PM, Wiley, Glen <[email protected]<mailto:[email protected]>> wrote: . . .we have put together an approach that lets a zone owner signal the policy that is used for their domain by adding a few keywords to the DMARC record. The draft is at: https://datatracker.ietf.org/doc/draft-osterweil-dmarc-dane-names/ Section 1.2 of your I-D says: The previous specification of DMARC is almost entirely relevant to the MTA and transparent to the end user. The additions in this document are also relevant to the MUA. . . I'm not sure that mixing the features to be used by the MUA into the MTA oriented specs for DMARC makes sense. For instance what would a receiver be expected to do if they attempted to lookup an encoded recipient and could not find the cited record? Would you expect them to enforce a non-pass policy against that message? I think it would be more appropriate to communicate this information at a distinct end service point in the DNS - for example _mailenc.<domain> rather than overloading the DMARC semantics with something that only has a peripheral relationship to message domain authentication. Your proposal seems more in the vein of "Encryption-Based Message Authentication, Reporting and Conformance". --Kurt Andersen
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
