[dmarc-discuss] Is DMARC the right place for SMTP-TLS policy and reporting?

Franck Martin fmartin at linkedin.com
Tue Jun 19 22:37:40 PDT 2012

The thing with DMARC is that any verification need to pass for DMARC to pass. So you are not gaining any added security by using TLS.

Also this is not about secure communications, but linking an email to a domain.

May be, the authentication-result header should indicate when tls was employed, and that would serve your purpose better?
From: dmarc-discuss-bounces at blackops.org [dmarc-discuss-bounces at blackops.org] on behalf of Chris Lamont Mankowski [makerofthings77 at gmail.com]
Sent: Tuesday, June 19, 2012 10:11 PM
To: John R. Levine
Cc: dmarc-discuss at dmarc.org
Subject: Re: [dmarc-discuss] Is DMARC the right place for SMTP-TLS policy and reporting?

I don't think it's accurate to say this is about compliance verses S/MIME because that conversation is tangential to why I started this thread;  I want to refocus on the part where SPF authenticates the sender, and DKIM reports the outcome.

Considering that TLS occurs at approximately the same hop when a SPF record is validated, and if SPF will be reported on via DKIM why shouldn't TLS be evaluated similarly?   TLS provides an alternative method of validation to SPF that may be complimentary in some situations.  In situations such as legal or financial documents it could enhance overall security and trust in the message.

John quoted my comment on how Google's planned MUA will show a special icon for validated messages.  Continuing on that train of thought:  If TLS policy is excluded from the DMARC spec, and MUAs end up showing a validation icon, does that imply that when a message is sent TLS Secured users will have yet another icon?

I'm envisioning a situation where a single email has so many validation icons it looks like the message was sponsored by Nascar.  Users will be overwhelmed and won't be able to tell the difference.

The last time a significant user change was implemented someone invented the EV HTTPS certificate (the green bar in the URL) that provides no technical value other than the insurance that only applies to e-commerce sites.  I want to prevent a repeat of what I consider misguided history and add some real security backbone to what is displayed to the end user.


  *   I want to define the version of TLS that was used (TLS 1.1 or newer in my case)
  *   The cipher must be RSA2048 or DHE
  *   The hash must be SHA2 or newer
  *   The subject name (or SAN) must match the sending domain
  *   (optional) the cert must be trusted in the root store
  *   (optional) the cert must have a thumbprint equal to xxx (allows for self signed certs)
  *   (optional) DNSSec is used for all certificate operations (to allow full compatibility with .gov)

I think DMARC can cause great things in MUAs to occur, and I'm elated it's being proposed but see that incorporating TLS policy and reporting as an essential component before anything is displayed to the end user as being secure.

On Wed, Jun 20, 2012 at 12:38 AM, John R. Levine <johnl at iecc.com<mailto:johnl at iecc.com>> wrote:
S/MIME could be an option for some industries, but I'm a finance vertical
and we are required to have a supervisory compliance agent review our
electronic communications.  (See Smarsh.com or Proofpoint Archive as an

Hmmn.  If this is about compliance, I think it's considerably outside the scope of what DMARC is intended for.  But I'll defer to Murray to explain.

John Levine, johnl at iecc.com<mailto:johnl at iecc.com>, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://medusa.blackops.org/pipermail/dmarc-discuss/attachments/20120620/1b32d29b/attachment.htm>

More information about the dmarc-discuss mailing list