Discussion:
RFC 6686 on Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments
Scott Kitterman
2012-07-20 17:15:23 UTC
Permalink
Subject: [spfbis] RFC 6686 on Resolution of the Sender Policy Framework (SPF)
and Sender ID Experiments
Date: Friday, July 20, 2012, 10:12:58 AM
From: rfc-***@rfc-editor.org
To: ietf-***@ietf.org, rfc-***@rfc-editor.org
CC: ***@ietf.org, rfc-***@rfc-editor.org


A new Request for Comments is now available in online RFC libraries.


RFC 6686

Title: Resolution of the Sender Policy
Framework (SPF) and Sender ID Experiments
Author: M. Kucherawy
Status: Informational
Stream: IETF
Date: July 2012
Mailbox: ***@gmail.com
Pages: 12
Characters: 26421
Updates/Obsoletes/SeeAlso: None

I-D Tag: draft-ietf-spfbis-experiment-11.txt

URL: http://www.rfc-editor.org/rfc/rfc6686.txt

In 2006, the IETF published a suite of protocol documents comprising
the Sender Policy Framework (SPF) and Sender ID: two proposed email
authentication protocols. Both of these protocols enable one to
publish, via the Domain Name System, a policy declaring which mail
servers were authorized to send email on behalf of the domain name
being queried. There was concern that the two would conflict in some
significant operational situations, interfering with message
delivery.

The IESG required all of these documents (RFC 4405, RFC 4406, RFC
4407, and RFC 4408) to be published as Experimental RFCs and
requested that the community observe deployment and operation of the
protocols over a period of two years from the date of publication to
determine a reasonable path forward.

After six years, sufficient experience and evidence have been
collected that the experiments thus created can be considered
concluded. This document presents those findings. This document
is not an Internet Standards Track specification; it is
published for informational purposes.

This document is a product of the SPF Update Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
http://www.ietf.org/mailman/listinfo/ietf-announce
http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-***@rfc-editor.org. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC
Don Lee
2012-08-07 16:50:44 UTC
Permalink
Anyone know about this:

http://www.dmarc.org/

I've spent about 10 minutes looking into it, and it looks like a worthwhile
effort. Other opinions?

-dgl-
Michael Deutschmann
2012-08-11 19:54:53 UTC
Permalink
Post by Don Lee
http://www.dmarc.org/
I recently perused it. I'd have to do a more careful read of the draft
before I do anything to my DNS in response, but from what I can tell there
seems no point. DMARC moves in precisely the wrong direction.

SPF's problem is that it false positives on all traditionally forwarded
mails. Hence SPF can only actually halt the delivery of forgeries when
both the recipient and the putative sender are unafraid of blocked
forwards.

DKIM/ADSP's problem is that it false positives on all mailing list
traffic. Thus it becomes crazy to publish anything other than
"dkim=unknown" when you post to mailing lists, but that means no actual
forgeries will be blocked either.

A protocol that avoids either problems could easily be developed -- it
would just have to use DKIM signatures like ADSP, but bind those
signatures to the MAIL FROM: (not header From:) like SPF.

DMARC does the opposite. Its "SPF alignment" feature demands that MAIL
FROM: be more similar to the Header From: than a mailing list can manage.
It's the drawback of SPF and the drawback of ADSP in one package.

It would appear that since I do post to mailing lists, there is no point
in publishing DMARC (or ADSP), even though I already publish SPF and
DKIM-sign outgoing mail.

I can see the rationale for ADSP and DMARC's insanity though. Under both
vanilla SPF and my hypothetical fused system, a phisher can freely lie in
*the address shown to an unsuspicious end user* so long as he doesn't lie
in his bounce address. But preventing that without breaking mailing lists
is really hard; it would require either that the recipient maintain a
whitelist of mailing lists he subscribes to, or that the putative-sender
publishes a whitelist of mailing lists he posts to.

In the meantime, just stopping forgery of the bounce address is still a
great improvement. Naive end users may never see it, but if bad mail
arrives SPF-pass, you at least have a solid identity you can punish for
it.

---- Michael Deutschmann <***@talamasca.ocis.net>
Tim Draegen
2012-08-12 15:02:48 UTC
Permalink
Post by Michael Deutschmann
Post by Don Lee
http://www.dmarc.org/
I recently perused it. I'd have to do a more careful read of the draft
before I do anything to my DNS in response, but from what I can tell there
seems no point. DMARC moves in precisely the wrong direction.
Cliff notes version:

- Domain Owners get new visibility into which servers on the internet are emitting email on behalf of their domains. Even if you never intend to put quarantine or reject policies into place, the feedback piece alone is incredibly valuable.

- The above mentioned feedback allows complex organizations to accurately deploy SPF and DKIM across their email streams. Email receivers need this accuracy or else policies cannot be safely enforced.

- DMARC is aimed at email streams that are highly phished. If you're a large financial organization and you're under attack, DMARC is a viable way to create email streams that are resilient to phishing attacks.

- Furthermore, receivers want to move to a model of being able to positively identify legitimate email instead of relying on the dominant "remove bad stuff" model. Doing so allows receivers to process and render authenticated email in new ways.

DMARC has already shown great utility in the real world, so it's odd to read things like "DMARC moves in precisely the wrong direction" and "I can see the rationale for ADSP and DMARC's insanity". I recommend reading through some of the introductory materials on dmarc.org; you'll find descriptions of the problems DMARC is attempting to solve, along with links to even more resources.

HTH,
=- Tim
Michael Deutschmann
2012-08-17 01:52:25 UTC
Permalink
Post by Tim Draegen
DMARC has already shown great utility in the real world, so it's odd to
read things like "DMARC moves in precisely the wrong direction" and "I can
see the rationale for ADSP and DMARC's insanity".
I was specific as to what I consider insane - the targetting criteria.
You cannot select anything for rejection or quarantine without also
selecting all legitimate mailing list posts for the same treatment. This
was broken in ADSP and DMARC has done nothing to fix it.

Sure, an *option* to say "No one at this domain posts to a
signature-breaking mailing list" would be useful to the rare sender
domain that can make the claim, ensuring that even phish dolled up to
look (to the filters) like something the recipient subscribed to would be
reliably blocked.

But making it a requirement ensures that most domains can never deploy a
non-null DMARC policy. That then means there is little incentive to
deploy DMARC at the receiverside.

In contrast, the *opposite* way to "combine SPF and DKIM" would have been
quite helpful. That is, provide a way for a domain to signal that
messages bearing its Return-path: always have a corresponding DKIM
signature, while saying nothing about messages with its From: but a third
party's Return-path:. This would have no SPF forwarding problem and no
DKIM mailing list problem.

---- Michael Deutschmann <***@talamasca.ocis.net>
Scott Kitterman
2012-08-17 06:31:42 UTC
Permalink
Post by Michael Deutschmann
Post by Tim Draegen
DMARC has already shown great utility in the real world, so it's odd to
read things like "DMARC moves in precisely the wrong direction" and "I can
see the rationale for ADSP and DMARC's insanity".
I was specific as to what I consider insane - the targetting criteria.
You cannot select anything for rejection or quarantine without also
selecting all legitimate mailing list posts for the same treatment. This
was broken in ADSP and DMARC has done nothing to fix it.
Sure, an *option* to say "No one at this domain posts to a
signature-breaking mailing list" would be useful to the rare sender
domain that can make the claim, ensuring that even phish dolled up to
look (to the filters) like something the recipient subscribed to would be
reliably blocked.
But making it a requirement ensures that most domains can never deploy a
non-null DMARC policy. That then means there is little incentive to
deploy DMARC at the receiverside.
In contrast, the *opposite* way to "combine SPF and DKIM" would have been
quite helpful. That is, provide a way for a domain to signal that
messages bearing its Return-path: always have a corresponding DKIM
signature, while saying nothing about messages with its From: but a third
party's Return-path:. This would have no SPF forwarding problem and no
DKIM mailing list problem.
They've got a target audience and most domains aren't in it. I think that's
fine as long as they are clear about it.

I've published DMARC records with a policy of none for the feedback reports.
Those I think are potentially useful for everyone. They are a great part of
the answer to "how do I check if I got my SPF records right". That's been a
tough one for a long time.

Scott K
Michael Deutschmann
2012-08-18 22:29:57 UTC
Permalink
Post by Scott Kitterman
They've got a target audience and most domains aren't in it. I think
that's fine as long as they are clear about it.
The problem with that is that with only phish-target domains deploying it
senderside, there is too little incentive to deploy it receiverside.

Despite the fact that DMARC should have no false positives, it seems
pointless because the expected amount of bad mail it would supress in a
year comes to about zero. A lot of bad mail is forged, but only actual
phish is forged in the name of a phish-fearing domain.
Post by Scott Kitterman
I've published DMARC records with a policy of none for the feedback reports.
Which still doesn't incentivize anyone to deploy it receiverside.


I notice some people in the DKIM camp seem to think that once their
standards advance far enough, then total receiverside deployment will just
appear by magic. Although they apparently also think this deployment will
be done by a jerk literal genie who will build the most porous possible
configuration that still complies with the letter of the RFC.

(That's the only way to explain Douglas Otis's panic on the IETF list over
his theoretical "double From:" exploit.)

---- Michael Deutschmann <***@talamasca.ocis.net>
Bob Tinkelman
2012-08-17 08:47:14 UTC
Permalink
Post by Scott Kitterman
I've published DMARC records with a policy of none for the feedback reports.
Those I think are potentially useful for everyone. They are a great part of
the answer to "how do I check if I got my SPF records right". That's been a
tough one for a long time.
Are you getting feedback reports? If so, from whom?

It's not clear to me how to check what recipients have implemented DMARC.

- Bob
Scott Kitterman
2012-08-18 03:00:20 UTC
Permalink
Post by Bob Tinkelman
Post by Scott Kitterman
I've published DMARC records with a policy of none for the feedback
reports. Those I think are potentially useful for everyone. They are a
great part of the answer to "how do I check if I got my SPF records
right". That's been a tough one for a long time.
Are you getting feedback reports? If so, from whom?
It's not clear to me how to check what recipients have implemented DMARC.
Google, Yahoo!, and AOL are the big ones. I also get reports from Linked In,
and 126.com/163.com (large Chinese ISP). I understand XS4All in .nl has
implemented, but I don't think I've gotten anything from them.

So far I only get the forensic (per message) feedback reports from
126.com/163.com.

Scott K
Ian Eiloart
2012-08-20 11:27:59 UTC
Permalink
Post by Michael Deutschmann
a phisher can freely lie in
*the address shown to an unsuspicious end user*
Actually, there's no such thing for many recipients. Outlook 2011 for OSX (and I think 2010 and earlier for PC), iOS Mail, Yahoo webmail and Hotmail webmail don't display sender email addresses by default. For those webmail clients, a mouseover can reveal the From: header address, but for Outlook and iOS Mail, it's really hard to find the address even when you know how.

For some large senders, that accounts for 70% of recipients:

http://litmus.com/blog/email-client-market-share-stats-infographic-june-2012/email-client-market-share-june-2012
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
Michael Deutschmann
2012-08-21 03:08:53 UTC
Permalink
On 11 Aug 2012, at 20:54, Michael Deutschmann
Post by Michael Deutschmann
a phisher can freely lie in
*the address shown to an unsuspicious end user*
Actually, there's no such thing for many recipients. Outlook 2011 for
OSX (and I think 2010 and earlier for PC), iOS Mail, Yahoo webmail and
Hotmail webmail don't display sender email addresses by default. For those
webmail clients, a mouseover can reveal the From: header address, but for
Outlook and iOS Mail, it's really hard to find the address even when you
know how.
So they only show the display name.

Well, then the phishers have free reign -- they can evade all technical
anti-forgery measures by simply not forging. They just have to use their
real domain in all headers including From:

Only a display-name anti-forgery protocol can help, and that is
problematic. To their credit, DMARC's specification draft at least
discusses it, but only to point out they have no idea how to plug the
hole, and hope someone else will.

Anyhow, it underscores my point that ADSP/DMARC's obsession with
protecting only the most visible header (From:) is insane.

SPF's forwarding problem is annoying, but only indirectly. I've been
publishing -all since 2004 and only once encountered a domain bouncing my
mails and blaming SPF. It only hurts because my false negative rate is
boosted by cowards who use ?all unnecessarily.

But the ADSP/DMARC mailing list problem, which could be trivially avoided
by joining SPF in protecting the bounce address instead, is fatal.

---- Michael Deutschmann <***@talamasca.ocis.net>
Ian Eiloart
2012-08-21 12:00:49 UTC
Permalink
Post by Michael Deutschmann
On 11 Aug 2012, at 20:54, Michael Deutschmann
Post by Michael Deutschmann
a phisher can freely lie in
*the address shown to an unsuspicious end user*
Actually, there's no such thing for many recipients. Outlook 2011 for
OSX (and I think 2010 and earlier for PC), iOS Mail, Yahoo webmail and
Hotmail webmail don't display sender email addresses by default. For those
webmail clients, a mouseover can reveal the From: header address, but for
Outlook and iOS Mail, it's really hard to find the address even when you
know how.
So they only show the display name.
Well, then the phishers have free reign -- they can evade all technical
anti-forgery measures by simply not forging. They just have to use their
Only a display-name anti-forgery protocol can help, and that is
problematic. To their credit, DMARC's specification draft at least
discusses it, but only to point out they have no idea how to plug the
hole, and hope someone else will.
Anyhow, it underscores my point that ADSP/DMARC's obsession with
protecting only the most visible header (From:) is insane.
SPF's forwarding problem is annoying, but only indirectly. I've been
publishing -all since 2004 and only once encountered a domain bouncing my
mails and blaming SPF. It only hurts because my false negative rate is
boosted by cowards who use ?all unnecessarily.
But the ADSP/DMARC mailing list problem, which could be trivially avoided
by joining SPF in protecting the bounce address instead, is fatal.
Well, I think we need to lobby the mail client developers to show the email address, since it's critical. Heck, some don't even show the email address when you reply to the email. It's terrifying!

But, the real responsibility lies with those who (should) have competence - the MTA operator.

What both SPF and DKIM give us are ways of fixing reputation systems to domains or email addresses. And, if mailing lists break DKIM, that doesn't much matter - it's the list's reputation that recipients should care about. They need to add their own DKIM signatures.

DMARC gives senders feedback about the effects of their publication of SPF and DKIM records. That's useful in itself, and my initial reaction is that we should adopt it.
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
Michael Deutschmann
2012-08-21 21:16:10 UTC
Permalink
Post by Ian Eiloart
Well, I think we need to lobby the mail client developers to show the
email address, since it's critical. Heck, some don't even show the email
address when you reply to the email. It's terrifying!
But, the real responsibility lies with those who (should) have
competence - the MTA operator.
The only thing the MTA could do is rewrite the From: to omit any display
names. But that's problematic, since the DKIM signature requires that
From: be preserved byte for byte. The MUA would be unable to verify the
signature, and just have to trust that the MTA checked it before mangling
the From:.
Post by Ian Eiloart
And, if mailing lists break DKIM, that doesn't much matter - it's the
list's reputation that recipients should care about. They need to add
their own DKIM signatures.
They often do, but it doesn't help against ADSP or DMARC because the
mailing list does not own the private key needed to make a new signature
corresponding to the From:.

If ADSP/DMARC were sane like SPF, and declared a signature corresponding
to the Return-path: to be adequate, then this would work fine.

---- Michael Deutschmann <***@talamasca.ocis.net>

Dotzero
2012-08-07 17:05:10 UTC
Permalink
On Tue, Aug 7, 2012 at 12:50 PM, Don Lee
Post by Don Lee
http://www.dmarc.org/
I've spent about 10 minutes looking into it, and it looks like a worthwhile
effort. Other opinions?
-dgl-
I'm one of the participants in dmarc.org (I beleive there are some
others who are lurking here as well. The effort basically came out of
the experience that a handful of senders and large mailbox providers
has doing something similar through private channels. The policy
assertion piece may not be for all senders but the reporting part
allows visiblity into auth failures where there didn't use to be any
visibility. For validators/receivers it is useful but not as usefulas
when there is greater adoption by senders. By combining the use of SPF
and DKIM you reduce false positives.
Scott Kitterman
2012-08-07 17:20:08 UTC
Permalink
Post by Dotzero
On Tue, Aug 7, 2012 at 12:50 PM, Don Lee
Post by Don Lee
http://www.dmarc.org/
I've spent about 10 minutes looking into it, and it looks like a worthwhile
effort. Other opinions?
-dgl-
I'm one of the participants in dmarc.org (I beleive there are some
others who are lurking here as well. The effort basically came out of
the experience that a handful of senders and large mailbox providers
has doing something similar through private channels. The policy
assertion piece may not be for all senders but the reporting part
allows visiblity into auth failures where there didn't use to be any
visibility. For validators/receivers it is useful but not as usefulas
when there is greater adoption by senders. By combining the use of SPF
and DKIM you reduce false positives.
I agree, with the slight caveat that the way the DMARC spec is written now, it
says that a DMARC policy record should override other policies, so if I
publish a DMARC record to get feedback, I'm at the same time telling receivers
not to take a policy action based on SPF fail. This is a problem that I think
will be addressed, but it hasn't been yet.

Scott K
Don Lee
2012-08-07 17:46:21 UTC
Permalink
Post by Scott Kitterman
Post by Dotzero
On Tue, Aug 7, 2012 at 12:50 PM, Don Lee
Post by Don Lee
http://www.dmarc.org/
I've spent about 10 minutes looking into it, and it looks like a worthwhile
effort. Other opinions?
-dgl-
I'm one of the participants in dmarc.org (I beleive there are some
others who are lurking here as well. The effort basically came out of
the experience that a handful of senders and large mailbox providers
has doing something similar through private channels. The policy
assertion piece may not be for all senders but the reporting part
allows visiblity into auth failures where there didn't use to be any
visibility. For validators/receivers it is useful but not as usefulas
when there is greater adoption by senders. By combining the use of SPF
and DKIM you reduce false positives.
I agree, with the slight caveat that the way the DMARC spec is written now, it
says that a DMARC policy record should override other policies, so if I
publish a DMARC record to get feedback, I'm at the same time telling receivers
not to take a policy action based on SPF fail. This is a problem that I think
will be addressed, but it hasn't been yet.
Scott K
My brief reading is that it is a complementary, and helpful standard, not
one that is generally in conflict with SPF (or DKIM).

SPF, DKIM, and other proposals seems to me to have been looking
for a "silver bullet" and have turned out to need broader support from
various stakeholders.

It looks to me like DMARC is part of that helpful, cooperative evolution,
and will help everyone adopt and deploy these technologies.

-dgl-
Scott Kitterman
2012-08-07 17:51:24 UTC
Permalink
Post by Don Lee
Post by Scott Kitterman
Post by Dotzero
On Tue, Aug 7, 2012 at 12:50 PM, Don Lee
Post by Don Lee
http://www.dmarc.org/
I've spent about 10 minutes looking into it, and it looks like a worthwhile
effort. Other opinions?
-dgl-
I'm one of the participants in dmarc.org (I beleive there are some
others who are lurking here as well. The effort basically came out of
the experience that a handful of senders and large mailbox providers
has doing something similar through private channels. The policy
assertion piece may not be for all senders but the reporting part
allows visiblity into auth failures where there didn't use to be any
visibility. For validators/receivers it is useful but not as usefulas
when there is greater adoption by senders. By combining the use of SPF
and DKIM you reduce false positives.
I agree, with the slight caveat that the way the DMARC spec is written now,
it says that a DMARC policy record should override other policies, so if I
publish a DMARC record to get feedback, I'm at the same time telling
receivers not to take a policy action based on SPF fail. This is a
problem that I think will be addressed, but it hasn't been yet.
Scott K
My brief reading is that it is a complementary, and helpful standard, not
one that is generally in conflict with SPF (or DKIM).
SPF, DKIM, and other proposals seems to me to have been looking
for a "silver bullet" and have turned out to need broader support from
various stakeholders.
It looks to me like DMARC is part of that helpful, cooperative evolution,
and will help everyone adopt and deploy these technologies.
I agree.

It is, however, a relatively young concept and there's still work to be done
to mature it.

Scott K
Loading...