Subject: [dmarc-ietf] DMARC's purpose

From: Pierre-Alain Dupont <[email-masked]>
Date: Thu, 10 Apr 2014 15:16:42 +0200

Hi folks,
After reading a few articles like
http://thehackernews.com/2014/04/yahoos-new-dmarc-policy-destroys-every.html,
I came to wonder as to why a soon-to-be standardized project came to on
purpose break a huge part of the reality of today's emails.

>From what I can read on this ML, the subject of forwarders/ML has been
discussed here numerous times, and basically, the answer is somehow
either of:

  * We do not care, forwarding shouldn't exist anyway.
  * Well, this is out of the scope of DMARC.
  * Maybe you could white-list the more prominent ones or implement a
    way to do it automatically.

Neither of those answers is really acceptable. The only credible one is
the third (that, or this protocol is not meant to be really used and is
a purely academic work).

Basically, it appears to me as if you are designing a protocol that
would be, on purpose, only accessible to big firms that can have the
manpower to do such a white-listing and/or do not really about their
captive users. Many people appear to believe that it is acceptable to
lose 2% legitimate emails... Well, it is not.
Moreover, it will introduce a bias toward ML providers that are widely
white-listed and others, that can in fact no longer appear as they are
already blocked. Again, I see a pattern of saying "emailing would be
better if there were only a few providers".

I am really wondering as to what is your aim here. Reducing spam is a
great goal, but not by sacrificing so much.

I know there has been discussion as to whether this should be an IETF
WG. Well, the answer is no. Definitely no. After all, the mission of the
IETF is to make the Internet work better, and purposely excluding a
section of the Internet is not a way to do it.

Regards,
PA.Dupont

---

From: John Sweet <[email-masked]>
Date: Thu, 10 Apr 2014 06:59:41 -0700

I see the competing "answers" breaking down differently:

 - Mailing list implementation/practice must change to support From-header
alignment
 - Never publish a p=reject policy for a domain with human (non-automated)
senders

"Whitelist known-good MLs" seems to me to be an effective way to eliminate
the use of MLs entirely, since the number of lists, and of entities who
must whitelist them, gets rather large rather quickly.

In reaction to "MLs must change," I've seen, "Sure, I'll change -- to block
all memberships/posts from addresses with p=reject policies."

I've never heard DMARC proposed as a spam solution, only as a phishing
solution. In that respect I think it's been very successful.

On Thu, Apr 10, 2014 at 6:16 AM, Pierre-Alain Dupont <[email-masked]> wrote:

> discussed here numerous times, and basically, the answer is somehow either
> of:
>
>    - We do not care, forwarding shouldn't exist anyway.
>    - Well, this is out of the scope of DMARC.
>    - Maybe you could white-list the more prominent ones or implement a
> the third (that, or this protocol is not meant to be really used and is a
> purely academic work).
>
> Basically, it appears to me as if you are designing a protocol that would
> be, on purpose, only accessible to big firms that can have the manpower to
> do such a white-listing and/or do not really about their captive users.
> Many people appear to believe that it is acceptable to lose 2% legitimate
> emails... Well, it is not.
> already blocked. Again, I see a pattern of saying "emailing would be better
> if there were only a few providers".
>
> I know there has been discussion as to whether this should be an IETF WG.
> Well, the answer is no. Definitely no. After all, the mission of the IETF
> is to make the Internet work better, and purposely excluding a section of
> the Internet is not a way to do it.
>
> Regards,
> PA.Dupont
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

---

From: Dave Crocker <[email-masked]>
Date: Thu, 10 Apr 2014 09:04:39 -0500

On 4/10/2014 8:59 AM, John Sweet wrote:
>   - Mailing list implementation/practice must change to support
> From-header alignment

Just to be clear, WRT SPF, that means never being able to specify an 
address for return notifications, other than the author's address.  No 
"delegating" the handling of such operational aspects of a message.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: John Sweet <[email-masked]>
Date: Thu, 10 Apr 2014 07:55:17 -0700

I thought that's what the Return-Path: was for.

I understand that MLs want to field bounces so they can track and inhibit
certain recipients, not to mention shield senders from (possibly very many)
bounces in response to a single post. The vacation autoresponses alone can
get very tedious very quickly. I'm not clear on how SPF alignment prevents
this.

My humblest apologies if you already covered the particulars in an earlier
message, and I missed it.

---

From: Jim Fenton <[email-masked]>
Date: Thu, 10 Apr 2014 08:47:27 -0700

On 04/10/2014 06:16 AM, Pierre-Alain Dupont wrote:
> I came to wonder as to why a soon-to-be standardized project came to
> on purpose break a huge part of the reality of today's emails.

This highlights one of the issues with the IETF publication process:
many people assume that anything with an RFC number is an IETF standard.
It was my understanding from Murray's message of March 26 that DMARC was
being considered as an informational RFC, which of course is not a standard.

More broadly:  I'm not an expert on IETF publication criteria, but I
hope that, especially given this confusion, controls are in place to
protect against the publication of informational RFCs that might be
harmful in some respect.

-Jim

---

From: Kurt Roeckx <[email-masked]>
Date: Thu, 10 Apr 2014 19:07:19 +0200

>  - Mailing list implementation/practice must change to support From-header

So that would mean that all mails on a mailling listshould
rewrite the From so that it's appears to come from someone in the
domain of the maillinglist?

Kurt

---

From: Dave Crocker <[email-masked]>
Date: Thu, 10 Apr 2014 12:11:27 -0500

> I thought that's what the Return-Path: was for.

Ignoring the SPF hack/enhancement to use rfc5321.EHLO rather than 
rfc5321.MailFrom, SPF aligns with MailFrom.

Return-Path is an 822-level copy of MailFrom, created at delivery time.

So, no, it no longer have a delegated address.

> I understand that MLs want to field bounces so they can track and
> inhibit certain recipients, not to mention shield senders from (possibly
> very many) bounces in response to a single post. The vacation
> autoresponses alone can get very tedious very quickly. I'm not clear on
> how SPF alignment prevents this.

My observation about this imposing a rigidity for the MailFrom command 
was meant as a universal effect, not merely one relevant to list processing.

d/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 10 Apr 2014 12:19:09 -0500

> being considered as an informational RFC, which of course is not a standard.

Over the months there has been a variety of paths considered for the 
DMARC base spec.  Someone thinking that it's intended for standards 
status isn't necessarily "misunderstanding"; they might merely not be 
current.

> protect against the publication of informational RFCs that might be

1.  The confusion some people have about the meaning of RFC vs. IETF 
'standard' is irrelevant to the current discussion.  Yes, some people 
are confused.  But as often as it gets cited over the years, it has 
never been demonstrated to cause real problems of any significance.

2.  Publication of Informational RFCs submitted through the "Independent 
" stream -- which is independent of the IETF-managed stream -- is not 
based on the sorts of content control you postulate.  Nor should it be. 
  The kinds of control in place are roughly the same as they've been 
forever and, again, while some such documents cause some people 
discomfort, it, too, has not been demonstrated to cause serious problems.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 10 Apr 2014 10:44:08 -0700

> protect against the publication of informational RFCs that might be

I don't think it's a bad idea to publish things that have potentially
negative side effects as long as they're well documented.  If that's flatly
disallowed, then a lot of good but incomplete ideas will never see the
light of day.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Thu, 10 Apr 2014 12:43:44 -0500

On 4/10/2014 12:44 PM, Murray S. Kucherawy wrote:
> negative side effects as long as they're well documented.  If that's
> flatly disallowed, then a lot of good but incomplete ideas will never
> see the light of day.

Those are what get standardized...

d/

---

From: John Sweet <[email-masked]>
Date: Thu, 10 Apr 2014 10:46:19 -0700

I was intentionally vague, since several distinct changes have been
proposed along those lines. That's definitely one of them. The general
objection covers all of them.

On Thu, Apr 10, 2014 at 10:07 AM, Kurt Roeckx <[email-masked]> wrote:

> From-header

---

From: Matt Simerson <[email-masked]>
Date: Thu, 10 Apr 2014 10:47:30 -0700

On Apr 10, 2014, at 10:44 AM, Murray S. Kucherawy <[email-masked]> wrote:

> I don't think it's a bad idea to publish things that have potentially negative side effects as long as they're well documented.  If that's flatly disallowed, then a lot of good but incomplete ideas will never see the light of day.

+1

http://en.wikipedia.org/wiki/Tragedy_of_the_commons

Matt

---

From: Franck Martin <[email-masked]>
Date: Thu, 10 Apr 2014 15:35:47 -0500 (CDT)

Some random thoughts.... 

-Yahoo policy change did not break all mailing lists, for instance most lists at apache.org are fine. Creating hyperbole drama does not offer tools to solve problems. 
-I remember a time, when adding a tag in the subject line was frown upon at IETF... even sending email with a mime/HTML part would get you many angry emails. At that time, if DKIM had existed, everything would have been fine, but lists changed... 
-Some list management software are not taking advantage of extended SMTP error codes, something that any ESP do, the SOFT vs HARD bounce concept. 
-RFC like anything human, can be changed, overwritten, etc... There is nothing which is sacred. I'm not saying that change should be easy, I'm just saying that change is not impossible. Laws have been turned, overturned and returned... This is part of progress.... and change creates pain. 
-IETF recent focus is on pervasive monitoring, increasing security, prevent identity theft,... DMARC is a tool that helps, it is aligned with IETF recent goals. It is deployed, widely used, proven beneficial, has still some problems, lets' fix them. 
-DMARC is not a silver bullet, but denying any new technology, because bad behavior cannot be eradicated, but simply mitigated is really strange to me. 
-Convenience or Security, make a choice... 
-I heard of numbers that mailing lists traffic is 10% of overall legitimate traffic. Some DMARC adopters have seen it was less than 1%. Your mileage may vary. 
-The problem has been highlighted for a year at least. Saying you should not publish a policy p=reject for a domain with users is not useful, this is not a legal nor even a regulatory constraint and there is no such thing as the RFC police. It was bound to happen, it came earlier than expected... 
-At the time of ADSP, I don't think anyone spotted the unsubscribe collateral damage problem, people just said mailing lists cannot work with ADSP and there is nothing you can do. If the problem was limited to "you cannot receive my email when I post to the list", it would have been my problem. I experimented on DMARC.org lists and discovered the collateral damage. I shared my experience. 
-As DMARC is widely adopted (unless ADSP was), some of us decided to build tools to remediate this upcoming problem in advance. There is code in mailman 2.1.16 to make a list DMARC compliant via 2 options: one that please the people that the From: should be the original poster, one that displeases them. There is a patch to forbid people with a DMARC policy to subscribe/post to the list (not sure it is in the main code, this is not my hitch, but I respect people wanting to add it and I welcome them to work on it). I would have hoped we had a bit more time, because for instance this list is running on 2.1.15 and give or take 6 months, would have been upgraded naturally to 2.1.16 or even 2.1.17. It would have been easy for list admins to flip the switch. 
-A few lists have already been fixed very quickly, like the one run by Al, http://www.spamresource.com/2014/04/run-email-discussion-list-heres-how-to.html but there are other examples: http://groupserver.org/groups/development/messages/topic/5lLZaa1bSOyEmssFMFPeMX http://blog.threadable.com/how-threadable-solved-the-dmarc-problem , the "church list" has been fixed too, very quickly... 
-This could have been fixed a year ago, it is not like this was not a problem predicted... but until it is too late no one is motivated to fix issues in advance... 
-ISOC recently ran a survey on why operators are not present at IETF as they used to be... May be we prefer facts than judgements. We do also like bio-diversity: There is not one solution, but many, the standard is the solution most adopt eventually. IETF is making progress with anti-harassment and anti-bullying practices. 

So this is the IETF, we are engineers, we solve problems. Get working!

---

From: SM <[email-masked]>
Date: Sat, 12 Apr 2014 01:41:24 -0700

Hi Jim,
>protect against the publication of informational RFCs that might be

It has been mentioned on this mailing list that publication of the 
DMARC specification will be sought through a non-IETF stream.  There 
is a conflict review in such cases.  BCP 92 describes the details.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Sat, 12 Apr 2014 03:58:52 -0700

Hi Franck,
>Some random thoughts....

[snip]

>-IETF recent focus is on pervasive monitoring, increasing security, 
>prevent identity theft,... DMARC is a tool that helps, it is aligned 
>with IETF recent goals. It is deployed, widely used, proven 
>beneficial, has still some problems, lets' fix them.

How does DMARC help to in respect to pervasive monitoring, increasing 
security, prevent identity theft?

Regards,
-sm

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 12 Apr 2014 08:29:37 -0400

SM wrote:
> DMARC specification will be sought through a non-IETF stream. There is 
> a conflict review in such cases.  BCP 92 describes the details.
>
It does strike me that DMARC, which is currently an internet-draft, not 
even an RFC, is causing incredible disruption by its adoption, by a few 
very large players.  Methinks this indicates a serious problem, and 
raises some questions about what measures might be taken when a big 
player breaks the Internet by not playing nice.  It sure seems that IETF 
should play a role in this.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

---

From: Dave Crocker <[email-masked]>
Date: Sat, 12 Apr 2014 07:53:46 -0700

> should play a role in this.

1.  DMARC was developed by an ad hoc industry consortium.  It is already 
deployed well enough to cover an estminated 60% of the world's email 
traffic.  As such, it's status with the IETF is obviously not a gating 
factor.  So the "not even an RFC" has some formal import, but limited 
practical import.

2.  The spec is clear about how it works and what the implications are. 
  The issue with mailing lists is well-documented.

3. A specification cannot be responsible for operators that choose to 
deploy something in a way that creates problems documented in the spec.

4.  You don't say what you feel the IETF should do, nor is it obvious to 
me what role the IETF can reasonably have for this sort of deployment 
issue.

d/

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 12 Apr 2014 17:10:13 +0200

On Sat, Apr 12, 2014 at 07:53:46AM -0700, Dave Crocker wrote:
> 
> 2.  The spec is clear about how it works and what the implications are.  The
> issue with mailing lists is well-documented.

I don't agree with this.

Kurt

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 12 Apr 2014 11:17:45 -0400

Dave Crocker wrote:
> 1.  DMARC was developed by an ad hoc industry consortium.  It is 
> already deployed well enough to cover an estminated 60% of the world's 
> email traffic.  As such, it's status with the IETF is obviously not a 
> gating factor.  So the "not even an RFC" has some formal import, but 
> limited practical import.
>
So what happens to an infrastructure that is operated and governed by 
consensus, when a few large players can make major changes to the 
infrastructure while ignoring issues that don't directly effect their 
interests?

>  The issue with mailing lists is well-documented.
Well documented, perhaps.  But, see above.

> deploy something in a way that creates problems documented in the spec.
No.  But a standards process can.  (E.g., not just anybody can be domain 
registry, or enter records into the root nameservers).

> 4. You don't say what you feel the IETF should do, nor is it obvious 
> to me what role the IETF can reasonably have for this sort of 
> deployment issue.
>
As to the practicalities of what IETF can do - I kind of agree. Which 
may point to a limit of Internet governance by consensus. (Consider the 
comparable case of a radio transmitter going off frequency and causing 
interference -- that will get a very rapid institutional response, 
possibly by people who carry guns, if, for example, you jam a police band.)

As to what the IETF should do - well... at the very least the Internet 
operates on a set of standardized protocols, developed by consensus - 
and there is a formal process by which protocols develop from ideas, to 
experimental standards, to recommended, to mandatory (not many of 
those).  At the very least, there is social pressure to conform to such 
standards.  In some cases there are mechanisms that have more teeth 
(e.g., where registration of protocol numbers is required in a database 
under IANA "jurisdiction") - not just anybody can put records into the 
core nameservers, and those can always be removed (IETF sets the 
policies for a lot of the databases IANA maintains - I guess in theory 
IETF could establish a policy that says "if you don't follow these 
protocols properly, your DNS records get yanked").  I'm not sure I'm 
advocating such measures - but....

At the very least, it strikes me that the IETF should be visibly and 
publicly chastising the "ad hoc industry consortium that developed 
DMARC" and those who deployed it - as being exceptionally bad actors who:
- roundly ignored issues of major impact in developing the standard
- have deployed it in ways that are causing widespread havoc
- are rather pointedly ignoring that havoc (have you seen anybody from 
Yahoo responding?)

Miles Fidelman

---

From: Dave Crocker <[email-masked]>
Date: Sat, 12 Apr 2014 08:25:24 -0700

> infrastructure while ignoring issues that don't directly effect their

That's an excellent question.  Worthy of discussion.

Perhaps oddly, however, it is almost irrelevant to the work of the IETF, 
which is creation of technical specification.

Your question is about enforcement, not about creation.

That's an operations issue.

> registry, or enter records into the root nameservers).

That's governed by operations organizations, not the IETF.

> - are rather pointedly ignoring that havoc (have you seen anybody from

I believe the IETF has never done such a thing.  I'm pretty sure it 
shouldn't.

The more a technical organization delves into public policy and 
politics, the less it is a technical organization.  Policy and politics 
issues come to dominate.

At the least, they confuse perception of the organization.

So while there well might be worthy statements and/or actions to be 
taken, when a major actor introduces major disruption, that's not a task 
for the IETF.

d/

---

From: SM <[email-masked]>
Date: Sat, 12 Apr 2014 08:37:28 -0700

Hi Miles,
At 05:29 12-04-2014, Miles Fidelman wrote:
>It does strike me that DMARC, which is currently an internet-draft, 
>not even an RFC, is causing incredible disruption by its adoption, 
>by a few very large players.  Methinks this indicates a serious 
>problem, and raises some questions about what measures might be 
>taken when a big player breaks the Internet by not playing nice.  It 
>sure seems that IETF should play a role in this.

I do not see what IETF participants could do as the internet-draft is 
not being reviewed by the IETF.  The big player is breaking email 
sent to mailing lists.  It is not breaking the internet.  I would not 
expect any company to play nice as it is a business after all.

Regards,
-sm

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 12 Apr 2014 11:52:01 -0400

Dave Crocker wrote:
> Perhaps oddly, however, it is almost irrelevant to the work of the 
> IETF, which is creation of technical specification.
>

Well, yes and no.

It's fairly typical in the standards world for one organization to set 
standards, and designate a "registration" authority to administer 
aspects of a standard.

In the current discussion about the NTIA/ICANN transition, two examples 
of this have come up, and there are 100s more:
- ISO defines the numbering scheme for bank card and credit card 
numbers, ANSI maintains the "Issuer Identification Database"
- ISBN numbers are similarly standardized by one body, with delegated 
authority for issuing the numbers

(ANSI by the way, is a voluntary, non-profit, originally formed by a 
bunch of engineering societies.  ISO is a consortium of ANSI and other 
national level standards bodies.)

Standards bodies also commonly define certification requirements and 
mechanisms, accredit certification bodies in various ways, and establish 
remedies for false representation of certification status.

In the case of Internet protocols, IETF is the primary standards body, 
and through various MOUs has designated registration authorities for 
various things (mostly IANA).

So yes, IETF has some governance authority (technical, moral, and legal) 
in this matter, if it chooses to exercise it.
> I believe the IETF has never done such a thing.  I'm pretty sure it 

Well - arguably, the IETF (or members thereof) were pretty vocal when 
the TCP/IP vs. ISO wars were going on.

> politics, the less it is a technical organization.  Policy and 
> politics issues come to dominate.
>
Well, IEEE and ACM both have policy arms.  IEEE is both a standards 
maker and very visible on some policy issues - including some that are 
technopolitical.  (Granted that IEEEs standards efforts are relatively 
removed from their policy efforts).

> taken, when a major actor introduces major disruption, that's not a 
> task for the IETF.
>

Which then begs the question: Who's task is it?

Miles

---

From: Dave Crocker <[email-masked]>
Date: Sat, 12 Apr 2014 08:57:05 -0700

>> That's governed by operations organizations, not the IETF.

Your lengthy treatise does not appear to contain a specific proposal. 
So while the tutorial information is all well and good, how is it 
relevant to the current situation?

> the TCP/IP vs. ISO wars were going on.

It was?  What specifics are you referring to?  I don't recall the IETF 
doing anything but facilitating work on both technologies, both with 
ISODE and for network management, and later when considering choices in 
IPv6.

d/

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 12 Apr 2014 12:23:02 -0400

SM wrote:
>> not even an RFC, is causing incredible disruption by its adoption, by 
>> a few very large players.  Methinks this indicates a serious problem, 
>> and raises some questions about what measures might be taken when a 
>> big player breaks the Internet by not playing nice.  It sure seems 
>> that IETF should play a role in this.
>
> not being reviewed by the IETF.  The big player is breaking email sent 
> to mailing lists.  It is not breaking the internet.  I would not 

Well, let's see:
- DMARC is an ad-hoc group that assembled with a "common goal was to 
develop an operational specification to be introduced to the IETF for 
standardization"
(http://dmarc.org/about.html)
- DMARC.org defines the "DMARC Base Specification" with a link to 
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ - an IETF 
document
- they published an information Internet draft, that expires in October 
of this year, that starts with "This memo presents a proposal for a 
scalable mechanism by which a mail sending organization can 
express,....." https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/
- by implication, they are representing DMARC as a standards-track IETF 
specification

Publication of a "proposal" as an information Internet draft, is barely 
the first step toward an operational specification standardized by the 
IETF - yet DEMARC proponents are representing it as an IETF standard (or 
at least as going through the process).

Beyond that, let me note that the draft includes this line: "The 
enclosed proposal is not intended to introduce mechanisms that provide 
elevated delivery privilege of authenticated email." -- which, of course 
is exactly what has been done by Yahoo by publishing "p=reject" in its 
DMARC policy, and by those who've chosen to honor it.

So, it seems to me that it is entirely legitimate for IETF to officially 
be on the record that:
1. DMARC is NOT even close to an IETF standard
2. It has not been subject to any of the technical and operational 
vetting associated with the progression of a specification through the 
IETF standardization process
3. The means by which Yahoo has deployed DMARC, and the choice of 
several other large ISPs to honor the p=reject policy, is not in keeping 
with the practice of measured testing and incremental deployment of IETF 
standards, as they progress from proposal, to experimental, to optional, 
to recommended, to mandatory

For reasons of technical and professional integrity, IETF should be 
distancing itself from this debacle, very loudly and very clearly. If 
nothing else, IETF should be defending its legitimacy as the Internet's 
standards body - in the same way that Xerox and Kleenex defend their 
trademarks.

Beyond that - perhaps a strong position by IETF might have an impact on 
Yahoo's decision making.

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 12 Apr 2014 12:26:22 -0400

Dave Crocker wrote:
> ISODE and for network management, and later when considering choices 
> in IPv6.
>

All I can speak for is observing some rather load and vociferous 
commentary, and agitation, from my BBN colleagues, many of whom were 
active in IETF, during the period where GSA and DoD were trying to foist 
OSI down everyone's throats.  The technical and policy papers were 
flying fast and furious - though I can't say that any were official IETF 
documents or positions.

Miles

---

From: Dave Crocker <[email-masked]>
Date: Sat, 12 Apr 2014 09:51:29 -0700

> to recommended, to mandatory

The IETF doesn't do that sort of thing.  If it did, it would be spending 
all of its time making similar statements about a great many other 
technologies and implementations.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sat, 12 Apr 2014 09:52:49 -0700

> flying fast and furious - though I can't say that any were official IETF

Many /people/ who participated in the IETF, as were their /employers/.

The /IETF/ itself wasn't.

d/

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 12 Apr 2014 12:57:44 -0400

> The /IETF/ itself wasn't.
I believe what I said was "Well - arguably, the IETF (or members 
thereof) were pretty vocal when
the TCP/IP vs. ISO wars were going on. "

MF

---

From: SM <[email-masked]>
Date: Sat, 12 Apr 2014 10:43:55 -0700

Hi Miles,
At 09:23 12-04-2014, Miles Fidelman wrote:
>develop an operational specification to be introduced to the IETF 
>for standardization"
>https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ - an IETF document
>- they published an information Internet draft, that expires in 
>October of this year, that starts with "This memo presents a 
>proposal for a scalable mechanism by which a mail sending 
>organization can express,....." 
>https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/
>- by implication, they are representing DMARC as a standards-track 
>IETF specification

According to an article in the IETF Journal:

"The amazing show of support changed the anticipated trajectory of 
the standardization plan. Rather than request the formation of an 
IETF working group (WG) to rework the specification, the authors 
discussed possible options with the IETF Applications Area WG and its 
Area Directors. Through conversation it became clear that there were 
some paths worth considering that would more closely follow the 
accelerated adoption curve associated with the draft DMARC specification.

The end result was to ask an Applications Area Director to sponsor 
the specification as a candidate for the Standards Track, at the same 
time convening a Birds of a Feather (BoF) at IETF 87 in Berlin to 
discuss DMARC extensions and supporting materials. At the BoF, a 
charter for a proposed DMARC WG was presented, which drove a 
discussion about potential work items for the WG. Barry Leiba, one of 
the Application Area Directors, agreed to sponsor the specification 
with the caveat that messages sent to the IETF DMARC discussion list 
clearly said that community experts validated that the specification 
was ready to move to the Standards Track.

Within a month of the BoF in Berlin, a handful of supportive comments 
by industry experts were sent to the discussion list. A few items 
were called out for further work on the DMARC specification, but many 
could be disposed of during the final-call phase of the Standards 
Track. While the DMARC specification could be tuned up, it's clearly 
functional for its intended purpose and the community supports the 
process for standardizing it."

A message was posted to this mailing list this year.  It was stated that:

  "We have chosen to submit the DMARC specification via the Independent
   Submission Editor (ISE). This will have three primary effects: (1) it
   will be published with a permanent reference location; (2) it will be
   classified as Informational rather than as a Proposed Standard; (3) the
   ISE process is a much more direct path to publication."

>Publication of a "proposal" as an information Internet draft, is 
>barely the first step toward an operational specification 
>standardized by the IETF - yet DEMARC proponents are representing it 
>as an IETF standard (or at least as going through the process).

I think that the web page mentioned above is out-of-date.  As for the 
memo (I reviewed an old version last year) it represents the views of 
the authors.

>enclosed proposal is not intended to introduce mechanisms that 
>provide elevated delivery privilege of authenticated email." -- 
>which, of course is exactly what has been done by Yahoo by 
>publishing "p=reject" in its DMARC policy, and by those who've 
>chosen to honor it.

Noted.

>So, it seems to me that it is entirely legitimate for IETF to 
>officially be on the record that:
>vetting associated with the progression of a specification through 
>the IETF standardization process
>several other large ISPs to honor the p=reject policy, is not in 
>keeping with the practice of measured testing and incremental 
>deployment of IETF standards, as they progress from proposal, to 
>experimental, to optional, to recommended, to mandatory
>
>distancing itself from this debacle, very loudly and very clearly. 
>If nothing else, IETF should be defending its legitimacy as the 
>Internet's standards body - in the same way that Xerox and Kleenex 
>defend their trademarks.
>
>Beyond that - perhaps a strong position by IETF might have an impact 
>on Yahoo's decision making.

The IETF would have to publish a RFC to be officially on record.  A 
person would have to write a draft and get it through the process for 
such a RFC to be published.  The above points looks like issues for 
the [email-masked] mailing list as they are about IETF standardization 
and trademarks.

Regards,
-sm

---

From: Franck Martin <[email-masked]>
Date: Sat, 12 Apr 2014 18:30:39 +0000

Printed on recycled paper!

> On Apr 12, 2014, at 3:59, "SM" <[email-masked]> wrote:
> 
> Hi Franck,
> How does DMARC help to in respect to pervasive monitoring, increasing security, prevent identity theft?
> 

http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-spear-phishing-email-most-favored-apt-attack-bait.pdf

The recent target problem started with an email, say Krebs...

A bit of research on security and email will give you a better picture on why legitimate emails need to be better recognized.

---

From: SM <[email-masked]>
Date: Sat, 12 Apr 2014 12:16:13 -0700

Hi Franck,
>http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-spear-phishing-email-most-favored-apt-attack-bait.pdf

The above points me to an article from trendmicro.com.  I was 
interested in reading your opinion.

>A bit of research on security and email will give you a better 
>picture on why legitimate emails need to be better recognized.

Ok.

Regards,
-sm

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 12 Apr 2014 15:25:18 -0400

On Saturday, April 12, 2014 18:30:39 Franck Martin wrote:
> >> with IETF recent goals. It is deployed, widely used, proven beneficial,
> >> has still some problems, lets' fix them.> 
> http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-> papers/wp-spear-phishing-email-most-favored-apt-attack-bait.pdf
> 
> A bit of research on security and email will give you a better picture on
> why legitimate emails need to be better recognized.

I don't think anyone is disputing that.  The problem is that legitimate emails 
are being treated as illegitimate.

Scott K

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 12 Apr 2014 15:57:51 -0400

>> picture on why legitimate emails need to be better recognized.
Gee.... and how does this help from all those spams our server keeps 
receiving, from compromised Yahoo addresses that pass all the SPF, DKIM, 
and DMARC tests?

Miles Fidelman

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 12 Apr 2014 22:21:00 +0200

On Sat, Apr 12, 2014 at 03:57:51PM -0400, Miles Fidelman wrote:
> >The above points me to an article from trendmicro.com.  I was interested
> >in reading your opinion.
> >
> >>A bit of research on security and email will give you a better picture
> >>on why legitimate emails need to be better recognized.
> >
> >Ok.
> >
> receiving, from compromised Yahoo addresses that pass all the SPF, DKIM, and
> DMARC tests?

It's my understanding that Yahoo now claims to have no users
anymore, only sends spam and advertises that by saying you can
now reject all their mail.

Seriously, DMARC does not try to do something about spam but about
phishing, and by doing that has no problem rejecting otherwise
real e-mail.

kurt

---

From: Franck Martin <[email-masked]>
Date: Sat, 12 Apr 2014 15:24:48 -0500 (CDT)

> On Apr 12, 2014, at 12:25, "Scott Kitterman" <[email-masked]> wrote:
> 

If you are not disputing that, then you know you need a driving license because it increase security on the road, and if you don't have one then you can feel some pain...

We use to keep our doors open, we used to drive without license, we used to not need TLS, we used to not need anti-spam software,...

Machine learning is not as capable as human learning, algorithms are more restrictive...

Feel free to propose a better solution.. Quickly.. 

History in reboot, it all looks like SPF and DKIM IETF wars again....

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 12 Apr 2014 16:34:15 -0400

> phishing, and by doing that has no problem rejecting otherwise

It has just occurred to me that one might consider that by publishing 
it's p=reject policy into the DNS systems, one might consider that Yahoo 
has launched a DDoS attack on most of the world's list servers - which 
is illegal under a bunch of statutes (“knowingly caus[ing] the 
transmission of a program, information code, or command, and as a result 
of such conduct, intentionally causes damages without authorization to a 
protected computer”).  One might also have a case that Yahoo is engaging 
in restraint of trade (by causing the rejection of valid emails), and 
that ISPs that honor the p=reject policy might be engaging in a criminal 
conspiracy. Hmmm......

Miles Fidelman

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 12 Apr 2014 22:36:05 +0200

> Feel free to propose a better solution.. Quickly.. 

It's actually not that hard.  The technology already exists for
over 20 years and is widely deployed already.

Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 12 Apr 2014 17:18:33 -0400

On Saturday, April 12, 2014 15:24:48 Franck Martin wrote:
> >> http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/whi
> >> te-> papers/wp-spear-phishing-email-most-favored-apt-attack-bait.pdf
> >> 
> > I don't think anyone is disputing that.  The problem is that legitimate
> > emails are being treated as illegitimate.
> 
> If you are not disputing that, then you know you need a driving license
> because it increase security on the road, and if you don't have one then
> you can feel some pain...
> 
> We use to keep our doors open, we used to drive without license, we used to
> not need TLS, we used to not need anti-spam software,...
> 

No.  This seems different.  Having been involved in these discussions, writing 
and reviewing specs, writing code, and helping educate people about email 
authentication since 2004, I don't recall anything like this.

The closes was the discussion about ADSP, but there was a clear understanding 
that ADSP was only appropriate for certain types of domains.  The same is true 
of DMARC p=reject.  It wasn't a problem until Yahoo stepped outside the 
generally understood scope of what p=reject was safe for with no notice and 
clearly absolutely no care for impact on third parties.

There was also a fair amount of heat around the impact of SPF on transparent 
forwarding, but there was never the same kind of "screw you - your problem" 
attitude.  If you look at the text of the soon to be published RFC 4408bis 
there is a ton (too much some people thought) of information about what can be 
done as a sender, mediator, or receiver to mitigate the problem.

I think DMARC is a good idea (that's why I have DMARC records published), but 
you have to be careful how you use it.

If they were going to make a change like this, despite the predictable and 
predicted negative impacts, it would have been a lot better to give notice so 
that administrators could be better prepared.  As the confused discussion 
around what mailing lists should do now makes quite clear, there is no 
consensus on design or operational guidance to mitigate this issue.  "mailman 
has a new feature" covers about 1% of the problem space.

When I look at the feedback I get on my DMARC reports about 90% of the mail I 
send fails DMARC despite good SPF and DKIM deployments due to mailing lists, 
bug trackers, web site sharing, etc.  For me and many others this is not about 
a trivial piece of the mail stream.

Scott K

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 12 Apr 2014 23:25:15 +0200

> a trivial piece of the mail stream.

Just as a reminder, of the mails I receive with DMARC records 90%
fails.  I'm glad I'm not the only one seeing such numbers.

Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 12 Apr 2014 17:29:08 -0400

On Saturday, April 12, 2014 23:25:15 Kurt Roeckx wrote:
> > When I look at the feedback I get on my DMARC reports about 90% of the
> > mail I send fails DMARC despite good SPF and DKIM deployments due to
> > mailing lists, bug trackers, web site sharing, etc.  For me and many
> > others this is not about a trivial piece of the mail stream.
> 

Although it's hard to tell what the numbers really mean.  If I send a mail to 
a list such as [email-masked] then that mail shows up in the 
Gmail feedback report as one failed message per Gmail using subscriber of the 
list.  So the number of messages reported as failed is much larger than the 
actual number of messages you sent for a large mailing list.

Scott K

---

From: Franck Martin <[email-masked]>
Date: Sat, 12 Apr 2014 18:27:46 -0500 (CDT)

----- Original Message -----
> From: "Scott Kitterman" <[email-masked]>
> To: [email-masked]
> Sent: Saturday, April 12, 2014 2:18:33 PM
> Subject: Re: [dmarc-ietf] Fwd:  DMARC's purpose
> 
> > >>>> beneficial,
> > >> on

I do agree with you, a bit more time would have helped… but then, I was bullied (not by you) for wanting to put new features in mailing lists to avoid this predicted collateral damage… So I did it when I had time on the software I could… Now people are feeling way more motivated…  ;)

This is true with all the other examples you gave, I told people, everywhere I would find something like this.. The mistake what to not see it would happen sooner or later.. Security fixes always happen sooner than later...

Sounds like the “you should do TLS - yeah… yeah… whatever…"

anyhow, I think we should stop this thread, this is an IETF list, it is about working on protocols. 

(and apparently french people are not supposed to do email outside working hours :P )

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 12 Apr 2014 19:42:20 -0400

> anyhow, I think we should stop this thread, this is an IETF list, it is about working on protocols.

Silly me - I thought we were talking about the DMARC protocol, on the 
[email-masked] list.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Apr 2014 00:42:25 -0700

On Sat, Apr 12, 2014 at 8:10 AM, Kurt Roeckx <[email-masked]> wrote:

>  The

If you have any specific suggestions for how it can be improved, now would
be a good time to make them.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Apr 2014 00:51:48 -0700

On Sat, Apr 12, 2014 at 9:23 AM, Miles Fidelman
<[email-masked]>wrote:

> - they published an information Internet draft, that expires in October of
> this year, that starts with "This memo presents a proposal for a scalable
> mechanism by which a mail sending organization can express,....."
That's your inference, not their implication.  None of "base
specification", "informational Internet draft" or "proposal for a scalable
mechanism" automatically mean "standard".  In fact, the document is not on
a path for the standards track.

Publication of a "proposal" as an information Internet draft, is barely the
> first step toward an operational specification standardized by the IETF -
> yet DEMARC proponents are representing it as an IETF standard (or at least
> as going through the process).
>

See above; this is incorrect.

> 1. DMARC is NOT even close to an IETF standard

...nor is it currently seeking that status.

> 2. It has not been subject to any of the technical and operational vetting
> associated with the progression of a specification through the IETF
> standardization process
>

Correct, at least formally in IETF terms, which is why it is on track to be
Informational.  Informally, there has been open community dialog about it
for quite some time now, not limited to this mailing list.

> 3. The means by which Yahoo has deployed DMARC, and the choice of several
> other large ISPs to honor the p=reject policy, is not in keeping with the
> practice of measured testing and incremental deployment of IETF standards,
> as they progress from proposal, to experimental, to optional, to
> recommended, to mandatory
>

DMARC includes mechanisms to be incremental and do live testing and
reporting as key components, and has since its inception since gradual
rollout capabilities were established as a requirement early on.

That one operator may have chosen to do something in a way people found
disruptive is not, to me, a valid cause through which the specification
should be invalidated.  DNSBLs can be just as or even more disruptive (and
have been), yet they are also described in Informational RFCs.  There are
likely many other examples.

-MSK

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 14 Apr 2014 19:43:58 +0200

> be a good time to make them.

I thought I made my comments about this in the past, but I can't
actually find them.  Some of them are:
- It does not describe how it (ab)uses existing technology and
  breaks existing things.  It's not clear what the effects of the
  alignment is.
- It does not say anything about how participating mailinglists
  should behave
- It's not clear in how reports should look like for messages that
  don't pass.  It would help that there were examples in it.

What would also help is:
- Implementations that actually follow the spec.  So far I have
  received 0 report mails that follow the specification.

Kurt

---

From: Matt Simerson <[email-masked]>
Date: Mon, 14 Apr 2014 10:52:34 -0700

>  received 0 report mails that follow the specification.

http://search.cpan.org/dist/Mail-DMARC/

and the report format definition:

http://search.cpan.org/dist/Mail-DMARC/lib/Mail/DMARC/Report/Aggregate.pm

If you received a report from me (or another site that uses Mail::DMARC), you'd get a report that follows the 2013 draft. To the letter. I haven't read the latest draft in enough detail to assure that is still the case.

While writing Mail::DMARC, I noticed a number of anomalies in the reports I was receiving. Upon reporting on those issues to the dmarc-users mailing list, all of them (except a hotmail issue) got a "oops, we'll fix that," response.  I haven't gone back to see if I can remove the "tolerate this malformation in a report" shims, but my assumption is that I can remove most of them.

Matt

---

From: Terry Zink <[email-masked]>
Date: Mon, 14 Apr 2014 16:38:04 +0000

Murray's response is the key point. Large email providers like DMARC because it helps cut down on phishing (which results in fewer compromised accounts), user complaints (which reduces support calls) and is fairly straightforward to implement (which makes the codebase more maintainable). They realize, however, that there are some scenarios that DMARC breaks. However, unless that pain is greater than the magnitude of pain that it solves, they are unlikely to reverse their DMARC implementations.

However, I'm sure they'd be amenable to updating it to fix the scenarios that is does break. So, what are the options? There are hundreds of years of email experience on this list, I'm sure we can come up with something.
-- Terry

From: dmarc [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Monday, April 14, 2014 12:42 AM
To: Kurt Roeckx
Cc: Dave Crocker; [email-masked]; Miles Fidelman
Subject: Re: [dmarc-ietf] DMARC's purpose

I don't agree with this.

If you have any specific suggestions for how it can be improved, now would be a good time to make them.

-MSK

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Apr 2014 14:16:52 -0400

>    received 0 report mails that follow the specification.
And a definitive statement as to whether or not Yahoo's implementation 
recognizes Original-Authentication-Results - which would represent a 
low-impact way to interoperate with DMARC.

Kind of trying to decide whether to invest time and energy in patching 
our Sympa installation to generate OAR headers - but so far, the only 
folks who claim to support it are Google - and I've received multiple 
anecdotal statements that "nobody has implemented it."
The dmarc.org faq recommends: "Add an Original Authentication Results 
<http://tools.ietf.org/html/draft-kucherawy-original-authres-00> (OAR) 
header to indicate that the list operator has performed authentication 
checks on the submitted message and share the results. " but a few days 
ago this was added: "*This is not a short term solution.* Assumes a 
mechanism to establish trust between the list operator and the receiver. 
No such mechanism is known to be in use for this purpose at this time. 
Without such a mechanism, bad actors could simply add faked OAR headers 
to their messages to circumvent such measures. OAR was only described as 
a draft document, which expired in 2012. No receivers implementing DMARC 
are currently known to make use of OAR from external sources. "

---

From: Barry Leiba <[email-masked]>
Date: Wed, 16 Apr 2014 12:39:44 -0400

> Well, let's see:
...
> https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ - an IETF

It is not "an IETF document".  One of those would have a name that
starts with "draft-ietf-", followed by the name of the working group
it's part of.  And even then, it's just a "work in progress."  IETF
documents have RFC numbers.  IETF work in progress has "draft-ietf-".

draft-kucherawy-dmarc-base is an individually posted Internet draft.
Anyone can post one of those (go ahead: try it).  They aren't IETF
documents.  That distinction is important.

Barry

---

From: Jim Fenton <[email-masked]>
Date: Wed, 16 Apr 2014 09:45:23 -0700

> documents.  That distinction is important.

Yes, but the boilerplate doesn't help.  From the second paragraph of
"Status of this Memo":

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts.

So it's an IETF document in addition to possibly being someone else's.

-Jim

---

From: Barry Leiba <[email-masked]>
Date: Wed, 16 Apr 2014 12:53:15 -0400

> issue with mailing lists is well-documented.

 aI'm not sure that any issue with mailing lists is documented in
draft-kucherawy-dmarc-base at all, well or otherwise.  A search for
"mailing list" (or even "mailing") shows hits in three places, all in
back matter, none of substance.

There's nothing that I can see anywhere that warns of possible
consequences (neither considerations for the domain publishing the
policy nor discussion of collateral damage to mailing lists) of using
"p=reject" -- not in the explanation of "p=reject", not in Section 6
("Policy Enforcement Considerations"), not in Section 15.4 ("Rejecting
Messages"), not in the Security Considerations.

Where is is well documented?

Barry

---

From: Franck Martin <[email-masked]>
Date: Wed, 16 Apr 2014 12:04:50 -0500 (CDT)

----- Original Message -----
> From: "Barry Leiba" <[email-masked]>
> To: "Dave Crocker" <[email-masked]>, "Murray Kucherawy" <[email-masked]>
> Cc: [email-masked]
> Sent: Wednesday, April 16, 2014 9:53:15 AM

In the upcoming BCP

Should we also document in this Murray's draft that MS-Exchange breaks DKIM on forwarding, inventory all the operational cases? I don't think so. The draft is to describe the protocol, the BCP is here to document on how to operationally deploy and use it.

The reviews if I recall suggested to limit the draft to the protocol bits strictly.

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 16 Apr 2014 13:06:04 -0400

> documents.  That distinction is important.
In the "fine print" - but most folks don't read the fine print - which 
makes it really easy for folks to take liberties in marketing and 
management presentations.

It's URL includes "ietf.org," it lives on an IETF server, it's header 
includes "Network Working Group."  If it looks like an IETF document, 
and quacks like an IETF document - that's enough for an awful lot of 
people to claim that it IS an IETF document, and for an awful lot of 
folks to believe it.  From the point of view of most of the world - at 
the level that sees IETF as "the Internet's standards body" - that 
distinction is so invisible as to be meaningless.

 From a legal point of view, it could be meaningless as well - in the 
same way that clauses buried in shrink wrapped licenses might or might 
not stand up in court. Example:  "no liability for anything" clauses 
don't cancel out an implied warrant of merchantability. Even as a 
non-lawyer, I know that one.  And again, Kleenex and Xerox and Coke 
spend a lot of money defending their trademarks - apparently, they 
believe that putting Kleenex(tm) on their boxes is not sufficient to 
prevent others from referring to their products as "kleenex."

Miles Fidelman

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Apr 2014 10:10:46 -0700

> management presentations.

Of course, this has been explained multiple times in multiple venues.

There is no way to prevent the actions of people who have no concern for 
speaking carefully and accurately, or who choose to dismiss details they 
find inconvenient.

Such folk fundamentally are engaging in the political effort of 
persuasion, rather than the intellectual effort of understanding.

For group interaction, the differences between the two are fundamentally 
different in terms of style, goals and outcome.

d/

---

From: Barry Leiba <[email-masked]>
Date: Wed, 16 Apr 2014 13:12:55 -0400

>> I'm not sure that any issue with mailing lists is documented in
>> Where is [it] well documented?
>
> In the upcoming BCP

1. I don't see it adequately covered there, on a quick scan.  I
haven't read it thoroughly, though.

2. There is no reference from dmarc-base to dmarc-bcp, not even an
informative one.  And this is an important enough consideration that I
think it should be a normative reference.

> Should we also document in this Murray's draft that MS-Exchange
> breaks DKIM on forwarding, inventory all the operational cases? I
> don't think so. The draft is to describe the protocol, the BCP is here
> to document on how to operationally deploy and use it.

I can't parse the first sentence, nor figure out what you're trying to
refer to.  But to answer the question that's behind what I think
you're asking: Yes, we should document, either in the specification or
in an Applicability Statement that the specification cites as a
normative reference, considerations that are critical to getting the
configuration right.

It's fine to separate the protocol bits and the "other information"
into different documents, but it *all* has to be there in order to
fight against misconfiguration and the damage that can cause.

Barry

---

From: Franck Martin <[email-masked]>
Date: Wed, 16 Apr 2014 12:44:47 -0500 (CDT)

----- Original Message -----
> To: "Franck Martin" <[email-masked]>
> Cc: "Dave Crocker" <[email-masked]>, [email-masked], "Murray Kucherawy" <[email-masked]>
> Sent: Wednesday, April 16, 2014 10:12:55 AM

Work in progress, feel free to submit some text to Dave.

> normative reference, considerations that are critical to getting the

It is well know that MS-Exchange breaks DKIM on forwarding by design, therefore breaks DMARC. It is not a trivial problem. Also Blackberries, break DMARC too. Should we cite all these cases in the draft? Make a laundry list?

We always said do monitor mode and then decide if it makes sense to move to p=reject.

Besides section 2.4 says it is out of scope:

Handling of undesirable or malicious mail that is coming from the
      domain from which it claims to be sent.

> fight against misconfiguration and the damage that can cause.

As far as I can see (I just did another search on the RFCs) there is no misconfiguration as there is no normative RFC to define what a mailing list is, how it operates, how it handles bounces, subscriptions, etc..... I think this is what Ned was referring to in his post.

Section 15.4 gives some advice to all sending systems:

In the latter case, when doing an SMTP rejection, providing a clear
   hint can be useful in resolving issues.  A receiver might indicate in
   plain text the reason for the rejection by using the word "DMARC"
   somewhere in the reply text.  Many systems are able to scan the SMTP
   reply text to determine the nature of the rejection, thus providing a
   machine-detectable reason for rejection allows automated sorting of
   rejection causes so they can be properly addressed.

I don't see the issue with mailing lists (and other systems) be different from doing appropriate bounce processing.

So I propose the following to be added in 15.4:

Some forwarding systems (including some mailing lists) are notably known to have a simple bounce processing system, in such cases, the forwarding system may consider after a few bounces that the recipient address is not valid anymore and unsubscribe such recipient.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Apr 2014 10:54:42 -0700

> think it should be a normative reference.

The issue is important, certainly, but there are two reasons I think 
having base point to the draft bcp is the wrong approach:

1. The underlying issue here is essentially architectural rather than 
operations.  DMARC is designed to work for some specialized end-to-end 
scenarios and known to fail for some others,  When a spec defines 
something with those sorts of characteristics, I consider the 
explanation of its implications to be better placed in the 
specification.  At the least, it facilitates understand the underlying 
architectural choices that were made.

2. BCPs usually come after the spec.  A spec should not rely on a 
supporting BCP.  It gets the document usage directionality all screwed up.

d/

---

From: Terry Zink <[email-masked]>
Date: Thu, 17 Apr 2014 15:43:06 +0000

> Should we also document in this Murray's draft that MS-Exchange breaks 
> DKIM on forwarding, inventory all the operational cases?

1. If a message is sent via Exchange with a 3rd party DKIM signer, then DKIM will not be broken if the next Exchange hop forwards.

2. Messages will be preserved with DKIM in a future release of Exchange, we use it internally and it works.

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Franck Martin
Sent: Wednesday, April 16, 2014 10:05 AM
To: Barry Leiba
Cc: Dave Crocker; [email-masked]; Murray Kucherawy
Subject: Re: [dmarc-ietf] DMARC's purpose

----- Original Message -----

In the upcoming BCP