Or TLS, plenty emails on our systems provide a client certificate to our servers. The domain in the CN= could be used for alignment.
I don't know if this is useful, as usually the emails have SPF or DKIM, but I see a sizeable portion of emails with no SPF nor DKIM providing a client TLS certificate signed by a trusted CA, and and an equivalent portion with self signed certificates. Overall it would cut by about half the number of unauthenticated emails (the ones with no valid SPF nor valid DKIM) if I would count the client TLS certificate as an authentication. ----- Original Message ----- From: "Brandon Long" <[email protected]> To: "Glen Wiley" <[email protected]> Cc: [email protected], "Kurt Andersen (b)" <[email protected]> Sent: Wednesday, February 3, 2016 1:55:53 PM Subject: Re: [dmarc-ietf] using DMARC to signal policy for email canonicalization, signing and encryption As far as adding S/MIME or SMIMEA as an authentication mechanism, ie to make DMARC act on "SPF/DKIM/SMIME" authentication, then adding it to DMARC makes sense. To include other domain email information that is unrelated to the underlying p=REJECT/QUARANTINE concept, doesn't make sense. Brandon On Wed, Feb 3, 2016 at 5:35 AM, Wiley, Glen < [email protected] > wrote: 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] > Date: Tuesday, February 2, 2016 at 7:51 PM To: Wiley Glen < [email protected] > Cc: " [email protected] " < [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] > wrote: <blockquote> . . .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: <blockquote> 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. . . </blockquote> 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 </blockquote> _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
