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

Douglas Otis dotis at mail-abuse.org
Sun Jun 24 18:08:11 PDT 2012


On 6/20/12 11:14 AM, Murray Kucherawy wrote:
> On shared IP addresses, there are two considerations:
> 
> 1.  DKIM is agnostic to IP addresses.  That means for shared IP 
> addresses, only authorized clients can possibly add valid 
> signatures. 2.  A client behind a shared IP address is most likely 
> (when sending legitimately) to send via its service provider's
> MTA, and not directly.  TLS in that case would be useful to
> authenticate the client to the service provider, but not to the
> recipient.  It's the latter spot where DMARC is in effect.

Dear Murray,

Many organizations apply TLS policy for specific outbound MTAs to
mitigate social engineering attack.  DMARC can extend such protections
in a scalable manner to benefit a larger community.

> On required TLS: There are really two hops of interest here,
> namely one between the author and its service provider's MTA, and
> the one from that MTA to the recipient.  If you use TLS to secure
> the transport in both cases, you meet the regulatory requirement
> you're talking about, but still it's only that last hop that's of
> interest to DMARC.  SPF and/or DKIM have a high likelihood of
> success there, so it's still unclear what TLS brings in terms of
> incremental improvement.  Where the direction is reversed, such as
> something transactional or a notification back to the user, only
> the second half of that model exists, but the logic is the same.

DKIM may fail due to non-malicious change with a small percentage of
cases.  Although SPF was intended as a fall-back, this protocol is
unable to cope with IPv6 related CGNs or UTF-8 encoded mail
parameters, both of which will play an increasing role, especially in
Asia.

> (Also, I don't think bank.example.com is really too concerned
> about authenticating mail from your home account; it's really the
> other direction that's interesting, in which case your BYOD isn't
> part of the equation.)

Establishing email validation or authentication requires years.  Not
preventing erroneous rejections of important transactional email is
likely to result in the inaction of desired DMARC policy as has been
seen with ADSP/discardable, and SPF/-all.

> A service provider adding to its SPF policy the entire IP space
> from which BYODs will be seen to connect is inviting degraded
> reputation. This goes for your hotel example too.  I don't think
> that's likely to happen.

Reputation of what specifically?  Per IP address, per CIDR, per ASN,
or per Domain?  If this is per IP address, how would that represent a
deterrent?

> Your key verification ideas seem to be jumbled.  DANE is, to 
> paraphrase, the storage of key fingerprints in the DNS as a way of 
> associating a certificate with a domain in some way that's more 
> authoritative than "that guy said so".  Storage of public keys in
> DNS is a DKIM thing, not a DANE thing.

Publishing a public key is not exclusive to DKIM.  TLS/ATPS also
offers a fallback for non-malicious message modifications.

> Repurposing DKIM as you described seems like it would be redundant
> to what DANE already does.
> 
> I wouldn't expect an ISP to authorize use of its domain by any 
> arbitrary hotel connection that appears.  I would expect hotel 
> connections to send mail through some other authorized mail
> server, such as a VPN back to home base.  That will cause the mail
> to go out through a stable relay, where SPF and DKIM are reliable.
> Anything else is a vector for abuse.

Rather than expecting receivers to somehow know which mailing-lists
may carry messages from a domain asserting a DMARC policy, the DKIM
signer can cull out needed exceptions to protect third-party ESPs who
they hope will assert their desired rejections.  Since such policy is
to benefit the From domain, this domain should publish exception
information within a small and single transaction.

http://tools.ietf.org/html/rfc6541

> I'm not sure I agree that the weakening of SPF through shared 
> addresses is a concern, because I don't think people are using SPF 
> that way.  A domain owner that puts shared IP address ranges in
> its SPF record is begging for degraded reputation at both the IP
> and domain level.  Instead of trying to balance better SPF coverage
> with weakened results, you have the option of using DKIM as well
> since it's route-agnostic.  The SPF record for "comcast.net" for
> example appears to contain nothing bigger than a /23, which I'm
> sure doesn't include any of their shared IP space.  DMARC only
> requires that one of the two pass.

At least with ATPS, source reputation and policy exceptions should be
viewed separately.  As currently defined, SPF may impose significant
overhead and not properly deal with infrastructural change.

> To boil it all down: DMARC looks at a message and says "Did this
> come from an authorized IP address (SPF), or via an authorized
> handler (DKIM)?"  I still don't see what TLS brings to that picture
> to make it more complete.

TLS and DKIM are both route-agnostic.  When used in conjunction with
ATPS, these two protocols offer a safer mechanism that receivers can
employ where SENDERS carry the burden of indicating which mailing-list
or third-party vendor should be excused from rejection based upon
policy.  Such exceptions will likely be placed in folders configured
for mailing-list or receive similar annotations.

It seems prudent for DMARC to define how ATPS and TLS may also satisfy
policy requirements.  Specification should consider changes already
taking place, and attempt to mitigate their impact.

Regards,
Douglas Otis


More information about the dmarc-discuss mailing list