Subject: DMARC from the perspective of the listadmin of a bunch of SMALL community lists

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

Folks,

We (really I) support perhaps 2 dozen small email lists, for a bunch of 
community groups (PTOs, churches, neighborhood groups) - mostly the 
legacy of previously running a small hosting firm, and still having the 
machines sitting in a data center.  The kinds of groups with lots of 
non-technical users who have email accounts on Yahoo, hotmail, AOL, 
Comcast, and such.  The lists range in size from tiny (5 person boards 
of directors) to maybe 1000 (high school parents).

Yahoo's implementation of it's new DMARC policy has been an absolute 
disaster.  Kind of messes things up when a few days before tax filings 
are due, and in parallel with the Heartbleed mess, (not to mention the 
work that pays the bills), roughly 1/3 of the addresses on almost all of 
the lists start bouncing mail from yahoo addresses - particularly when 
yahoo's postmaster didn't have a clue what was going on (my initial 
thought was - oh heck, need to get back on their whitelist).  Luckily 
gmail seems not to be honoring the Yahoo's p=reject policy, at least so 
far, or things would be a LOT worse.

Still trying to figure out a reasonable fix for this, as it looks like 
lots of other listmasters are trying to do - and doesn't help that I'm 
running a less common list package (sympa).

Anyway - one of my reactions to this is that something is really broken 
about the process by which DMARC and Yahoo's policy have been foisted on 
the larger Internet community - and in particular IETF's role or lack 
thereof.  Specifically:

- 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

- the referenced document is an informational  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,.

- It's also being presented as mature - through such publicity 
statements as "DMARC standard now protects almost two-thirds of the 
world's 3.3 billion consumer mailboxes worldwide" 
(http://dmarc.org/news/press_release_20140218.html)

In essence, DMARC is being represented as a mature, standards-track IETF 
specification - with the implication that it's been widely vetted, and 
is marching through the traditional experimental -> optional -> 
recommended -> mandatory steps that IETF standards go through.

In reality:
- DMARC was developed by a tiny number of people, all of whom work for 
very large ISPs
- as far as I can tell, all input from the broader community - notably 
mailing list developers and operators was roundly ignored or dismissed 
(the transcript is really clear on this)
- while DMARC is at least partially tested, deploying and honoring 
"p=reject" messages is brand new, and has wreaked tremendous damage 
across the net
- as far as I can tell, those who are behind DMARC are taking the 
position "it's not our problem" (see discussions on 
[email-masked] and [email-masked]) - and there is nary a Yahoo 
representative to be seen anywhere

 From an operational perspective, this is akin to a large player 
publishing a corrupt nameserver database or routing update - and then 
actively resting attempts to clean up the mess (which, in effect is what 
Yahoo did by updating their DMARC record to p=reject).

The situation strikes me as incredibly perverse and broken - the more so 
that the perpetrators are presenting this as blessed by the IETF 
standards process.

It strikes me that IETF should weigh in on this in a formal fashion - if 
only to make it very clear that IETF is not responsible for this 
debacle, and perhaps to exert some moral influence on the perpetrators 
to back off and help clean up the mess they've created.

On a broader scope - this sort of points out a really big hole in our 
consensus governance process - when one bad actor can inflict damage 
across the entire Internet, apparently, with impunity.

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 13:30:25 -0700

> https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ - an IETF

While the Internet-Draft mechanism is operated by the IETF, it is an 
open mechanism and issuance through it carries no automatic status, 
particularly with respect to the IETF.

The DMARC specification is not 'an IETF document'.  The current plan is 
to publish it as an RFC, through the 'Independent' stream, which also is 
/not/ an IETF activity.

> - the referenced document is an informational  Internet draft, that

Drafts do not have status.  So the qualifier 'informational' here is not 
meaningful.

> - DMARC was developed by a tiny number of people, all of whom work for

Well, a few of us who participated don't...

> (the transcript is really clear on this)

What transcript?  I'm not aware of its being 'ignored or dismissed'.

> "p=reject" messages is brand new, and has wreaked tremendous damage

It's not new at all, though of course Yahoo's use is distinctive.

> representative to be seen anywhere

I've no idea what specifics you are referring to.

> that the perpetrators are presenting this as blessed by the IETF

I haven't seen anyone present such a claim of blessing.  Please point to 
the specifics.

I fear you are confusing the difference between a desire for standards 
status with a claim of its having been granted.

  d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Michael Richardson <[email-masked]>
Date: Sat, 12 Apr 2014 16:49:27 -0400

Miles Fidelman <[email-masked]> wrote:
    > legacy of
    > previously running a small hosting firm, and still having the machines

ditto.

+5 on everything you said.
It is a great idea, but it is not mature, and there wasn't much in the way of
running code.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

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

Dave,

Dave Crocker wrote:
> The DMARC specification is not 'an IETF document'.  The current plan 
> is to publish it as an RFC, through the 'Independent' stream, which 
> also is /not/ an IETF activity.
>

My point is that the folks behind dmarc PRESENT it in a way that 
implicitly makes it look like an IETF document, and that it's on the 
standards track.  The reality, as you say, is different.  "Plan to" is 
vaporware.
> Drafts do not have status.  So the qualifier 'informational' here is 
> not meaningful.
>
As currently published, it carries the header

Intended status: Informational

> Well, a few of us who participated don't...

fair enough - but again, just look at http://dmarc.org/about.html - I 
don't see your name, or any other small individuals or ISPs - what I do 
see are
"A group of leading organizations came together in the spring of 2011"
and
"The founding contributors include:

  * *Receivers:* AOL, Comcast, GMail, Hotmail, Netease, Yahoo! Mail
  * *Senders:* American Greetings, Bank of America, Facebook, Fidelity,
    JP Morgan Chase, LinkedIn, PayPal
  * *Intermediaries & Vendors:* Agari, Cloudmark, ReturnPath, Trusted
    Domain Project"

This was very much an industry-based effort.

> What transcript?  I'm not aware of its being 'ignored or dismissed'.

Funny, that's the impression I get when I read back through the archives 
for [email-masked] and [email-masked]

pretty much all discussion of aligning the From: field came down to - 
"you change"

> It's not new at all, though of course Yahoo's use is distinctive.

Depends on your definition of "new" - and while DMARC builds on an older 
base, DMARC itself was started in 2011, and I assume the first standards 
and software are more recent then that.

As you say, Yahoo's use is "distinctive" - though I'd use a somewhat 
stronger word.
> I've no idea what specifics you are referring to.

I've been following the discussions, on lots of lists, and I've yet to 
see someone say even "I'm from Yahoo and we feel your pain" - much less 
"hmm... maybe this wasn't such a good idea, we're going to back off and 
implement in a slightly gentler manner - and maybe provide some support 
to help patch the major list management packages" - or even "our 
implementation honors Original-Authentication-Results"

nope - as far as I can tell, the folks who turned on p=reject at Yahoo 
don't seem to have even told their own security or customer care folks 
about what's going on - at least when this first broke, and I contacted 
Yahoo's postmaster (thinking I needed to get our servers back on the 
whitelist) - they just pointed me at the whitelist request form

> I haven't seen anyone present such a claim of blessing.  Please point 
> to the specifics.
>
No... I'm quoting the way that dmarc.org is presenting the "DMARC Draft 
Specification" - as marching through the IETF standards track, as it is 
generally understood, and then hiding in the fine print that no such 
thing has happened, or is currently happening

I'm not confused.  It is, and I think intentionally, being presented in 
a way that is intended to confuse.  And I personally think that IETF 
should be calling them on it.  Officially, loudly, and clearly.  (The 
same way that Xerox and Kleenex jump down the throats of anybody who 
tries to use their names generically.  )

Miles Fidelman

---

From: Hector Santos <[email-masked]>
Date: Sat, 12 Apr 2014 18:09:44 -0400

Miles, Bravo to you for being brave!! +100 on everything you said!!

--
HLS

n 4/12/2014 3:56 PM, Miles Fidelman wrote:
> Folks,
>
> We (really I) support perhaps 2 dozen small email lists, for a bunch
> of community groups (PTOs, churches, neighborhood groups) - mostly the
> legacy of previously running a small hosting firm, and still having
> the machines sitting in a data center.  The kinds of groups with lots
> of non-technical users who have email accounts on Yahoo, hotmail, AOL,
> work that pays the bills), roughly 1/3 of the addresses on almost all
> of the lists start bouncing mail from yahoo addresses - particularly
> when yahoo's postmaster didn't have a clue what was going on (my
> initial thought was - oh heck, need to get back on their whitelist).
> Luckily gmail seems not to be honoring the Yahoo's p=reject policy, at
> least so far, or things would be a LOT worse.
>
> Anyway - one of my reactions to this is that something is really
> broken about the process by which DMARC and Yahoo's policy have been
> foisted on the larger Internet community - and in particular IETF's
> role or lack thereof.  Specifically:
>
> 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,.
>
> In essence, DMARC is being represented as a mature, standards-track
> IETF specification - with the implication that it's been widely
> vetted, and is marching through the traditional experimental ->
> optional -> recommended -> mandatory steps that IETF standards go
> through.
>
> In reality:
> [email-masked] and [email-masked]) - and there is nary a
> Yahoo representative to be seen anywhere
>
> actively resting attempts to clean up the mess (which, in effect is
> what Yahoo did by updating their DMARC record to p=reject).
>
> The situation strikes me as incredibly perverse and broken - the more
> so that the perpetrators are presenting this as blessed by the IETF
> standards process.
>
> It strikes me that IETF should weigh in on this in a formal fashion -
> if only to make it very clear that IETF is not responsible for this

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 13 Apr 2014 10:23:22 +1200

Hi,

In the DMARC draft, I noticed this:

>  Descriptions of the PolicyOverrideTypes:
...
>    mailing_list:  Local heuristics determined that the message arrived
>       via a mailing list, and thus authentication of the original
>       message was not expected to succeed.

Could somebody explain what that means and whether it can be used to
mitigate the current issue? Or are substantial changes needed
in the fundamentals of DMARC?

I assume the authors will be adding a discussion of this issue
to the draft.

Regards
   Brian

---

From: Theodore Ts'o <[email-masked]>
Date: Sat, 12 Apr 2014 19:02:00 -0400

On Sat, Apr 12, 2014 at 03:56:14PM -0400, Miles Fidelman wrote:
> community groups (PTOs, churches, neighborhood groups) - mostly the legacy
> of previously running a small hosting firm, and still having the machines
> sitting in a data center.  The kinds of groups with lots of non-technical
> users who have email accounts on Yahoo, hotmail, AOL, Comcast, and such.
> The lists range in size from tiny (5 person boards of directors) to maybe
> 1000 (high school parents).

Why don't you just respond by sending an e-mail to each of the
affected users, telling them that they will unfortunately no longer be
able to participate in the mailing list due to the choices of their
mail provider, and that if they want to continue to receiving e-mail,
to consider setting up new e-mail account with some other provider
such as gmail -- and then cc [email-masked] on the message.

That's how I plan to deal with things....

					- Ted

---

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

> That's how I plan to deal with things....

Well, it's certainly attractive, if time consuming.  2000 or so people, 
or 24 or so list messages, plus dealing with all the folks who ask me to 
personally unsubscribe one address, and add their new one.  Probably 
less painful to patch the list manager to re-write the From address of 
incoming mail (which is what seems to be where a lot of people are going).

As to them impact on Yahoo - I expect they'd ignore it.  On the other 
hand, I'm starting to wonder about suing them for damages and creating a 
public nuisance. :-)  [yes, I'm feeling a little vindictive right now.]

Sigh...

Miles

---

From: Mark Andrews <[email-masked]>
Date: Sun, 13 Apr 2014 09:48:34 +1000

> public nuisance. :-)  [yes, I'm feeling a little vindictive right now.]

Just reject any email with a DMARC "p=reject" qualifier destined
to a email list at the SMTP level that doesn't include you as a
valid sender.

5.x.x DMARC p=reject not compatible with email sent to a mailing list

What Yahoo is doing is anti-social.  It is forcing people who don't
want to be involved in DMARC to particate to some level as they are
getting all the bounces from Yahoo's idiocy.

Alterntively reject all @yahoo.com email until the DMARC record is
changed.  If Yahoo want to apply presure to people to support DMARC
by changing their software, email list operators can apply presure
back when they deliberately do something stupid like this.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Hector Santos <[email-masked]>
Date: Sun, 13 Apr 2014 00:37:07 -0400

> I assume the authors will be adding a discussion of this issue

Brian,

The overall problem is that the middle ware, mailing list servers 
(MLS) need to change in order to support any DKIM optional add-on 
security policy layer.

If the MLS is going to break the integrity and resign the mail, it 
could not do this blindly without considering the submitting author 
domain security policy.

First it was SSP, then ADSP, now DMARC.  Same problem. Unless the 
middle ware supports this policy layer, they risk causing distribution 
problems at the ADSP and/or DMARC, policy-compliant downlinks.   This 
was one of the cited interop problem reasons why ADSP was made historic.

So its really a matter of getting wider support at the Mailing List 
Software or once again, like it was done for ADSP, promoting the idea 
of not supporting the p=reject feature of DMARC.

Keep in mind, this is really only a problem because a "public" 
yahoo.com domain, for some odd reason, use a DMARC p=reject and there 
is apparently mail distribution down links that support it.  The list 
servers blindly resigned the mail and there is no 3rd party support 
concept in place to handle it.

But it would be precisely what another domain like fedex.com would 
want with its restrictive ADSP discardable and DMARC p=reject policies 
being used in a public mailing list.

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Sat, 12 Apr 2014 23:04:33 -0700

> I assume the authors will be adding a discussion of this issue

Dear Brian,

There was an extension that foresaw this problem by offering a safe policy override scheme for third-party services that might result in DKIM signature failure.  DMARC often fails with messages from third-party services such as mailing-list.  Such failures normally result in these messages being placed into junk folders.  Unfortunately, too many ignore cautions about rejecting as can be demanded by DMARC.  This work began as http://tools.ietf.org/html/draft-otis-dkim-tpa-label-06 by Daniel Black and myself that eventually resulted in http://tools.ietf.org/html/rfc6541.  Murray considered TPA too complex.  The TPA scheme could have avoided the very problems caused by DMARC policies placed on wrong account types.  DMARC is often promoted without its limitation being clearly stated or seemingly understood.  Does Yahoo expect mailing lists to drop users of their service?  

This could have been avoided without any disruption to mailing lists by a community generated list of known good third-party service providers published as hash labels.  Although IESG did not think SPF records able to generate hundreds of DNS transactions against otherwise uninvolved domains a concern, IESG regarded a single ATPS query against the authoritative domain a major threat that MUST be addressed by use of a "special" DKIM signature.  This IESG mandated change defeated efforts aimed at avoiding such disruptions and also made virtually any policy exception scheme non-deployable. 

The IESG needs to explain their thinking.  I can't, nor have they allowed a means for a functional alternative.

Regards,
Douglas Otis

---

From: Dave Crocker <[email-masked]>
Date: Sun, 13 Apr 2014 07:02:41 -0700

> in the fundamentals of DMARC?

It means that a receiving system, which otherwise complies with DMARC 
policy records, has chosen to deviate from a domain owner's request to 
reject messages that fail DMARC, by virtue of knowing that it went 
through a mailing list that was trusted.

In other words, it means that the receiving mail system whitelisted a 
mailing list.

d/

---

From: "Andrew G. Malis" <[email-masked]>
Date: Sun, 13 Apr 2014 10:26:22 -0400

Dave,

I couldn't help seeing in your email:

The DMARC specification is not 'an IETF document'.  The current plan is to
> publish it as an RFC, through the 'Independent' stream, which also is /not/
> an IETF activity.
>

when compared to the following at dmarc.org (on the front page):

"DMARC policies are published in the public Domain Name System (DNS), and
available to everyone. It is the goal of DMARC.org to submit the draft
specification to the IETF so that it may begin the process of becoming an
official Internet Standard RFC - available to everyone for reference,
implementation, and improvement."

The statement on dmarc.org really does look like a misrepresentation.

Cheers,
Andy

---

From: [email-masked]
Date: Sat, 12 Apr 2014 16:35:13 -0700 (PDT)

> mitigate the current issue?

"mailing_list" is an indicator that a Receiver has chosen to override the
policy the Domain Owner specified for a failed DMARC check, on the basis that
the Receiver has knowledge that the message was forwarded by a mailing list and
thus the DMARC failure is expected. A whitelisting mechansism, in other words.

This is viable mitigation in theory, but not in practice, because it assumes
that Receviers are aware of and can verify mail they receive from every
possible legitimate mailing list out there. That's clearly not possible.

> Or are substantial changes needed

The underlying technical issue is that the two technologies DMARC is built on -
DKIM and SPF - both attach additional/restrictive semantics to longstanding mail
system fields. (Broadly speaking, From: for DKIM and MAIL FROM for SPF.)

An unavoidable consequence of doing this is that longstanding email mechanisms
that depend on the semantics of those fields are going to be affected. (Mailing
lists are the obvious example for DKIM, autoforwarers the obvious one for SPF.)
And when you couple this with an unforgiving policy choice, things break badly.

If you're expecting any of this to be fixable by some technical change to
DMARC, DKIM, or SPF, you can forget it. The design constraints in the space are
very tight, and if you "fix" them to address the issues they cause, you ruin
their effectiveness.

> I assume the authors will be adding a discussion of this issue to the draft.

You're really looking at the wrong draft. draft-crocker-dmarc-bcp-03 talks about
when p=reject should be used, and has this to say:

   DMARC provides protection against some forms of email domain name
   abuse.  Its restricted policy form (p=quarantine or p=reject) is not
   intended for all use cases, and is beneficial only in the presence of
   an actual spoofing problem.  You may, however, want to protect
   mailboxes by checking inbound mail, and you may want information
   about how your domains are showing up at recipients by publishing a
   p=none record.

It goes on to discuss the use of p=reject with domains that only send
transactional. AFAICT there is no discussion of when *not* to use p=reject, and
why. Nor, for that matter is there substantive discussion of mailing_list,
and why it's not a general solution to the problems caused by p=reject.

More generally, I have to say I find myself in substantive agrement with Miles
Fidelman and Hector Santos on this matter. There has been a cascade failure
leading to a colossal screwup. And while Yahoo is clearly the primary malfeasor
here, as is always the case in a cascade failure, there's blame aplenty to go
around.

Like it or not, the IETF published a draft that defines certain mechanisms
which, if used improperly by a large provider, cause serious problems for a
large number of people. The text describing the consequences of the use of
those mechansisms in the drafts is, IMO, entirely inadequate.

And it's not like we didn't know. As others have pointed out, this issue
existed in the earlier ADSP proposal. It was given insufficient attention there
as well.

The clear discrepancy between the fine print regarding intended status in the
specifications (which only engineers read) and what's on the DMARC web site
(which is what managers read)  is also nothing short of deplorable.

Of course the IETF can fall back on the usual excuses, including, but not
limited to:

    Yahoo, of all ISPs, should have known better
    We don't tell people what to do
    It was just a draft
    It was never intended to be a standard
    We're not the Internet Protocol Police
    etc.

I'm sorry, but this time none of these dogs are hunting for me. An attractive
nuisance is an attractive nuisance, and this is what the IETF has, albeit with
the best of intentions, managed to create.

The real question we should be discussing is what options the IETF has to try
and address this.

				Ned

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 13 Apr 2014 15:16:58 -0400

> In other words, it means that the receiving mail system whitelisted a 
Which - I'll note - Yahoo is not providing for.

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 13 Apr 2014 15:21:21 -0400

Andrew G. Malis wrote:
>     The DMARC specification is not 'an IETF document'.  The current
>     plan is to publish it as an RFC, through the 'Independent' stream,
>     which also is /not/ an IETF activity.
>
>
> when compared to the following at dmarc.org <http://dmarc.org> (on the 
> front page):
>
> "DMARC policies are published in the public Domain Name System (DNS), 
> and available to everyone. It is the goal of DMARC.org to submit the 
> draft specification to the IETF so that it may begin the process of 
> becoming an official Internet Standard RFC - available to everyone for 
> reference, implementation, and improvement."
>
> The statement on dmarc.org <http://dmarc.org> really does look like a 
> misrepresentation.
>

Exactly.  And IETF is complicit by providing the publication vehicle and 
not loudly denying that it's an IETF standards-track protocol, with all 
the associated careful vetting, testing, and maturation over time.  
(There's a reason that folks like Xerox and Kleenex very actively 
protect their brand.)

Miles Fidelman

---

From: "John Levine" <[email-masked]>
Date: 13 Apr 2014 19:54:50 -0000

>In other words, it means that the receiving mail system whitelisted a 

Yeah.  The problem is that as we are now seeing from the Yahoo fiasco,
receivers don't whitelist mailing lists, leading to all sorts of
damage to mail that has been working perfectly well and that, if my
experience is any guide, recipients want a lot more than the bulk
blasts that p=reject was designed to handle.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Apr 2014 07:57:14 +1200

Miles,

> (There's a reason that folks like Xerox and Kleenex very actively

Hold on though. At the moment the text says, among other things,

   Note that other groups may also distribute
   working documents as Internet-Drafts.  ...

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 4, 2014.

If published in the Independent Stream as an RFC, it will say

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the RFC Series, independently of any
   other RFC stream.  The RFC Editor has chosen to publish this
   document at its discretion and makes no statement about its value
   for implementation or deployment.  Documents approved for
   publication by the RFC Editor are not a candidate for any level of
   Internet Standard; see Section 2 of RFC 5741.

and might also carry an explicit statement from the IESG along the
YMMV axis.

We know this doesn't prevent marketing people from telling lies
about the status of a document, but the IETF doesn't do so.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Apr 2014 08:05:08 +1200

Ned (and others),

Thanks for the explanations. Very helpful to a non-expert.

On 13/04/2014 11:35, Ned Freed wrote:
...
> The real question we should be discussing is what options the IETF has to try

Yes please. I don't think it's going to work to dump this problem
in the lap of the Independent RFC Series Editor.

   Brian

---

From: Theodore Ts'o <[email-masked]>
Date: Sun, 13 Apr 2014 16:08:41 -0400

> about the status of a document, but the IETF doesn't do so.

Well, maybe someone like Miles should consider writing an I-D "DMARC
considered harmful", which advises users impacted by Yahoo's diastrous
implementation of DMARC to find another e-mail provider.

Perhaps the metaphorical swatting the nose of these other groups with
a newspaper will help encourage them to avoid abusing the IETF's
reputation in order to market their specification.

					- Ted

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 13 Apr 2014 16:21:59 -0400

> about the status of a document, but the IETF doesn't do so.

Just pointing out that when marketing people tell lies, pointing to the 
fine print may not be a sufficient response (morally, or legally).

Miles

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 13 Apr 2014 16:22:23 -0400

> in the lap of the Independent RFC Series Editor.

Yes!

Miles

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 13 Apr 2014 16:28:35 -0400

> reputation in order to market their specification.
Hmm.  Good idea.  Though I think John Levine's piece pretty much IS 
"DMARC considered harmful" - just needs to be titled!
http://www.ietf.org/mail-archive/web/ietf/current/msg87153.html
Yahoo breaks every mailing list in the world including the IETF's

As are some of Hector Santos' posts to various lists, re. the recent 
debacle.

Both of whom are probably far more qualified to address the technical 
details (on this one, I can talk primarily from the perspective of 
operational pain, and having to deal with the fallout).

John, Hector - want to collaborate on a "DMARC considered harmful" 
Internet draft?

Miles

---

From: Dick Franks <[email-masked]>
Date: Sun, 13 Apr 2014 21:41:31 +0100

On 13 April 2014 00:35, <[email-masked]> wrote:
[snip]

> The real question we should be discussing is what options the IETF has to

IETF has already adequately addressed this issue by its insistence on
inclusion of this statement in the document preamble:

  It is inappropriate to use Internet-Drafts as reference

An implementation based on I-D reference material is therefore no
better than "work in progress".

The blame for this debacle lies squarely with Yahoo, and its
inadequate engineering change management.

---

From: Dick Franks <[email-masked]>
Date: Sun, 13 Apr 2014 21:18:49 +0100

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Apr 2014 11:36:24 -0400

Dick Franks wrote:
>
>
> On 13 April 2014 00:35, <[email-masked] 
> <mailto:[email-masked]>> wrote:
> [snip]
>
>
> An implementation based on I-D reference material is therefore no better than "work in progress".
>
> The blame for this debacle lies squarely with Yahoo, and its inadequate engineering change management.
>

That's all in the fine print.  The folks behind DMARC are representing 
DMARC as both IETF standards-track - both implicitly (by pointing to a 
"specification" published as an IETF document) and explicitly (multiple 
statements along the lines of "intended as... " and "intend to submit), 
and as mature.  Yahoo is using that to justify it's actions ("Today, 80% 
of US email user accounts and over 2B accounts globally can be protected 
by the DMARC standard.")

By no sense of the imagination is DMARC a "standard" (or even much of a 
specification) - IETF or otherwise - much less a mature one.

To my mind, IETF's inaction, and silence is both morally wrong, and 
carries a longer term risk:

- as the Internet standards body, IETF and its participant have a 
professional and moral responsibility to speak for "what is an Internet 
standard," as well as what constitutes responsible implementation, 
deployment, and operation of Internet protocols -- not just leave it in 
the fine print

- IETF, to a large degree, dropped the ball on a "standard," that for 
some period of time was worked on under the aegis of an IETF WG

- allowing someone to represent something as an IETF standard carries a 
risk to IETF's standing, effectiveness, and credibility as the 
Internet's standards body (ISO tends to get very upset if someone claims 
to be ISO9000 certified, but isn't; Xerox sends lawyers after 
competitors who refer to their copiers as "xerox machines")

 From an operational perspective, concerned with the stability and 
reliability of the Internet infrastructure, this kind of thing really 
scares me - particularly in the larger context of current discussions 
over changes to Internet governance.  This strikes me as a very clear 
cut example where our voluntary, cooperative model for doing things is 
failing very badly -- in large part because none of our institutions of 
self-governance are stepping up to the plate.  ("We wrote a disclaimer 
in the fine print" is not stepping up to the plate.)

Miles Fidelman

---

From: Hector Santos <[email-masked]>
Date: Mon, 14 Apr 2014 13:29:18 -0400

This DMARC issue has finally hit our support forum today!

-------- Original Message --------
Subject: [WINServer] Lists, Yahoo and DMARC
Date: 	 Mon, 14 Apr 2014 12:51:38 -0400
From: 	 Kevin M. Agard <[email-masked]>
Reply-To: <[email-masked]>
To: 	 [email-masked]

Is anyone else running the wcListserver seeing bounces on messages to
Yahoo, MSN and Comcast due to these provider's DMARC configs??

What I am seeing is that any message originating from a @yahoo.com
address is being bounced by these domains with a 554 5.7.9: Message not
accepted for policy reasons error messages.

Interestingly enough, although Yahoo, MSN and Comcast all bounce these
messages, it is only messages from Yahoo that bounce. Messages
originating from MSN and Comcast make it through fine.

KMA
------------------------------------------

-- 
HLS

---

From: Dick Franks <[email-masked]>
Date: Mon, 14 Apr 2014 18:41:13 +0100

On 14 April 2014 16:36, Miles Fidelman <[email-masked]> wrote:

> Dick Franks wrote:
>
>
>> On 13 April 2014 00:35, <[email-masked] <mailto:
>> [email-masked]>> wrote:
>> [snip]
>>
> That's all in the fine print.

Indeed, but with blame so firmly attached, list operators need not be too
concerned about inconveniencing Yahoo customers by rejecting posts. Those
most affected will doubtless vote with their metaphorical feet.

> risk to IETF's standing, effectiveness, and credibility as the Internet's
> standards body (ISO tends to get very upset if someone claims to be ISO9000
> certified, but isn't; Xerox sends lawyers after competitors who refer to
> their copiers as "xerox machines")
>

Are you suggesting that IETF brings an action for trademark infringement?

Against whom?

A more pragmatic, less expensive, and publicly visible expression of IETF
displeasure might be to expunge all versions of the offending I-D from IETF
document store and refuse to publish any subsequent version until the
unwarranted claims made for it are retracted.

To be effective, that needs to be done now, while the iron is still hot;
not after the usual 3-month email debate about the diplomatic niceties.

---

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

> system fields. (Broadly speaking, From: for DKIM and MAIL FROM for SPF.)

Something's amiss here.  What new semantics does DKIM attach to From:?  As
far as I know, it only requires that the field be signed.  It doesn't
require that it be interpreted in a particular way or that it contain any
particular value.

> and why it's not a general solution to the problems caused by p=reject.

Yes, that's useful advice for a future revision.

> those mechansisms in the drafts is, IMO, entirely inadequate.

It's the same document that was posted on other web sites for some time,
and was in use by a number of operators (including Yahoo) long before it
went into the datatracker.

As it's only a draft, there's ample opportunity to make such improvements.

Also: By "the IETF published a draft", are you talking about an RFC, or the
DMARC base draft?  It seems extreme to lay blame on the IETF in general
merely for having an open mechanism by which to post a draft for all to see
and discuss.  A "Request For Comment", as it were.  Are you suggesting that
process should be closed or moderated somehow?

> existed in the earlier ADSP proposal. It was given insufficient attention

As with any draft, its content is only as good as its contributions and the
reviews it got.

> the best of intentions, managed to create.

I would add to this that, by its ultimate inaction in the face of a
protracted period of abuse and attempts by participants to solve that
problem within its procedures, the IETF has abdicated any authority it may
have had.

The real question we should be discussing is what options the IETF has to
> try

I certainly agree with that.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Apr 2014 10:56:58 -0700

On 4/14/2014 10:53 AM, Murray S. Kucherawy wrote:
> Something's amiss here.  What new semantics does DKIM attach to From:?
> As far as I know, it only requires that the field be signed.  It doesn't
> require that it be interpreted in a particular way or that it contain
> any particular value.

Correct.

DKIM does not carry any semantics about message content, other than the 
DKIM-Signature field.

A side-effect of the DKIM mechanism is some transit data integrity 
between signing and validation, but that has nothing to do with content 
'validity'.

DMARC, on the other hand, defines an "alignment" between the 
rfc5322.From field domain name and the domain name in the DKIM d= value 
and or (for SPF) the domain name in the rfc5321.MailFrom command.

d/

---

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

Dick Franks wrote:
>
>
> On 14 April 2014 16:36, Miles Fidelman <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Dick Franks wrote:
>
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>         [snip]
>
> Indeed, but with blame so firmly attached, list operators need not be 
> too concerned about inconveniencing Yahoo customers by rejecting 
> posts. Those most affected will doubtless vote with their metaphorical 
> feet.
>
>
>
>     - allowing someone to represent something as an IETF standard
>     carries a risk to IETF's standing, effectiveness, and credibility
>     as the Internet's standards body (ISO tends to get very upset if
>     someone claims to be ISO9000 certified, but isn't; Xerox sends
>     lawyers after competitors who refer to their copiers as "xerox
>     machines")
>
>
> A more pragmatic, less expensive, and publicly visible expression of 
> IETF displeasure might be to expunge all versions of the offending I-D 
> from IETF document store and refuse to publish any subsequent version 
> until the unwarranted claims made for it are retracted.
>
> To be effective, that needs to be done now, while the iron is still 
> hot; not after the usual 3-month email debate about the diplomatic 
> niceties.
>
The later, accompanied with a strong statement about the limits of 
DMARC, and the flaws in its deployment - might not be a bad start.

Miles

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Apr 2014 11:03:24 -0700

On Mon, Apr 14, 2014 at 11:01 AM, Miles Fidelman <[email-masked]
> wrote:

> DMARC, and the flaws in its deployment - might not be a bad start.

What real-world effect is this supposed to have, apart from setting a very
dangerous precedent?

-MSK

---

From: Warren Kumari <[email-masked]>
Date: Mon, 14 Apr 2014 14:43:43 -0400

On Sat, Apr 12, 2014 at 4:30 PM, Dave Crocker <[email-masked]> wrote:
> While the Internet-Draft mechanism is operated by the IETF, it is an open
> mechanism and issuance through it carries no automatic status, particularly
> with respect to the IETF.

It seems that folk often miss this particular point (see the recent
drama about draft-loreto-httpbis-trusted-proxy20). Pointing at the
boilerplate, explaining the fact that anyone (with an Internet
connection and an XML editor) can submit an ID, etc doesn't seem to
work. I considered pointing at, well, anything by Terrell, but instead
decided to publish a draft :-P

http://tools.ietf.org/html/draft-wkumari-not-a-draft-00

Comments welcome.
W

> I haven't seen anyone present such a claim of blessing.  Please point to the
> specifics.
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 14 Apr 2014 11:47:27 -0700

> http://tools.ietf.org/html/draft-wkumari-not-a-draft-00

Let me know if you need a document shepherd.

-MSK

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 14 Apr 2014 18:55:00 +0000

From: ietf [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Monday, April 14, 2014 1:54 PM
To: [email-masked]
Cc: ietf
Subject: Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists

On Sat, Apr 12, 2014 at 4:35 PM, <[email-masked]<mailto:[email-masked]>> wrote:
The underlying technical issue is that the two technologies DMARC is built on -
DKIM and SPF - both attach additional/restrictive semantics to longstanding mail
system fields. (Broadly speaking, From: for DKIM and MAIL FROM for SPF.)

Something's amiss here.  What new semantics does DKIM attach to From:?  As far as I know, it only requires that the field be signed.  It doesn't require that it be interpreted in a particular way or that it contain any particular value.

It's the same document that was posted on other web sites for some time, and was in use by a number of operators (including Yahoo) long before it went into the datatracker.
As it's only a draft, there's ample opportunity to make such improvements.
Also: By "the IETF published a draft", are you talking about an RFC, or the DMARC base draft?  It seems extreme to lay blame on the IETF in general merely for having an open mechanism by which to post a draft for all to see and discuss.  A "Request For Comment", as it were.  Are you suggesting that process should be closed or moderated somehow?

MH: I’m going to disagree with your statement about insufficient attention Ned. I’ve been reviewing the discussions from the DKIM working group at that time (early 2008) and there was in fact quite a bit of attention given to the issue in the context of SSP and the discussion got quite heated. One such discussion at that time was “RE: [ietf-dkim] Re: ISSUE 1521 -- Limit the application of SSP tounsigned messages”. One position in that discussion was that mail lists could be trusted and therefore should supercede any policy assertions by domain owners made through SSP (which name was changed at my suggestion because the standard represented domain policy assertions and not individual sender assertions). The discussion of mail lists in the context of email authentication has been exhaustive (both literally and figuratively) on multiple occasions and in multiple places for some time frame approaching a decade if not longer.

As with any draft, its content is only as good as its contributions and the reviews it got.

MH: The reality is that there was a compromise to get ADSP set and out the door with the understanding that once there was some experience running in the wild “we” would circle back and remediate identified issues. It was a bad compromise and there were even some that stated at the time, the compromise was intended to kill ADSP. If I had it to do over again I would be more resistant to compromise regarding the MLM issue even if it had meant ADSP not getting out the door.

I would add to this that, by its ultimate inaction in the face of a protracted period of abuse and attempts by participants to solve that problem within its procedures, the IETF has abdicated any authority it may have had.

MH: I’m not sure I would go this far but I think it reflects concerns held by many.

MH: First there needs to be a consensus as to what “this” is before there can be an attempt to address “this”.

-MSK

---

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

> http://tools.ietf.org/html/draft-wkumari-not-a-draft-00

Well yes, but that's the "fine print."

Who ever reads a 20-page shrink-wrap license - and he jury is still out 
as to when those apply or can be ignored.  And then there's a "warrant 
of merchantability" that vendors can be held to despite all kinds of 
disclaimers buried in a license.

When the organization that coordinated and promulgated DMARC:
- describes their efforts as "their common goal was to develop an 
operational specification to be introduced to the IETF for standardization
- refers to the only defining document as a "Base Specification" and 
links to a document, on the IETF's webserver, with an IETF document number

It's kind of easy for the uninitiated to draw the conclusion that it's a 
standards-track IETF standard.

Then, when Yahoo defends the havoc they've wrought with statements like 
(they) "designed and built something called DMARC 
<http://www.dmarc.org/>, or Domain-based Message Authentication, 
Reporting and Conformance. Today, 80% of US email user accounts and over 
2B accounts globally can be protected by the DMARC standard." - with a 
pointer to dmarc.org - and from there to an IETF webserver and document 
-- it sure is easy for the general community to draw the conclusion 
"Yahoo implemented a vetted IETF standard - and it broke all the mailing 
lists I'm on."  And it sure is easy for someone to draw the conclusion 
that the fault lies with the broken standard, not with Yahoo.

You have to look hard to figure out who really broke what.  And (IMHO) 
one would not be wrong to draw the conclusion that IETF dropped the ball 
in its role as the Internet standards body - if only in it's relative 
silence (a disclaimer in the fine print does not constitute exercising 
one's professional or institutional responsibilities).

ISO, for example, has processes for complaining about mis-use of their 
standards, and about misrepresentation of being certified against a 
standard.  Perhaps it's time for IETF to institute similar policies and 
proceedures - beyond:
"it's not actually a standard - we just provided space for the document"
"it's a voluntary standard, we're not responsible if it's not 
implemented properly, or not deployed properly"

We all claim that we don't want governments to run the Internet - but 
when our voluntary, cooperative mechanisms drop the ball - that's the 
end result.  (Along with lots of litigation.)

Just one man's opinion, of course.

Miles Fidelman

---

From: Dick Franks <[email-masked]>
Date: Mon, 14 Apr 2014 21:24:46 +0100

On 14 April 2014 19:03, Murray S. Kucherawy <[email-masked]> wrote:

> On Mon, Apr 14, 2014 at 11:01 AM, Miles Fidelman <
> [email-masked]> wrote:
>
>
>>
>>> IETF displeasure might be to expunge all versions of the offending I-D from
>>> IETF document store and refuse to publish any subsequent version until the
1)  Invalidates the inappropriate document citations on DMARC site.

2)  Publicly refutes any claim that this is an IETF standardisation effort.

Robust action in defence of IETF reputation is possibly a precedent worth
setting.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Apr 2014 08:46:10 +1200

> Robust action in defence of IETF reputation is possibly a precedent worth

Not at the price of looking like censorship and distorting the
historical record.

We have very carefully designed boilerplate, and the point of
boilerplate is precisely that it's there even if people don't
read it. We're an open voluntary standards organisation;
we're still not the Internet Police.

I'm strongly against removing drafts from the public record unless
they are obscene or libellous.

   Brian

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 14 Apr 2014 22:54:16 +0200

On 04/14/2014 07:53 PM, Murray S. Kucherawy wrote:
> On Sat, Apr 12, 2014 at 4:35 PM, <[email-masked] 
> Something's amiss here.  What new semantics does DKIM attach to 
> From:?  As far as I know, it only requires that the field be signed.  
> It doesn't require that it be interpreted in a particular way or that 
> it contain any particular value.
>
> It's the same document that was posted on other web sites for some 
> time, and was in use by a number of operators (including Yahoo) long 
> before it went into the datatracker.
>
> Also: By "the IETF published a draft", are you talking about an RFC, 
> or the DMARC base draft?  It seems extreme to lay blame on the IETF in 
> general merely for having an open mechanism by which to post a draft 
> for all to see and discuss.  A "Request For Comment", as it were.  Are 
> you suggesting that process should be closed or moderated somehow?
>
> problem within its procedures, the IETF has abdicated any authority it 
> may have had.

This might have been true if:

1. Yahoo _did_ solve the abuse problem and
2. the decision making process within a closed industry consortium with 
maybe less than 20 members, representing immense commercial power, could 
be compared to the process of consensus, that's being used within IETF.

Ad 1. Yahoo only solved some of the problem, for some time and only for 
themselves. But we have seen that bad guys have adapted faster than 
anyone else to new technologies:
- 90% of all mail agents show the display-name in the From field and 
with the current move towards mobile devices this percentage will likely 
further increase;
- Yahoo doesn't use the From:From construct to enable receivers to 
detect use of multiple From: fields;
- developments like EAI will help bad guys to find lookalike 
domains/cousin domains [1], [2]
Ad 2. I assume this doesn't need further explanation.

/rolf

[1] http://www.ietf.org/mail-archive/web/dmarc/current/msg00370.html
[2] http://en.wikipedia.org/wiki/IDN_homograph_attack

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Apr 2014 14:14:25 -0700

...
> be compared to the process of consensus, that's being used within IETF.

By way of pressing a particular process issue, without commenting on any 
of the surrounding issues:

    It's certainly true that the DMARC specification has not gone 
through an IETF approval process.

    That said, the document has been subject to open review for quite 
awhile, first (and continuing) via a mailing list at dmarc.org and more 
recently also one hosted at the IETF.  And the handling of reviews has 
been substantive.  Again, not an IETF open process, but substantive.

    Over quite a few months, there were a number of aggressive efforts 
to solicit community suggestions and agreement about the engineering 
work or document refinement work needed on the specification.

    Nothing close to rough consensus developed for any technical or 
documentation work.  Not on the dmarc.org list and not on the IETF's 
dmarc list.

If the community wanted changes to the specification, it had quite a bit 
of opportunity to call for the changes and/or call for  doing such work 
in the IETF.

d/

---

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

> 1)  Invalidates the inappropriate document citations on DMARC site.

I think you give them more weight than is justified.

> 2)  Publicly refutes any claim that this is an IETF standardisation effort.

Any such claim is merely outdated and needs correction.  DMARC did seek
standardization, but it was effectively denied.

> Robust action in defence of IETF reputation is possibly a precedent worth

I suggest the price of going about it the way you described will do far
more harm than good, for reasons Brian has already cited.

-MSK

---

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

> 1. Yahoo _did_ solve the abuse problem and

We'll have to wait for them to tell us whether it did.  Anything we
conclude is our perspective, not theirs.

> maybe less than 20 members, representing immense commercial power, could be
> compared to the process of consensus, that's being used within IETF.
>

The consortium hasn't been closed for a long time.  A public mailing list
outside the IETF was announced and created, and then a second one
maintained at the IETF, both of which have been places from which
suggestions from the general community have been discussed, accepted, and
incorporated into revisions.  There was furthermore a BoF to create a
working group held a couple of IETF meetings ago.  It's not correct to
claim this has been closed the entire time any more than DKIM was.

-MSK

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Apr 2014 17:42:51 -0400

> they are obscene or libellous.
Big red disclaimer at the top then:
- THIS IS A DRAFT DISCUSSION MEMO
- THIS IS NOT A STANDARDS-TRACK SPECIFICATION
- THIS IS AN INDEPENDENT SUBMISSION, NOT AN IETF DOCUMENT
- SHOULD NOT BE USED AS THE BASIS FOR OPERATIONAL DEPLOYMENT OF PROTOCOL 
SOFTWARE

---

From: Dave Cridland <[email-masked]>
Date: Mon, 14 Apr 2014 23:06:24 +0100

> - SHOULD NOT BE USED AS THE BASIS FOR OPERATIONAL DEPLOYMENT OF PROTOCOL
It doesn't matter. The fact that DMARC is an I-D at all is largely
incidental.

If Yahoo had privately developed DMARC in a consortium under entirely
different practice and operational rules than the IETF, where any
participants in their mailing lists would have no clue how their
contributions might be used, and without any review by the IETF as a whole,
and then that consortium had published the result as an I-D, it'd be
exactly the same situation as we are now.

Dave.

---

From: Dick Franks <[email-masked]>
Date: Tue, 15 Apr 2014 02:05:51 +0100

On 14 April 2014 22:17, Murray S. Kucherawy <[email-masked]> wrote:

> Any such claim is merely outdated and needs correction.
>

 Correct it and the objection goes away.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Apr 2014 13:45:15 +1200

I thought that standard operating procedure in the IT industry
was: if you roll something out and it causes serious breakage to
some of your users, you roll it back as soon as possible.

Why hasn't Yahoo rolled back its 'reject' policy by now?

Regards
   Brian

---

From: Doug Barton <[email-masked]>
Date: Mon, 14 Apr 2014 20:04:15 -0700

> Why hasn't Yahoo rolled back its 'reject' policy by now?

Simple ... from Yahoo!'s perspective the breakage is negligible, not 
serious. Traditional e-mail traffic to and from traditional e-mail lists 
(like this one) is simply not large enough to lose sleep over. Keep in 
mind, Yahoo! knew what breakage was going to occur before they threw the 
switch, and they threw the switch anyway.

Again, I realize that it's hard for most IETF'ers to conceive of, but in 
this matter we are the ultimate anachronists.

Doug

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Apr 2014 23:12:03 -0400

> Why hasn't Yahoo rolled back its 'reject' policy by now?
That really is a great question.

I guess the one that immediately follows is - why has there not been a 
strong call for them to do so?

Miles

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 14 Apr 2014 23:13:15 -0400

Doug Barton wrote:
> serious. Traditional e-mail traffic to and from traditional e-mail 
> lists (like this one) is simply not large enough to lose sleep over. 
> Keep in mind, Yahoo! knew what breakage was going to occur before they 
> threw the switch, and they threw the switch anyway.
>
> Again, I realize that it's hard for most IETF'ers to conceive of, but 
> in this matter we are the ultimate anachronists.
>
Only by abdication.  That's reversible.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Apr 2014 22:19:49 -0500

On Apr 14, 2014, at 3:24 PM, Dick Franks <[email-masked]> wrote:
> Robust action in defence of IETF reputation is possibly a precedent worth setting.

Robust, wrong action in defense of IETF reputation is a precedent worth avoiding.   The quoted statement makes no assertions about IETF policy, but simply says the proponents of DMARC would like to publish the spec through the IETF.   There is nothing wrong with them saying this.   If you think it means the IETF has endorsed the spec, no amount of word-smithing or protest is going to help.   More likely it's going to be a sound bite on some news program talking about a dispute between "those crazy boffins."

---

From: Theodore Ts'o <[email-masked]>
Date: Mon, 14 Apr 2014 23:23:13 -0400

On Mon, Apr 14, 2014 at 08:04:15PM -0700, Doug Barton wrote:
> (like this one) is simply not large enough to lose sleep over. Keep in mind,
> Yahoo! knew what breakage was going to occur before they threw the switch,
> and they threw the switch anyway.
> 

The problem is that e-mail volume really is the wrong way to measure
"breakage".  After all, the vast majority of e-mail may be SPAM, but
that doesn't mean that those e-mail messages are the ones that any
users care about.

I've already had to send out message to my church's vestry (governing
board) explaining that people who are using Yahoo aren't going to be
able to send to the church mailing lists reliably, and that for now,
until I can get around to fixing the mailing list software (hint: not
during Holy Week), that their messages will be held for moderation
until someone can manually cut and paste it and send it on their
behalf.

I've also explained that if they care, they should consider
complaining to Yahoo and/or switching e-mail providers.

If enough people do the same, maybe Yahoo will reconsider.  If not, so
long most of my e-mail community switches mail providers (i.e.,
treating yahoo.com as damage, and routing around it), I may not care
all that much.

In the maintime, if someone has had the time to hack together some
patches to mailman to write the from field of yahoo.com users to be
yahoo.com.INVALID.  Please send them my way; I'll be most grateful.

		    	   	     	- Ted

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 14 Apr 2014 23:56:23 -0400

> of opportunity to call for the changes and/or call for  doing such work

Not really.  As long as change control is outside the IETF and it's normal 
processes, outsiders to the core group can call for change and that change can 
be accepted or ignored be the insiders in the group with none of the normal 
IETF processes that resolve issues and lead to rough consensus.

It's not a very attractive environment to expend ones "free" time in.  I did 
some review of the spec, but certainly would be been more motivated to do a 
more thorough and complete job in the context of a WG.

Scott K

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 15 Apr 2014 05:02:20 +0100

The standard procedure in many companies is business scoped, so they
identify important business users and the business returns/damages. Most
important users are not IT experts, and use email for personal exchange. Yahoo
has signed an agreement with users to protect its information system, so
all seem to follow that, and all users are free to stop using services or
not.

AB

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 15 Apr 2014 00:07:38 -0400

Important business users, with Yahoo accounts?  Is that a joke?

Just as a reference point:
- I just logged into my long-unused, and un-publicized yahoo email 
account - and the only thing there is Spam
- the lion's share of mail that comes from yahoo, to my normal account, 
is spam
- unfortunately, a good number of people on the email lists that I run 
seem to have Yahoo mail accounts - and a good amount of the mail that 
comes from those accounts is... you guessed it... spam - because yahoo 
email accounts seem to be vulnerable to cracking and exploitation

So, just who is it that Yahoo is protecting here?

Abdussalam Baryun wrote:
> identify important business users and the business returns/damages. 
> Most important users are not IT experts, and use email for personal 
> exchange. Yahoo has signed an agreement with users to protect its 
> information system, so all seem to follow that, and all users are free 
> to stop using services or not.
>
> AB
>

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Tue, 15 Apr 2014 05:32:19 +0100

> IETF processes that resolve issues and lead to rough consensus.

Yes.

Basically DMARC was always an outsider effort.  The effect of a bunch of very important ESPs (and a bunch of security types) crying "Look!  We've solved the email forgery problem!" was to inspire me to look at the spec, shrug it off as yet another FUSSP *, and move on.  Does this mean that I have materially failed to contribute?  Well maybe, but it means a lot for the spec to be in the IETF where I can point out how broken it is. :)

And, to be clear: I respect the goals of the proposal, and will be reasonable in accommodating it.  But to suggest that the contortions of the proponents in keeping it from the watchful eye of the IETF weren't in some small way intended to advance DMARC by force in numbers rather than consensus strains credulity, just a tad.

Cheers,
Sabahattin

* https://twitter.com/sgucukoglu/status/174104462758133760

---

From: Seth Johnson <[email-masked]>
Date: Tue, 15 Apr 2014 01:20:21 -0400

The framework internationally is different.  Within free countries, there's
a culture of expectations that certain things will be unacceptable, or will
be resisted by self-respecting citizens.  That culture is based in a system
that guards fundamental liberties, and people are able to rely on it to do
so, though for private firms the limits aren't so definitive as they are
for the government.

Internationally, the limits are no longer so definitive, and that's because
even though governments will sign onto instruments like the UDHR, those
rights are not actually fundamental, even if we call them that.
Fundamental rights have an undeniable priority within countries where they
have been claimed in the founding act.  On that foundation, judges are
always obliged to assess fundamental rights in light of the unarguable fact
that their priority over the government was part of the original creation
of the whole system.  There's no founding act in the international arena
that sets the priority of people over the governments of the world, so
rights are actually at the indulgence of governments, and governments can
always assert their state interests are so important that they warrant
impinging on fundamental liberties.

We just saw an example of this with the Snowden disclosures.  We've been
through a long period where we couldn't get our government to actually do
much for us, or conversely to not invade our liberties -- because the
claims that the government was snooping pervasively were kept marginal.
But once documentation moved those considerations, we suddenly began seeing
the appeals work again: that's not the kind of country we are, what we set
up for ourselves.  And while it's still in a bit of denial, we are seeing a
gradual grudging retracting -- again, because the basis in fundamental
liberties is unarguably related to how we set the government up in the
founding act(s).

This is for governments and the more definitive relationship between
fundamental liberties and the government; that is, that they are limits on
the government.  The judicial system treats fundamental rights violations
by the government in terms of "strict scrutiny," which means a governmental
act that impinges on fundamental liberties must serve a compelling state
interest, and even then, must be narrowly tailored.  For private parties,
it's more that the working system creates a culture of people who enjoy
this ability to live in a system where these limits on the government are
actually at play -- and that's a context that more easily supports
attitudes of resistance and pushback from people who see their dignity
invaded by private firms that do excessive things.

None of this exists internationally.  The best you can place some faint
hope in is that national/state interests will be "balanced" against rights
expressed in a treaty.  That's a totally different standard from strict
scrutiny.  And relying on even that is unrealistic, because governments
have the "epistemic priority" -- and so they often, quite freely, simply
claim their sovereignty and act according to what they claim is an
important state interest.  They simply have that wherewithal at the
international level.

All of which is preface to say that the result is that governments and
private parties (and corporations, who have concocted trans-state "rights"
through judges acting to fill in gaps in the law over the years) know the
rules don't apply the same way in the international arena.

In fact, given the transitions currently being attempted, whether with the
IANA functions or "Internet governance" more generally, Yahoo's DMARC
behavior may really be a sort of dry run, testing the ability to take
advantage of the moves to put concerns related to the operation of the
Internet into an international frame, which folks are pushing for without
really recognizing what's missing in that context, what they have sort of
unconsciously relied on and taken for granted within systems of checks and
balances that are rooted solidly at national levels.

The checks and balances don't work the same internationally, and that
circumstance can be exploited (and is, all the times, these days).

People might push back, but they don't really do so with the same sense of
fundamental recourse assured by a solidly rooted system.  And Yahoo knows
this.  And we're just shoring that up by saying we can just switch
multistakeholderism to the international arena.

(All of this is aside from other factors not generally acknowledged -- that
there are actually inter-governmentally endorsed frames in place that will
have a bearing on IANA type functions or domain names (Names, Numbers,
Addresses and Identifiers/NNAI, in the ITU parlance), regardless of the
fact the IANA transition defines itself as non-governmentally-led or
inter-governmental.  Looking at this in that light, Yahoo may be forcing
the creation of a context in which it can start to exercise those
frameworks.)

Seth

On Tue, Apr 15, 2014 at 12:07 AM, Miles Fidelman <[email-masked]

> - I just logged into my long-unused, and un-publicized yahoo email account
> - and the only thing there is Spam
> - the lion's share of mail that comes from yahoo, to my normal account, is
> spam
> seem to have Yahoo mail accounts - and a good amount of the mail that comes
> from those accounts is... you guessed it... spam - because yahoo email
> accounts seem to be vulnerable to cracking and exploitation
>
>> important users are not IT experts, and use email for personal exchange.
>> Yahoo has signed an agreement with users to protect its information system,
>> so all seem to follow that, and all users are free to stop using services
>> or not.
>>
>> AB
>>

---

From: Seth Johnson <[email-masked]>
Date: Tue, 15 Apr 2014 01:29:19 -0400

(one insert/correction inline)

On Tue, Apr 15, 2014 at 1:20 AM, Seth Johnson <[email-masked]>wrote:

> The framework internationally is different.  Within free countries,
> there's a culture of expectations that certain things will be unacceptable,
> or will be resisted by self-respecting citizens.  That culture is based in
> a system that guards fundamental liberties, and people are able to rely on
> it to do so, though for private firms the limits aren't so definitive as
> they are for the government.
>
> Internationally, the limits are no longer so definitive, and that's
> because even though governments will sign onto instruments like the UDHR,
> those rights are not actually fundamental, even if we call them that.
> claims that the government was snooping pervasively were kept marginal in
> various ways.
>

<fixed>

> But once documentation moved those considerations out of the frame of
> "conspiracy" or zealotry by activist organizations, we suddenly began
> seeing the appeals work again: "that's not the kind of country we are, what
> we set up for ourselves," we started saying again.
>
</fixed>

(eom)

> And while it's still in a bit of denial, we are seeing a gradual grudging
> retracting -- again, because the basis in fundamental liberties is
> unarguably related to how we set the government up in the founding act(s).
>
> circumstance can be exploited (and is, all the time, these days).
>
> (All of this is aside from other factors not generally acknowledged --
> that there are actually inter-governmentally endorsed frames in place that
> will have a bearing on IANA type functions or domain names (Names, Numbers,
> On Tue, Apr 15, 2014 at 12:07 AM, Miles Fidelman <

---

From: <[email-masked]>
Date: Tue, 15 Apr 2014 06:57:37 +0100

> Important business users, with Yahoo accounts?  Is that a joke?

If you've ever done business in the third world, you will find
that government officials use e.g. Yahoo accounts, because
they're more reliable than their local provider, and, unlike the
local provider, aren't spamblocked.

Yes, this makes telling the actual government officials from the
fraudsters pretending to be government officials a bit more work -
personal relationships, introductions, and whatnot.

Lloyd Wood
http://about.me/lloydwood

---

From: Seth Johnson <[email-masked]>
Date: Tue, 15 Apr 2014 07:36:25 -0400

Jimmy Wales is, perhaps partially unconsciously, referencing this with his
point on a "culture of free expression."

Note: I am not implying in making these observations that stewardship
should be by any particular country, or any number less than the totality
for that matter -- only that we rely on systems that we have claimed for
the people to create such a context, and the international arena (and the
various systems so far presented for "checks and balances" or even simply
handoff to privatized systems to multistakeholder-ish processes that must
not be government-led or inter-governmental) does not presently support
that.

Seth

Seth

On Tue, Apr 15, 2014 at 1:29 AM, Seth Johnson <[email-masked]>wrote:

>> In fact, given the transitions currently being attempted, whether with
>> the IANA functions or "Internet governance" more generally, Yahoo's DMARC
>> People might push back, but they don't really do so with the same sense
>> of fundamental recourse assured by a solidly rooted system.  And Yahoo
>> knows this.  And we're just shoring that up by saying we can just switch

---

From: Dave Crocker <[email-masked]>
Date: Tue, 15 Apr 2014 08:49:42 -0700

> Why hasn't Yahoo rolled back its 'reject' policy by now?

As the most-recent public statement from Yahoo, this might have some 
tidbits in it that are relevant to your question:

http://yahoo.tumblr.com/post/82426971544/an-update-on-our-dmarc-policy-to-protect-our-users

d/

---

From: Hector Santos <[email-masked]>
Date: Tue, 15 Apr 2014 12:02:49 -0400

> Basically DMARC was always an outsider effort.  The effect of a bunch of very important ESPs (and a bunch of security types) crying "Look!  We've solved the email forgery problem!" was to inspire m…

I feel the same way.

But after the whole stressful, wasteful dollars, time and energy 
situation over 9 years starting with DKIM+SSP, reduced to DKIM+ADSP or 
DKIM+POLICY in general,  it is not healthy to repeat this with DMARC.

It was clear DMARC couldn't address the key central total mail 
integration support requirements if it lacked two things:

   - 3rd party policies,
   - MLM/MLS support for restrictive policies.

> And, to be clear: I respect the goals of the proposal, and will be reasonable in accommodating it.  But to suggest that the contortions of the proponents in keeping it from the watchful eye of the…

Yes, that was an obvious problem, marketing hype we tend to ignore, 
but it was a concern that they were just repeating the same issues. 
Lets remember that DMARC was more about reporting than actually 
honoring and literally "rejecting" transactions.  Reporting was since 
as a potential mail-based DoS attack vector. So my input was to limit 
it to TESTING periods and under abuse controls when it was suggested 
to DKIM+POLICY reporting.

We saw this again repeated with SPF when in the SPFBIS, the same 
people mind you, began to add DOUBT on the whether anyone actually did 
reject mail and just simply quarantine the mail.  So it became a battle of

       SPFFAIL+REJECT vs SPFFAIL+ACCEPT+MARK

When I saw that mentality grow, I raised an SPFBIS issue to make sure 
we describe in the spec as two alternative implementation and 
deployment option:

    - SPFFAIL+REJECT
    - SPFFAIL+ACCEPT+MARK+SEPARATE

Without separation, we have a security loophole if the deployment did 
not operate by rejecting SPF Failure but instead accepted, marked it 
with an Auth-Res header but still delivered the failed message to the 
user.

And guess what?

Its happening now again with the new Yahoo/Facebook RRVS proposal. 
Again, they are raising the question if whether a reject should be 
taken literally or not.

IMO, what has occurred now is a realization that there are actual 
systems that are beginning to actually reject the mail based on 
restrictive policies.  When it happen to a big long time publicly used 
domain like yahoo.com, now it became a major problem.

Anyway, it is really too tiresome and stressful to repeat all this.

I thought it was a major mistake and IETF error to make ADSP historic, 
done to help make way for DMARC.  Who are we kidding?  But if thats 
the case, once again, the solution is simple:

  - Add 3rd party policy support,

  - In DMARC deployment guide, provide strong semantics for MiddleWare
    to support policies.  It can not be ignored.

With the latter, it was a mistake in the DKIM deployment guide to not 
raise an  Middle Ware resigning implementation note about not honoring 
ADSP checking.  This issue was raised when the document was written 
but largely ignored.

Again, we been through all this. It is all covered with the DKIM 
threat analysis and one of the main conclusions is that self-signing 
1st party policies are a powerful method to protect against fraud. 
ADSP was a proposed standard track work item along with DKIM-base. 
DKIM-WG ended on a sour note never resolving this basic issue.

The only reason common agreement and question was whether we can scale 
the 3rd party domain authorizations.

So what did we do?

Eventually, Murray saw the issue wouldn't go away. I talked about ASL 
(Authorized Signer List) which piggy backed off the ADSP record. It 
was meant for the smaller systems. Doug Otis talked about TPA (Third 
Party Authorization) but it was too complex.  So Murray did ATPS as an 
ADSP extension to help with the complexity and scalability questions.

See the wizard at

   http://www.winserver.com/public/wcadsp

which allows you to create zone records for ADSP+ATPS+ACL domains.  We 
implemented this into our software and mail system product, including 
the MLS that will deny restrictive ADSP domains.

The work was done.  The solutions and conflicts are known. The 
question is more a matter of getting people to accept policy more or 
as some will like, get rid of it or just don't really honor any kind 
of mail rejection -- always accept, mark and hopefully separate.

And lets not forget, the DKIM+TRUST model which is what Crocker and 
Levine want to see happen.  This market has not materialized 
unfortunately, which would be different than the DKIM+POLICY 
framework, in that TRUST requires all nodes in the system to query the 
same trust databases, otherwise we lack consistency and persistency in 
mail distributions.  Some nodes will become targets if they lack 
subscription to a 3rd party TRUST query system.

-- 
HLS

---

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

> http://yahoo.tumblr.com/post/82426971544/an-update-on-our-dmarc-policy-to-protect-our-users 
You mean the part where they say:
"We know there are about 30,000 affected email sending services, but we 
also know that the change needed to support our new DMARC policy is 
important and not terribly  difficult to implement. We have detailed the 
changes we are requiring here 
<http://yahoomail.tumblr.com/post/82426900353/yahoo-dmarc-policy-change-what-should-senders-do>."

I.e., 'not our problem'

Miles Fidelman

---

From: Seth Johnson <[email-masked]>
Date: Tue, 15 Apr 2014 12:46:15 -0400

They're forcing adoption -- while folks have not been addressing this piece
of the inter-governmental frame.  :-)

On Tue, Apr 15, 2014 at 12:35 PM, Miles Fidelman <[email-masked]

> changes we are requiring here <http://yahoomail.tumblr.com/
> post/82426900353/yahoo-dmarc-policy-change-what-should-senders-do>."
>
> I.e., 'not our problem'
>
> Miles Fidelman
>
>
> --

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 15 Apr 2014 12:52:33 -0400

Which does bring us back to the question of how to deal with "bad 
actors" (or at least "irresponsible actors" or "uncooperative actors") 
within a cooperative governance framework.  Sigh.... Miles

Seth Johnson wrote:
> They're forcing adoption -- while folks have not been addressing this 
> piece of the inter-governmental frame.  :-)
>
>
> On Tue, Apr 15, 2014 at 12:35 PM, Miles Fidelman 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Dave Crocker wrote:
>
>         As the most-recent public statement from Yahoo, this might
>         have some tidbits in it that are relevant to your question:
>
>
>
>     "We know there are about 30,000 affected email sending services,
>     but we also know that the change needed to support our new DMARC
>     policy is important and not terribly  difficult to implement. We
>     have detailed the changes we are requiring here

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 15 Apr 2014 10:00:50 -0700

> within a cooperative governance framework.  Sigh.... Miles

Welcome to the club. I've been wondering about that same issue with
regards to getting adoption of BCP38 for over a decade. :-)

- ferg

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

-- 
Paul Ferguson
VP Threat Intelligence, IID
PGP Public Key ID: 0x54DC85B2

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 15 Apr 2014 13:16:30 -0400

> regards to getting adoption of BCP38 for over a decade. :-)
Well, seriously, though - people do respond to large-scale ddos attacks, 
as well as to things like propagation of corrupted routing BGP tables - 
both operationally, and sometimes legally.  What are the ways that 
people deal with those who are propagating such information, when they 
don't cooperate, and particularly when they don't cooperate 
intentionally?  What recourse comes into the picture?

CERT comes to mind.  So does the CFAA (Computer Fraud and Abuse Act).  
But what about general principles for institutional response?

Miles Fidelman

---

From: Hector Santos <[email-masked]>
Date: Tue, 15 Apr 2014 13:38:50 -0400

> http://yahoo.tumblr.com/post/82426971544/an-update-on-our-dmarc-policy-to-protect-our-users

Thanks for the link.

Yes, it does provide some insight, but it would be nice if YAHOO made 
an official statement to provide vendors with planning decisions.

This is GOOD NEWS.

What it means that POLICY has won. I believe a policy-based DKIM 
framework is best and I invested in ADSP and its extensions.   Many 
never believed in ADSP or policy based protocols but you have changed 
your position and now promote DMARC as the way to go.  Thats great Dave.

But as I have been saying and largely ignored, it didn't still solve 
the problem unless the MLM supported the handling of restricted 
policies as well -- gracefully.  It doesn't matter if its ADSP or DMARC.

Yahoo has FORCE the issue so in that way, I am happy.

What it means is that I will now begin exploring DMARC implementation 
into our already laid out DKIM framework using ADSP.  Maybe we can 
finally get some payoff and value from all this DKIM work after all!!

I have to note the yahoo.com impact on our system was low. The few 
yahoo.com accounts in our support list was down to four and this was 
going on since January with no complaints.  But the fact, Yahoo hasn't 
roll back or relaxed its policy in over 4 months, DMARC is probably 
here to stay now!!

As the Jeff says:

    "With stricter DMARC policies, users are safer, and the
     bad guys will be in a tough spot. More importantly,
     verified senders will unlock a massive wave of innovation
     and advancement for all our inboxes."

Its time for the IETF to support DMARC.  We can do this using DMARC 
Extensions. Maybe Murray can consider writing DMARC extensions like 
ATPS  but using DMARC as the base call.  It should be a minor change 
to the ATPS specs.

I can see additional DMARC extensions for other advancements, but the 
main one is about managing 3rd party authorized domain to satisfy the 
"signing/sent on behalf of" design need that yahoo says is required:

    "Yahoo requires external email service providers, such as
     those who manage distribution lists, to cease using unsigned
     “sent from” mail, and switch to a more accurate “sent on
     behalf of” policy."

What is this so called "more accurate" method?

-- 
HLS

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 15 Apr 2014 13:52:57 -0400

> What is this so called "more accurate" method?
And more to the point - what is a standard for representing 
"sent-on-behalf-of" that software developers can rely on when making 
changes to list software and user agents.  (Or even better, a way to 
represent it that allows standard reply and address functions to 
continue working tranparently).

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 15 Apr 2014 18:16:33 +0000

> -----Original Message-----
> From: ietf [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Tuesday, April 15, 2014 1:39 PM
> To: [email-masked]; Brian E Carpenter; IETF Discussion
> Subject: Re: What I've been wondering about the DMARC problem
> 
> >> was: if you roll something out and it causes serious breakage to some
> >> of your users, you roll it back as soon as possible.
> >>
> > http://yahoo.tumblr.com/post/82426971544/an-update-on-our-dmarc-
> policy
> > -to-protect-our-users
> 
> Thanks for the link.
> 
> Yes, it does provide some insight, but it would be nice if YAHOO made an
> official statement to provide vendors with planning decisions.
> 

Just curious, what sort of statement would you like to see? How would it help with vendor planning decisions?

> never believed in ADSP or policy based protocols but you have changed your
> position and now promote DMARC as the way to go.  Thats great Dave.
> 

I've believed in policy for quite some time (pre-dating SSP/ADSP). The only problem with ADSP was that we agreed to a compromise that left it too inflexible and crippled. Lesson learned.

> But as I have been saying and largely ignored, it didn't still solve the problem
> unless the MLM supported the handling of restricted policies as well --
> gracefully.  It doesn't matter if its ADSP or DMARC.
> 
> What it means is that I will now begin exploring DMARC implementation into
> our already laid out DKIM framework using ADSP.  Maybe we can finally get
> some payoff and value from all this DKIM work after all!!
> 

I'm looking forward to hearing your thoughts and questions and I'm sure others do as well. Is this list the best place for this or is there somewhere else more appropriate?

> yahoo.com accounts in our support list was down to four and this was going
> on since January with no complaints.  But the fact, Yahoo hasn't roll back or
> relaxed its policy in over 4 months, DMARC is probably here to stay now!!
> 

Hector, Yahoo implemented the change a week ago Friday, not 4 months ago. I'm sure they have received complaints. 

I'd love it if at some later point someone that was involved in the Yahoo decision process writes something about the events that started them thinking about making the change and the decision making process involved. It would be nice to have insight into how and why they decided to go ahead without giving anyone prior notice. How did it impact customer support and what kind of plan was in place (and how well did it work)? How did they deal with partners and vendors? In other words it would be a compelling case study whether one thinks their action was good or horrible.

> Extensions. Maybe Murray can consider writing DMARC extensions like ATPS
> but using DMARC as the base call.  It should be a minor change to the ATPS
> specs.
> 

On one level there already are ways for satisfying the 3rd party authorized domain issue. A domain could use SPF (either by specifying hosts/IPs or using an include in the SPF record) for a 3rd party domain. Another method would be to provide DKIM signing keys to the 3rd party. Yet a 3rd way is to delegate a subdomain so that the 3rd party can manage these things on their own. There are some best practice documents published at maawg.org that might be useful. If what you mean is a mechanism to specify random 3rd parties that an end user wishes to use, then no there is not a mechanism and I don't know of anyone who has put forth what I would consider a workable model.

> What is this so called "more accurate" method?

Not sure exactly what he means.

Mike

---

From: Hector Santos <[email-masked]>
Date: Tue, 15 Apr 2014 15:48:21 -0400

> Just curious, what sort of statement would you like to see? How would it help with vendor planning decisions?

I think the one provided here, although a link via tumblr, appears to 
be the official Yahoo position and sufficient:

http://yahoomail.tumblr.com/post/82426900353/yahoo-dmarc-policy-change-what-should-senders-do

> I'm looking forward to hearing your thoughts and questions and I'm sure others do as well. Is this list the best place for this or is there somewhere else more appropriate?

I don't think the IETF-LIST would be the appropriate place. I would 
think Dave and Murray would take lead here, as the current IETF "reps" 
on DMARC.

> Hector, Yahoo implemented the change a week ago Friday,
> not 4 months ago. I'm sure they have received complaints.

This is a January 10, 2014 transaction for one of the yahoo.com 
subscribers to our support list getting a copy of a yahoo.com user 
mail submission:

**************************************************************************
Wildcat! ESMTP Server v7.0.454.4
SMTP log started at Fri, 10 Jan 2014  22:06:21
Connection Time: 20140110 22:06:21  cid: 00000000 tid: 144C
SSL Enabled: YES
Message Queue: d:\spool\santronics\smtp\47446W
Destination: [email-masked]
Mail Host IP: 98.136.216.26:25 (mta6.am0.yahoodns.net)
Attempt #1 LastAttempt: n/a
22:06:21.471 ** Opening Connection to host: mta6.am0.yahoodns.net ip: 
98.136.216.26:25
22:06:21.668 S: 220 mta1089.mail.gq1.yahoo.com ESMTP ready
22:06:21.669 C: EHLO secure.winserver.com
22:06:21.770 S: 250-mta1089.mail.gq1.yahoo.com
22:06:21.770 S: 250-PIPELINING
22:06:21.770 S: 250-SIZE 41943040
22:06:21.770 S: 250-8BITMIME
22:06:21.770 S: 250 STARTTLS
22:06:21.770 C: MAIL FROM:<[email-masked]>
22:06:21.884 S: 250 sender <[email-masked]> ok
22:06:21.884 C: RCPT TO:<[email-masked]>
22:06:21.987 S: 250 recipient <[email-masked]> ok
22:06:21.987 C: DATA
22:06:22.087 S: 354 go ahead
22:06:23.179 S: 554 5.7.9 Message not accepted for policy reasons. 
See http://postmaster.yahoo.com/errors/postmaster-28.html
22:06:23.180 C: QUIT
22:06:23.180 ** Completed. Elapsed Time: 1700 msecs

Its repeated for the other three yahoo.com users during a submission 
and its recorded in the last four months of logs.  Only yesterday did 
a customer post a support message he was now seeing it his Wildcat! 
List Server setup and logs.  There might have been earlier reports but 
I didn't see them.

> On one level there already are ways for satisfying the 3rd party authorized domain issue. A domain could use SPF (either by specifying hosts/IPs or using an include in the SPF record) for a 3rd par…

I have to begin reading the DMARC spec to see what are all the 
boundary conditions, but it means basically able to answer mail 
operation policy questions such as:

   o  Does the domain ever distribute mail?
   o  Do you expect the mail to be unsigned?
   o  Do you expect to sign all mail?
   o  Is your domain the exclusive signer?
   o  Are 3rd party signers allowed?
   o  Are 3rd party signers allowed to strip your original signatures?

This is an illustration of the logical flow when SSP defined policies 
were used to answer the above questions.

   http://www.winserver.com/public/ssp/ssp.htm

> Not sure exactly what he means.

The 5322.From rewrite suggestion?

-- 
HLS

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 15 Apr 2014 20:10:17 +0000

> From: Hector Santos [mailto:[email-masked]]
> Sent: Tuesday, April 15, 2014 3:48 PM
> To: MH Michael Hammer (5304); IETF Discussion
> I think the one provided here, although a link via tumblr, appears to be the
> official Yahoo position and sufficient:
> 

It sounded like you were looking for something more.

> 
> > I'm looking forward to hearing your thoughts and questions and I'm sure
> others do as well. Is this list the best place for this or is there somewhere else
> more appropriate?
> >
> 
> I don't think the IETF-LIST would be the appropriate place. I would think Dave
> and Murray would take lead here, as the current IETF "reps"
> on DMARC.
> 

If it is DMARC related then IETF-DMARC or DMARC-DISCUSS would probably be the appropriate places. If it is specific to MLM related issues and how they might be addressed, I'm not sure and would defer to others as to the best place for discussions.

> > Hector, Yahoo implemented the change a week ago Friday, not 4 months
> > ago. I'm sure they have received complaints.
> 
> This is a January 10, 2014 transaction for one of the yahoo.com subscribers to
> our support list getting a copy of a yahoo.com user mail submission:
> 

Ah, you are talking about validating inbound email, not the outbound p=reject policy. Yahoo started validating over 2 years ago as did the other DMARC participating mailbox providers. I'm aware of other mailbox providers that are validating against DMARC but I'm not aware of a list of them that is available. 

> SMTP log started at Fri, 10 Jan 2014  22:06:21 Connection Time: 20140110
> 22:06:21  cid: 00000000 tid: 144C SSL Enabled: YES Message Queue:
> d:\spool\santronics\smtp\47446W
> Mail Host IP: 98.136.216.26:25 (mta6.am0.yahoodns.net) Attempt #1
> LastAttempt: n/a
> Its repeated for the other three yahoo.com users during a submission and its
> recorded in the last four months of logs.  Only yesterday did a customer post
> a support message he was now seeing it his Wildcat!
> List Server setup and logs.  There might have been earlier reports but I didn't
> see them.
> 
> > On one level there already are ways for satisfying the 3rd party authorized
> domain issue. A domain could use SPF (either by specifying hosts/IPs or using
> an include in the SPF record) for a 3rd party domain. Another method would
> be to provide DKIM signing keys to the 3rd party. Yet a 3rd way is to delegate
> a subdomain so that the 3rd party can manage these things on their own.
> There are some best practice documents published at maawg.org that might
> be useful. If what you mean is a mechanism to specify random 3rd parties
> that an end user wishes to use, then no there is not a mechanism and I don't
> know of anyone who has put forth what I would consider a workable model.
> >
> 
> I have to begin reading the DMARC spec to see what are all the boundary
> conditions, but it means basically able to answer mail operation policy
> questions such as:
> 
> This is an illustration of the logical flow when SSP defined policies were used
> to answer the above questions.
> 

Don't think SSP when you look at DMARC. There are only 3 basic settings for a sender publishing a DMARC record. I don't want to be accused of shilling for DMARC here so if you have questions it is probably better for you to go to one of the DMARC related lists or contact me offline.

> The 5322.From rewrite suggestion?

Possibly, I hate guessing on something like that.

Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Apr 2014 08:38:36 +1200

It serves to explain their obduracy but this really annoys me:

> There is a regrettable, short-term impact to our more aggressive position on DMARC. Many legitimate emails sent on behalf of Yahoo Mail customers from third parties are also being rejected. We apologize for any inconvenience this may have caused.

Why do they assert that it's a *short-term* impact? There's no clean fix, as
the discussion here has shown. And doesn't that "any" in "any inconvenience"
make you grind your teeth? We know that it's caused great inconvenience.

And this:

> We know there are about 30,000 affected email sending services, but we also know that the change needed to support our new DMARC policy is important and not terribly  difficult to implement. 

"not terribly  difficult to implement"? From what list admins are telling us,
that is simply untrue.

>  We have detailed the changes we are requiring here.

"requiring"?? Who are Yahoo to _require_ changes from 30000 third parties?

The mailman fix is worse than the disease. I think the .INVALID fix is
much better, because Reply-all will still work.

    Brian

---

From: Doug Royer <[email-masked]>
Date: Tue, 15 Apr 2014 14:53:00 -0600

Yahoo policy says you must have DKIM, SPF, or DMARC records. At what 
point could a large ISP start actually requiring these kinds of records 
for FREE email they accept and allow users to send?

Annoying, but it sounds reasonable to me for them to state a policy and 
enforce it.

If everyone had to wait until everyone upgraded, nothing would change.

-- 

Doug Royer - (K7DMR.us / DougRoyer.com)
[email-masked]
714-989-6135

---

From: Theodore Ts'o <[email-masked]>
Date: Tue, 15 Apr 2014 17:43:48 -0400

On Tue, Apr 15, 2014 at 02:53:00PM -0600, Doug Royer wrote:
> Yahoo policy says you must have DKIM, SPF, or DMARC records. At what point
> could a large ISP start actually requiring these kinds of records for FREE
> email they accept and allow users to send?
> 

The problem is with the alignment requirements of DMARC.  That can't
be easily fixed without breaking existing mailing list functionality.

Given that, it seems that the "From: [email-masked]"
rewrite solution for mailing list, is the best solution, since it puts
the pain on yahoo.com users and people who want to communicate with
yahoo.com users.  If Yahoo wants to unilaterially allocate pain to the
rest of the Internet, then it shouldn't be surprised if people choose
a technical solution which transfer some of the pain back to Yahoo.

	  	   	 	       - Ted

---

From: mohammed serrhini <[email-masked]>
Date: Wed, 16 Apr 2014 04:15:52 +0400

The problem is with the alignment requirements of DMARC.  That can't be easily fixed without breaking existing mailing list functionality.and  to give others  mail services had made the necessary changes.
Yahoo recognizes that  " Yahoo is the first major email provider in the world to adopt this  aggressive level of DMARC policy on behalf of theirs users. "
to protect users we do not need to be aggressive .

С уважением,
mohammed serrhini
[email-masked]

---

From: Doug Royer <[email-masked]>
Date: Tue, 15 Apr 2014 18:34:03 -0600

Yahoo does not seem to require DMARK. Simply use one of the other two 
options. I use SPF for my domains, and it makes it through their systems 
just fine.

It looks to me that some want to be able to send list email to many from 
a bogus email address (some-domain.invalid). Simply stop doing that. One 
of the responsibilities of being a list maintainer is cleaning up all of 
bounced mess from no longer valid email addresses. I have advocated in 
the past for a email header that allows a bounced message to be 
automatically routed for the correct reason back to the list maintainer 
for processing by automated processes. Maybe it is time to revisit that 
proposal.

I used to get thousands of spams from forged email. I get almost none 
now. If I got thousands, Yahoo must get millions. I applaud them for 
their courage to take a stand.

On 04/15/2014 06:15 PM, mohammed serrhini wrote:
>
> The problem is with the alignment requirements of DMARC. That can't be 
> easily fixed without breaking existing mailing list functionality.and  
> to give others mail services had made the necessary changes.
> Yahoo recognizes that  "Yahoo is the first major email provider in the 
> world to adopt this aggressivelevel of DMARC policy on behalf of 
> theirs users."

--

---

From: Theodore Ts'o <[email-masked]>
Date: Tue, 15 Apr 2014 21:22:05 -0400

> options. I use SPF for my domains, and it makes it through their systems

You seem to be confused about what the problem is.  It's not that
Yahoo is requiring DMARK.  The problem is that Yahoo is requesting
that *other* mailers reject mail if the From field is not aligned with
the Sender, and the From field is from yahoo.com.

This means that if a [email-masked] sends a message to a list which
includes [email-masked], and the mailing list server keeps the from
field as "[email-masked]", and sends the message to all of the mailing
list recipients, which includes [email-masked], the following things will happen:

a) hotmail.com will compare the sender address (authenticated with
   SPF) with the from address (authenticated by DKIM), see that they
   are different, and since yahoo.com has a DEMARK p=reject,
   hotmail.com will bounce the mail.

b) this means [email-masked] will never see [email-masked]'s mail

c) since the mailing list server receives a bounce from hotmail.com,
   if there are enough attempts from yahoo.com users to send mail to
   the mailing list, the number of bounces will cause the mailing list
   server to suspend or remove [email-masked] from the mailing
   list.

If we munge the from field from [email-masked] to
[email-masked], then hotmail.com will not bounce the mailing
list mail.  This means Alice will see Bob's message, and Alice will
not be in danger of getting suspended or dropped from the mailing list.

Alternatively, the mailing list server could determine the Bob is
sending his mail from a domain that has a DEMARK p=reject policy, and
simply bounce the mail back to Bob right away, instead of sending it
to the mailing list recipients.  That way, Bob's can get pursuaded to
use another mail provider, and Alice doesn't have to worry about
getting suspended from the mailing list.

Do you have another suggestion about what the mailing list server is
supposed to do?

						- Ted

---

From: Doug Royer <[email-masked]>
Date: Tue, 15 Apr 2014 19:44:25 -0600

On 04/15/2014 07:22 PM, Theodore Ts'o wrote:
> You seem to be confused about what the problem is.  ...

Yes, I did misunderstand. Now I wonder if the yahoo techs understood the 
effects.

> Do you have another suggestion about what the mailing list server is
Munge the from address to be the list-name@yahoo ? Odd, but would that work?

--

---

From: Douglas Otis <[email-masked]>
Date: Tue, 15 Apr 2014 18:45:45 -0700

On Apr 15, 2014, at 5:34 PM, Doug Royer <[email-masked]> wrote:

> Yahoo does not seem to require DMARK. Simply use one of the other two options. I use SPF for my domains, and it makes it through their systems just fine.

Dear Doug,

There's confusion about DMARC policy.  Policy is based on the domain in the From header field as indicated at _dmarc.<email-domain>.  If the From header contains "[email-masked]", then policy located at:

_dmarc.yahoo.com. IN TXT "v=DMARC1\; p=reject\; sp=none\; pct=100\; rua=mailto:[email-masked], mailto:[email-masked]\;"
means any validation not aligned with yahoo.com is to be rejected.

> It looks to me that some want to be able to send list email to many from a bogus email address (some-domain.invalid). Simply stop doing that.

No. Having emailing lists change ]From headers to "[email-masked]" sidesteps onerous _dmarc. policy (which prevents mailing-list use).

It seems 5 organizations outweigh 30,000 smaller groups.  There are scalable solutions such as ATP.  DMARC, on its own, requires all services to be under their domain.

> One of the responsibilities of being a list maintainer is cleaning up all of bounced mess from no longer valid email addresses. I have advocated in the past for a email header that allows a bounced message to be automatically routed for the correct reason back to the list maintainer for processing by automated processes. Maybe it is time to revisit that proposal.
> 
> I used to get thousands of spams from forged email. I get almost none now. If I got thousands, Yahoo must get millions. I applaud them for their courage to take a stand.

What you describe reflects most mailing lists that are generally better managed than the general corpus of messages directly from yahoo.com itself.  This is also why I wrote the ATP protocol.  ATP offers sending domains a means to select an ATP label hashes of domains they or the community considers well-managed third-party services.  Such exceptions will not invite abuse.

Regards,
Douglas Otis

---

From: Theodore Ts'o <[email-masked]>
Date: Tue, 15 Apr 2014 21:47:14 -0400

> Yes, I did misunderstand. Now I wonder if the yahoo techs understood the

Apparnetly, they believe that mailing list traffic is "insignificant".

So if only an insignificant number of yahoo.com users are encouraged
to switch to another mail provider, I'm asusming they won't mind....

	     	       	   	    	       - Ted

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Apr 2014 22:23:22 -0400

> server to suspend or remove [email-masked] from the mailing

So, as a WG chair, a person known to me just tried to post to the list
From a brand new yahoo.com mail account.  They aren't subscribed with that
address.  I would normally just approve, and add them...

It seems to me that I must now actually reject, because it would affect other
subscribers.

I'm now thinking that we need to remove all the @yahoo.com addresses from
posting to ietf mailing lists.

---

From: Theodore Ts'o <[email-masked]>
Date: Tue, 15 Apr 2014 22:38:13 -0400

> posting to ietf mailing lists.

So on my mailman configuration (which I believe is the default), if
[email-masked] receives 5 hard fail bounces she will get
automatically suspended from the mailing list.  So a single e-mail
from a @yahoo.com address won't cause damage, and if seven days go by
without any further bounce messages, the "bounce counter" gets reset
to zero.  The problem comes if you have many e-mail messages from
yahoo.com users (which according to yahoo and the DMARC cheerleaders,
shouldn't happen happen, because mailing list traffic is
"insignificant" :-).

So this is what I've done on my church mailman setup.  First of all,
I've disabled bounce processing, so even if a yahoo.com posting slips
by, it won't do any damage.  (It does mean more bounce mail will end
up going to the list-owner address, which I'll then have to manually
deal with, but as a short-term hack, I'm willing to live with it).
Secondly, I've taken all of the yahoo.com users, and set the
moderation bit, so if they do send e-mail, it will be held for
moderation.

I can then manually cut and paste their e-mail and send it to them on
their behalf.  Unfortunately, about 25% of my church's governing board
is using Yahoo, and so this is something I was willing to do as a
short-term remediation, since I didn't want to just bounce their
e-mail or let their e-mail cause other Vestry members to be removed
from the mailing list.

In the long-term, I'm going to try to convince some of them to move to
another mail provider, or at least use another mail provider for
church business.  I'll also try to see if I can get a patch to mailman
so it will do the "[email-masked]" -> "[email-masked]"
from header rewrite.  But that's not something I can do on short
notice, since this is a rather busy week for me.

I don't know what the ietf.org secretariat should do.  My short-term
remediations aren't very scalable, so what works for a small church
probably wouldn't work for the entire IETF.

What a mess.

							- Ted

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Wed, 16 Apr 2014 07:58:44 +0100

> much better, because Reply-all will still work.

Reply-all should still work with the Mailman fix; reply-to contains member (or member and list, for the reply-to-list case) and To/CC are included by MUA as usual.  It's "Reply" that's broken, and in the reply-to-list case: if the sender's address is discarded then the recipient can't use it, and if it's included then the sender has to manually manipulate the recipients in the composer window just to reply to the sender only after hitting Reply.

I really have little issue with the Mailman fix as it currently stands.  It's borked, but it works.  My lists are mostly of the chatty reply-to-list variety anyway.  The display name isn't touched; lots of users won't even notice …

Apparently Mailman 3 will do this properly, implementing support for DMARC by rejection and not tampering. http://j.mp/1m6N5Jt
Perhaps someone should point them to this discussion, or advise on the rewrite-to-invalid hack (which BTW has shortcomings of its own, especially for users of touchscreen devices …).

Cheers,
Sabahattin

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Apr 2014 11:13:16 +0100

On 04/16/2014 03:23 AM, Michael Richardson wrote:

> 
> So, as a WG chair, a person known to me just tried to post to the
> list From a brand new yahoo.com mail account.  They aren't
> subscribed with that address.  I would normally just approve, and
> add them...
> 
> It seems to me that I must now actually reject, because it would
> affect other subscribers.
> 
> I'm now thinking that we need to remove all the @yahoo.com
> addresses from posting to ietf mailing lists.
> 

This is probably obvious, but had gmail.com done what yahoo.com
has done, that could I guess have a pretty significant impact on
the IETF getting stuff done for a while since a lot of folks in
the last few years seem to have migrated their IETF mail to
gmail.com as a reasonable way to get around corporate this-and-that
issues.

Maybe people who've done that might want to consider whether its
such a good plan for so many IETF participants to be dependent on
just one service now that we have a demonstration that s/none/reject/
in one TXT RR can have such an impact.

S.

---

From: Hector Santos <[email-masked]>
Date: Wed, 16 Apr 2014 04:07:18 -0700 (PDT)

This is mostly a test with my junk yahoo.com testing account to see what happens here.   

Stephen, you are right, but we have been on this for over 9 years.  With all due respect to Crocker and Levine, who fought  hard against DKIM Security Policy based solutions starting with SSP, then ADSP which Levine authored as a poison pill many believe, he never supported his own work. The industry was quite aware of what was coming and it took DMARC, an external development, which Eric Allman predicted would happen when SSP was demoted by ADSP, to highlight the very high interest in the technology and tremendous need for an self-signing, low cost, email authentication protocol. DKIM was it and without a policy that Crocker and Levine tried to remove, the payoff was low and signatures were worthless.   So we have to give some credit to Yahoo for pushing the issue, finally.   Some will continue to fight it and  some will continue to work with it.   I choose to work with it now as I did with ADSP.

--
HLS via Yahoo
On Wednesday, April 16, 2014 6:13 AM, Stephen Farrell <[email-masked]> wrote:

S.

---

From: Randy Bush <[email-masked]>
Date: Wed, 16 Apr 2014 20:51:46 +0900

> in one TXT RR can have such an impact.

try smtp to goog over ipv6.  if you do not have an spf rr and good
reverse dns, high percentage of rejection.  the excuse is that ipv6
is mostly spam so they put up an aggressive barrier.

randy

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Apr 2014 15:46:59 +0300

> gmail.com as a reasonable way to get around corporate this-and-that

I’m one of those folks. It was mostly over spam filtering rejecting posts that it shouldn’t, especially messages from the lists that seemed to be coming from my email address. And rejected messages lead to unsubscribing. I got fed up with re-enabling my subscription every week or so. 

> in one TXT RR can have such an impact.

I considered this, so I first tried another provider (neither Yahoo! nor GMail). It turned out to be blocked from posting to @irtf.org mailing lists. I waited a week for this to sort itself out, but that didn’t happen. So I thought I’d complain/open a ticket/something. I searched their site and couldn’t find a support email address. The troubleshooting flowchart ended with a phone number. I spent 20 minutes on hold and then 10 more with the firstest or first-line support (“yes, I’m sure I have an account.  Yes, I’m logged in. Yes, I’m sure the other SMTP server is up”). He gave me the number for the second line of support. In the US. So I gave up, especially since their IMAP didn’t work with my client.

It looks like there’s a lot of providers out there, but there’s not that many who work correctly.  So I ended up with a GMail account like many others.

Yoav

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 16 Apr 2014 14:07:39 +0000

> From: ietf [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Wednesday, April 16, 2014 6:13 AM
> To: Michael Richardson; Theodore Ts'o
> Cc: [email-masked]
> Subject: Re: DMARC and yahoo
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> > From a brand new yahoo.com mail account.  They aren't subscribed with
> > that address.  I would normally just approve, and add them...
> >
> > I'm now thinking that we need to remove all the @yahoo.com addresses
> > from posting to ietf mailing lists.
> >
> 
> This is probably obvious, but had gmail.com done what yahoo.com has done,
> that could I guess have a pretty significant impact on the IETF getting stuff
> done for a while since a lot of folks in the last few years seem to have
> migrated their IETF mail to gmail.com as a reasonable way to get around
> corporate this-and-that issues.
> 

Instead of "But had gmail.com..." substitute "When gmail.com does..." Add a little loop to go down the list of various mailbox providers/ISPS/cable providers/telcos/etc and add the same statement. Be sure to add a counter that stops the loop after the top <pick your number>. Add an if else statement along the lines of "if too painful stop else keep on going". Susan Powter could be the spokesperson shouting "Stop the insanity". 

> Maybe people who've done that might want to consider whether its such a
> good plan for so many IETF participants to be dependent on just one service
> now that we have a demonstration that s/none/reject/ in one TXT RR can
> have such an impact.
> 

Consider the scenario presented above. My impression is that the agreed upon solution within this group is to remove individuals with mail accounts at domains publishing p=reject and tell them to go somewhere else. There appears to have been a rough consensus so that is what the group should do. Nowhere to hide. This makes me think of the SIG at the bottom of Miles Fidelman posts. 

I think a "guaranteed not to publish p=reject" logo should be offered up by IETF as a branding mechanism. In fact, I like this idea so much I am going to have a designer friend of mine create it. IETF prominently in the middle with "guaranteed not to publish p=reject" around the perimeter of the circular logo. Participating mailbox providers could display it prominently on their websites and in their marketing materials. Just to be clear for anyone wanting to jump in claiming trademark infringement, this falls under the heading of parody - unless of course Y'all want to take the proposal seriously in which case you can have the logo.

This approach will allow any potential list participants in the world the opportunity to know that they won't run into the p=reject problem with the providers displaying the logo. IETF could maintain a webpage listing such providers to help market the concept. This approach will also provide miscreants identification of which mailbox provider domains to abuse - kind of like homes that post gun free zone signs. And of course, it will provide other mailbox providers a heads up on which domains are potentially subject to increased abuse. Hmm... what would that scoring look like in SpamAssassin? MLMs that don't want to change will be protected and life will go on for some definition of go on.

Anther solution would be for IETF to provide IETF participants with accounts at ietf.org (or a subdomain or something) and webmail, POP/IMAP access, etc. Eating your own dog food, what? This is sounding more and more like walled gardens from days of yore. Hey Hector, does WildCat! BBS still support dialup? Would you donate a license to IETF to solve this problem? Back to the future. This would ensure that although IETF participants would be dependent on just one service, there would only be one throat to choke so to speak.

Who would have thunk that the IETF standards process could be so exhilarating.  En garde.

Mike

---

From: Theodore Ts'o <[email-masked]>
Date: Wed, 16 Apr 2014 11:50:55 -0400

On Wed, Apr 16, 2014 at 02:07:39PM +0000, MH Michael Hammer (5304) wrote:
> 
> 
> Instead of "But had gmail.com..." substitute "When gmail.com
> does..." 

You are asserting that gmail will eventually do what Yahoo has done.

I can't speak for my employer, but I suspect there will be a lot of
people (both inside and outside of the company) lobbying to make sure
gmail doesn't do the same insane thing that Yahoo has done.  I have
quite a bit of faith that senior folks like Vint Cerf will take a bit
more of a nuanced view than some of the DMARC cheerleaders have done,
and his voice does carry a fair amount of weight.

Cheers,

						- Ted

P.S.  One of the reasons why I think mailing list software should pick
mechanisms that inflict pain on yahoo.com customers, and hopefully get
them to switch, is that hopefully other e-mail providers will consider
the costs of using DMARC p=reject for domains where users might need
to send mail to mailing list, and choose differently from Yahoo.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 16 Apr 2014 17:03:19 +0000

> From: Theodore Ts'o [mailto:[email-masked]]
> Sent: Wednesday, April 16, 2014 11:51 AM
> To: MH Michael Hammer (5304)
> Cc: [email-masked]
> > Instead of "But had gmail.com..." substitute "When gmail.com does..."
> 

I am asserting that if, as an organization, Google (or any other mailbox provider for that matter) perceives that p=reject is working for other providers of a similar nature to mitigate abuse then yes, they will, even recognizing potential negative consequences in some areas as long as they believe that the benefits outweigh the consequences. It may be that no other mailbox provider chooses to make such a move.  I'm also saying that mailbox providers which validate DMARC have the data to see what the impacts are - both on abuse as well as broken mail through mailing lists and other sources. This is especially true for large providers that have the resources to do the analysis.

> I can't speak for my employer, but I suspect there will be a lot of people
> (both inside and outside of the company) lobbying to make sure gmail
> doesn't do the same insane thing that Yahoo has done.  I have quite a bit of
> faith that senior folks like Vint Cerf will take a bit more of a nuanced view
> than some of the DMARC cheerleaders have done, and his voice does carry a
> fair amount of weight.
> 

As I've said before, my ox isn't gored on the mailing list issue. Each mailbox provider will make a calculus as to which way to jump. This calculus will change over time for each mailbox provider depending on a number of factors and the perceived outcomes for the organization and its customers. Let's assume that Google chooses not to follow Yahoo but a number of other large providers do. You still have a similar outcome. I'm not presenting this as cheerleading for DMARC. I'm presenting this as a real situation and other mailbox providers, both large and small, may choose to go this direction. I haven't heard any of the denizens of this list present any approach as to how they will deal with such a sea change. 

As von Moltke the Elder wrote, "no plan of operations extends with any certainty beyond the first contact with the main hostile force".

Setting aside your personal preference as to outcomes, I'd love to hear your thoughts on how IETF and/or mailing list operators would deal with such a situation (some significant portion of mailbox providers/users migrated to this new paradigm) should it occur. 

> them to switch, is that hopefully other e-mail providers will consider the
> costs of using DMARC p=reject for domains where users might need to send
> mail to mailing list, and choose differently from Yahoo.

That is certainly a plan but it doesn't work so well if it becomes Yahoo+n. My wife and I have discussed this issue and our personal decision is that if our alma maters, charitable organizations that we contribute to, etc. undertake this tactic to intentionally inflict pain on us if our mailbox provider (neither of us happens to use Yahoo) should go this route, we will simply choose other places to give our support and donations. This is not a function of the DMARC debate itself but is instead a function of an organization biting the hand that feeds them to intentionally inflict pain to gain leverage over a 3rd party. For some organizations, while our donations are not critical, they are significant enough to get senior management attention if withheld with an explanation of why we have made that choice.

---

From: Jim Fenton <[email-masked]>
Date: Wed, 16 Apr 2014 12:01:10 -0700

>From the latest DMARC draft, section 8:

"If the RFC5322.From domain does not exist in the DNS, Mail Receivers
SHOULD direct the receiving SMTP server to reject the message."

So if a receiver that is implementing DMARC is faithful to the draft,
that won't work very well (nobody has gotten a TLD allocation for
.invalid, I hope?)

-Jim

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Apr 2014 08:36:58 +1200

On 16/04/2014 18:58, Sabahattin Gucukoglu wrote:
> Reply-all should still work with the Mailman fix; 

It doesn't work *properly*. Firstly, this message wouldn't be sent
to you with CC to the list, which is the correct semantic.
If you weren't a subscriber, you would never see it. Secondly,
the first line above would read:

 On 16/04/2014 18:58, IETF discussion list wrote:

which is untrue.

On 17/04/2014 07:01, Jim Fenton wrote:
...
> that won't work very well (nobody has gotten a TLD allocation for

DMARC isn't a standard, though, so standards-compliant mail receivers
shouldn't be implementing it. And that particular rule seems completely
out of place even if DMARC was a standard.

    Brian

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 16 Apr 2014 20:40:54 -0400

> I think a "guaranteed not to publish p=reject" logo should be offered up by IETF as a branding mechanism. In fact, I like this idea so much I am going to have a designer friend of mine create it. I…
Can't tell if you're serious or not - but I like it :-)

Kind of like "Best Viewed with Any Browser"

Cheers,

Miles

---

From: <[email-masked]>
Date: Thu, 17 Apr 2014 02:39:03 +0100

> I think a "guaranteed not to publish p=reject" logo should be offered up by IETF as a branding mechanism. 

... for expired internet-drafts.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Miles Fidelman [[email-masked]]
Sent: 17 April 2014 01:40
To: [email-masked]
Subject: Re: DMARC and yahoo

Cheers,

Miles

---

From: [email-masked]
Date: Wed, 16 Apr 2014 23:00:42 -0700 (PDT)

> require that it be interpreted in a particular way or that it contain any

I was trying to be brief. Yes, I'm well aware that DKIM can be used in other
ways. This entire discussion is within the context of DMARC here. Do you
disagree that DMARC's use of DKIM and SPF assign additional semantics to header
and envelope from fields respectively?

> went into the datatracker.

So?

> As it's only a draft, there's ample opportunity to make such improvements.

You're missing the point. When Yahoo made this change wouldn't it have been
nice to be able to point to the draft and say, "This is explicitly contrary
to what the draft says"?

> DMARC base draft?

The draft, of course.

> It seems extreme to lay blame on the IETF in general
> and discuss.  A "Request For Comment", as it were. 

You may think it extreme. I don't. I think the IETF's politics have led to  it
inching closer to moral hazard territory for a long time, and with this
incident it has stepped in it.

> Are you suggesting that

What I suggested is that we need to have a serious discussion of what, if
anything can be done to ameliorate the damage in this case. Others have
suggested that we also need to look at how to prevent this from happening
in the future. I concur.

> > existed in the earlier ADSP proposal. It was given insufficient attention
> > there as well.

> As with any draft, its content is only as good as its contributions and the

I hope you're not saying that this is now fault of the people who failed to
contribute to the draft.

> problem within its procedures, the IETF has abdicated any authority it may

That may be your assessment. Given subsequent comments from other people,  mine
is now that this effort was looking for a rubber stamp, didn't like it when
that didn't happen, and proceeded to skirt around the edges of the process.

With disasterous results.

				Ned

---

From: Douglas Otis <[email-masked]>
Date: Thu, 17 Apr 2014 00:08:08 -0700

> and envelope from fields respectively?

Dear Ned,

Murray is correct. DKIM does not create special From header field semantics.  However, DMARC semantics are similar to those of ADSP while avoiding some shortcomings.
 
> nice to be able to point to the draft and say, "This is explicitly contrary

Agreed.

> incident it has stepped in it.

This disruption should be shared with the provider that has already enumerated 30,000 mailing-lists but made no effort to establish a means to verify these sources and to safely assert specific exceptions to DMARC alignment requirements. This ability is desperately needed before applying DMARC reject on user accounts.  I'll be happy to modify either ATP or ATPS to permit these exceptions without the need to alter mailing-list. 

> I hope you're not saying that this is now fault of the people who failed to

These comments were made more than one year ago and ignored.

> With disasterous results.

Agreed. They seemed motivated into creating a system finely tuned for bulk senders while ignoring needs of individual users.  After all, bulk mailers contribute to their bottom line, but they may find users voting with their feet which may have the effect of reducing ad revenues due to fewer eyeballs.

Regards,
Douglas Otis

---

From: John C Klensin <[email-masked]>
Date: Thu, 17 Apr 2014 03:57:21 -0400

--On Wednesday, April 16, 2014 23:00 -0700
[email-masked] wrote:

>> merely for having an open mechanism by which to post a draft
>> for all to see and discuss.  A "Request For Comment", as it
>> were. 
> 
> You may think it extreme. I don't. I think the IETF's politics
> have led to  it inching closer to moral hazard territory for a
> long time, and with this incident it has stepped in it.

Indeed.  We have had warnings about where the ability of anyone
to post anything and then claim IETF approval in external
contexts without any fear of meaningful pushback would lead for
a long time.  It hasn't been significantly damaging before
because (i) we have been lucky and (ii) attempts to manipulate
the mechanisms have come from outsiders, not insiders.  With
DMARC, the ability to claim IETF responsibility when that is
handy and that the IETF has no control when _that_ is handy have
now been utilized by insiders.  That comes after a history of
the less effective approach of bringing specs into IETF WGs and
then claiming that fundamentals cannot be changed because they
were developed by experts in another forum.  As I think Ned
suggested, the ADSP issue and how it was handled should have
been another warning sign.  And, with Yahoo's move and its
consequences (whether they anticipated them or not), we also ran
out of luck.

> What I suggested is that we need to have a serious discussion
> of what, if anything can be done to ameliorate the damage in
> this case. Others have suggested that we also need to look at
> how to prevent this from happening in the future. I concur.

agreed.

>...
>> I would add to this that, by its ultimate inaction in the
>> face of a protracted period of abuse and attempts by
>> participants to solve that problem within its procedures, the
>> IETF has abdicated any authority it may have had.
> 
> That may be your assessment. Given subsequent comments from
> other people,  mine is now that this effort was looking for a
> rubber stamp, didn't like it when that didn't happen, and
> proceeded to skirt around the edges of the process.

> With disasterous results.

Exactly.

I'm also concerned that several of these efforts represent back
door approaches to deprecating multi-hop email.  Certainly many
things are more convenient in a single hop environment.  They
would become even more convenient if all email were to be
handled by a small oligarchy of providers.  To the degree to
which one simultaneously believes in openness and privacy, those
would be very sad outcomes.

    john

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Thu, 17 Apr 2014 11:03:41 +0100

> If you weren't a subscriber, you would never see it. Secondly,

Sorry, but I appear to be confused.

The Reply-To: field is adjusted to be the author's address, on a discussion list like this where replies go back to the authors.  Just in case we're talking across purposes somehow and to avoid all doubt, the fix we are talking about is described here:
http://www.dmarc.org/supplemental/mailman-project-mlm-dmarc-reqs.html

Unless your MUA is doing something very unusual, and some do, then pressing "Reply all" should produce a message addressed to me, with a CC that contains the remainder of the recipient addresses.  The From: is completely irrelevant.

I'm just waiting to be told that I've missed the obvious. :)

Now, FWIW, a better way is as has been suggested here, namely to synthesise addresses for each subscriber.  That's how I'd do it: every mailing list post has its From: rewritten, like:
ietf-resend+brian.e.carpenter=[email-masked]

That address remails to you, first checking that a subscriber of the list is recognised.  In the process, it performs the same transformation on the From: field of the message, so as to pass SPF alignment.  It is hoped that your interlocutor happens to be on the list, also, or that you are still on the list when he is trying to contact you.

> On 16/04/2014 18:58, IETF discussion list wrote:

It isn't necessary to change the personal name.  Some MUAs may very cleverly add one in the absence of one, or store it in an address book, though, incorrectly.  With the resend method above this issue is less problematic; furthermore the list software can add "(via listname)" to make the distinction less confusing.

No, none of these suggestions are perfect.  I'm not looking for a perfect solution though, I'm looking for one that works, for now.  Throwing people off my lists *is not* an option.

Cheers,
Sabahattin

---

From: [email-masked]
Date: Thu, 17 Apr 2014 07:41:25 -0700 (PDT)

> the mechanisms have come from outsiders, not insiders.

Nicely put. I completely agree.

> With DMARC, the ability to claim IETF responsibility when that is
> now been utilized by insiders.

Or by people with better access to insiders. It's hard to tell, and I'm not
sure it really matters.

> That comes after a history of

An onimous phrase, isn't it? But an accurate one, I fear.

> would be very sad outcomes.

It's not just multi-hop email - although I agree it's in danger - it's various
semantics of email that happen not be to be useful to commercial email of
various sorts, and whose presence makes the problem more challenging. John
Levine refers to all this as "send on behalf of", which isn't exactly right but
is probably close enough for purposes of this discussion.

I also find it particularly revealing that one of the arguments being made here
is along of the lines of, "Everything else has had to change, why are those
stodgy old mailing list thingies somehow exempt?" Except that's not it at all -
the approach was always essentially, "We're going to screw you, how about you
do X or Y to mitigate the damage a little?" To which the answer, predictably,
was less than enthusiastic.

				Ned

---

From: [email-masked]
Date: Thu, 17 Apr 2014 08:46:53 -0700 (PDT)

> Murray is correct. DKIM does not create special From header field semantics. 

Actually, by requiring that the signature cover the From: field, it sort
of does. But that's beside the point. Again, I was talking about DMARC's 
use of DKIM, not DKIM usage in general.

> However, DMARC semantics are similar to those of ADSP while avoiding some
> shortcomings.
 
But both of them attach additional semantics to From:. (Not that they had
a choice; as I pointed out previously, in order to acheieve the stated
goal they have to attach the check to the identity users actually see.)

> This disruption should be shared with the provider that has already
> enumerated 30,000 mailing-lists but made no effort to establish a means to
> verify these sources and to safely assert specific exceptions to DMARC
> alignment requirements. This ability is desperately needed before applying
> DMARC reject on user accounts.  I'll be happy to modify either ATP or ATPS to
> permit these exceptions without the need to alter mailing-list.

I'm by no means sure that ATP or ATPS is the right answer, but I certainly
agree that we need to at least try and address the situation that's been
created.

Sigh. We have a lot of work to do, don't we?

				Ned

---

From: Hector Santos <[email-masked]>
Date: Thu, 17 Apr 2014 14:28:25 -0400

Ned,

I don't see this as a big technical problem.  The engineering has been 
done. For the most part, not to over simplify, this was a battle 
between two camps:

    DKIM + POLICY (1st party author domain) framework
    DKIM + TRUST (3rd party signer domain) framework

DKIM is a trust model. It was unfortunate, by design, the Policy 
Semantics were pulled.  The trust advocates "won the war" by finally 
making ADSP historic to make room for DMARC where the focus was mostly 
about Reporting.  Even with ADSP, we were collecting information but 
it lacked the reporting part, unlike early versions of the policy 
proposals. But DMARC reporting was richer.

But this DMARC did have a similar handling logic it learned from SSP, 
DSAP and ADSP. It was odd but I presume the IETF believed DMARC 
p=reject will not be used as much as they strongly believed the 
equivalent ADSP dkim=discardable policy would never be used or 
honored, and if so, in a small insignificant way.

YAHOO changed that mindset and reality. Did they ever! In my book, as 
I always knew this lost of policy focus would have to be corrected 
some day.  Yahoo has forced the issue. Policy wins.

To me, both TRUST and POLICY are needed.

POLICY is just a first level filter of the most obvious domain 
practice faults. After policy passes the test, the trust layer comes 
in. After all, for DKIM trust query to be activated, the signature 
must exist and be valid per specification.

But just with using trust, Yahoo could of used the signer domain as 
the DKIM specs wanted it to do in the first place to lookup some 
"trusted" whitelist or 3rd party service to see if the signer domain 
is a "good guy."  It could of also accepted and quarantined the 
message allowing the user to white list the signer domain.  Yahoo 
online mail UI can offer the user a "DKIM whitelist" input field. 
Yahoo can keep this to itself or it can create public ATPS records, if 
it makes sense.

DKIM also has the Agent or User Id (AUID), the i= tag in 
DKIM-signature, that can be used as some MLM signing method.  I think 
we need to explore this again.

But ultimately, the author domain policies should be honored as the 
first layer check before trust can even come into play.  That mindset 
needs to be accepted.

The hard part is going to be getting the same folks to change their 
tune about how the Author Domain fits in with DKIM specification.  The 
DKIM abstract says:

    DKIM separates the question of the identity of
    the Signer of the message from the purported author
    of the message.

Impossible. I always wanted to know which "question" that was. 
5322.From is the sole single technical requirement to be hash bound to 
the signature.  There will always be an authorization relationship.

-- 
HLS

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Apr 2014 08:06:35 +1200

On 17/04/2014 22:03, Sabahattin Gucukoglu wrote:
> The Reply-To: field is adjusted to be the author's address, 

Oh, OK. Most UAs will probably do what you describe, but I think
there are exceptions. However, if I want to reply to the author
alone, it's now the simple Reply that will fail me, because it
will reply to the list. And in my mail folders, messages will
all appear to come from the list; if I want to find the message
that Sabahattin sent me two years ago, I can't, because my UA
doesn't allow for searching on the Reply-To field.

It's still got very poor semantics.

    Brian

> on a discussion list like this where replies go back to the authors.  Just in case we're talking across purposes somehow and to avoid all doubt, the fix we are talking about is described here:

---

From: Theodore Ts'o <[email-masked]>
Date: Thu, 17 Apr 2014 16:53:32 -0400

> It's still got very poor semantics.

It's all about semantics, isn't?

Suppose we made the mailing list software take the contents of the
>From field, and moved it to something like "X-Originally-From: ", and
changed the From field to be "[email-masked]".  That would be what the
DMARC people would want, right?

Except then, a couple of years later, because users might actually
want to find the message that was written by "Brian Carpenter", or
"Sabahattin Gucukoglu", and not from "[email-masked]", MUA's might
start using the Originally-From field in the summary field, and start
emphasizing the "Originally-From" from field in the UI.  At which
point, the spammer/scammer/whatever could start forging the the
"Originally-From" field, and then Lo!  There will be a DMARC II,
demanding that "Originally-From" field be aligned with the From field,
and we're right back to where we started.

It was the same argument about why a DKIM or DMARC couldn't just
verify the Sender field, and call it a day.  The problem is that the
>From field is what people pay attention to.

And this is true of whatever solution we want to better support
mailing lists.  Suppose the answer is to rewrite the from field to
something like this:

From: ietf-resend+brian.e.carpenter=[email-masked]

Or this:

From: [email-masked] (Originally from Brian E Carpenter: [email-masked])

It doesn't matter.  Eventually, the UA's will start emphasizing and
parsing out the original From field information, because that's what
people will want to be automatically added to their address book, and
not [email-masked], and that's what they will want to see in their
e-mail summary.  And then the DMARC folk will say, "Oh, Noes!
Spammers and scammers and bears, oh my!  They are using this loophole
to fool the naive user."  We must have DMARC II... and DMARC
III.... and DMARC IV.... and it will never end.

					- Ted

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 17 Apr 2014 17:09:23 -0400

> want to find the message that was written by "Brian Carpenter", or
<snip>

Worse than that.  That would any authentication back to the original author.

Personally, on my incoming mail, I really don't care if a message passed 
through a mailing list or not - if it says it's From: <foo>, what I 
really care about is that it really is from <foo> and that it's the 
message that <foo> originally sent (modulo things like subject tags, and 
list headers/footers) -- if some random mail list wants to forward the 
mail to me, and it comes through intact - do I really care about the 
legitimacy of the list server (other than not wanting it to become a 
spam or attack vector)?

Not sure that's completely clear.

Miles Fidelman

---

From: "John Levine" <[email-masked]>
Date: 18 Apr 2014 01:34:33 -0000

>SHOULD direct the receiving SMTP server to reject the message."

As far as I can tell, that bit of poor advice hasn't been implemented.

>that won't work very well (nobody has gotten a TLD allocation for

See RFC 2606.

R's,
John

PS: I did a few experiments, and putting two addresses on the From:
line works remarkably well to avoid inappropriate policy failures,
e.g.

 From: Marissa <[email-masked]>, [email-masked]
 Subject: whatever
 ...

---

From: Doug Barton <[email-masked]>
Date: Thu, 17 Apr 2014 21:28:43 -0700

On 04/17/2014 07:41 AM, [email-masked] wrote:
> I also find it particularly revealing that one of the arguments being
> made here is along of the lines of, "Everything else has had to
> change, why are those stodgy old mailing list thingies somehow
> exempt?" Except that's not it at all - the approach was always
> essentially, "We're going to screw you, how about you do X or Y to
> mitigate the damage a little?" To which the answer, predictably, was
> less than enthusiastic.

Another way to look at this is that the IETF, which ostensibly is 
interested in "input from operators," received pretty clear "input" from 
the operators of the largest mail systems on the planet, and 
collectively stuck their fingers in their ears and sang "la la la la la, 
I can't hear you" because it didn't like what was being said.

The message was pretty clearly, "We think DMARC is valuable enough to us 
that we plan to deploy it even though it has the unfortunate side effect 
of causing problems for mailing lists." Rather than throwing up our 
hands and telling the DMARC folks that we refuse to work with them 
unless their solution solves the problem of our anachronistic use case 
that that constitutes only a tiny percentage of their overall traffic; a 
more rational approach would have been to recognize that the tail is not 
going to wag the dog here and start working with mailing list authors to 
solve the problem of how to live in a world that includes DMARC.

When people talk about how the IETF is out of touch with the operator 
community and increasingly irrelevant, this is exactly the kind of thing 
that they are talking about. We ignore this lesson at our peril.

Doug

---

From: [email-masked]
Date: Fri, 18 Apr 2014 07:47:22 -0700 (PDT)

> I can't hear you" because it didn't like what was being said.

... except that would be wildly incorrect. In particular, the "operator
community" consists of a lot more than just the proponents of DMARC. Many of
those other operators - including some of comparable size - are now struggling
to deal with the consequences of DMARC.

> of causing problems for mailing lists."

Allow me to rephrase: "We think getting our commerical mail through is worth
sacrificing all sorts of personal mail functionality users depend on. And we
don't care who it hurts, including some shops as large or larger than we are."

> Rather than throwing up our
> that that constitutes only a tiny percentage of their overall traffic;

Again with the traffic size as justification for poor behavior. Not all
messages are created equal, and some functions have utility entirely
disproportionate to the amount of bandwidth they use.

> a more rational approach would have been to recognize that the tail is not

And suppose that would have required some tweaks to DMARC and maybe even
DKIM to accomplish. What part of "no changes" is hard to understand?

> that they are talking about. We ignore this lesson at our peril.

Well, here we sort of agree. The IETF is indeed out of touch with the operator
community. But not because it fails to talk to the DMARC proponents - which it
actually does do - but rather because it fails to talk to lots of other
operators.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Apr 2014 08:41:06 -0700

> don't care who it hurts, including some shops as large or larger than we

I'm not so sure delivery is the primary goal.  Rather, "We're tired of the
fact that we are unable to control who generates mail that appear to come
from our domain(s), and it's hurting us" is how that should at least
start.  A tarnished domain name has repercussions beyond just delivery of
email.

-MSK

---

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

> As far as I can tell, that bit of poor advice hasn't been implemented.

Why is that poor advice?  It's not uncommon for an MTA receiving mail to
confirm that the message is replyable, at least insofar as an A and MX are
available for whatever comes after the "@".

-MSK

>  From: Marissa <[email-masked]>, [email-masked]
Huh, interesting.  Likely accidental, alas.

-MSK

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 18 Apr 2014 11:51:46 -0400

Murray S. Kucherawy wrote:
> On Fri, Apr 18, 2014 at 7:47 AM, <[email-masked] 
> I'm not so sure delivery is the primary goal.  Rather, "We're tired of 
> the fact that we are unable to control who generates mail that appear 
> to come from our domain(s), and it's hurting us" is how that should at 
> least start.  A tarnished domain name has repercussions beyond just 
> delivery of email.
>

Given the amount of spam and other malicious mail that comes from real, 
honest-to-god, Yahoo accounts -- be it generated by spammers who obtain 
Yahoo accounts, or botnets that have obtained access to legitimate 
accounts -- perhaps Yahoo might have started closer to home in 
addressing the "tarnished brand" problem.

Pretty much the ONLY malicious mail, from Yahoo, that has ever made it 
through our spam filters, and onto any of our mailing lists, has been 
from compromised Yahoo accounts -- and that was BEFORE DMARC.

On the other hand, the only mail that ever seems to end up in my Yahoo 
mailbox (which I rarely check), is spam.

What Yahoo has just done is tarnished their brand by "breaking every 
email list in the world" - and causing pain to every one of their users 
who subscribes to mailing lists.

Kind of shooting yourself in the foot, if you ask me.  (Or blowing up 
yourself, along with your target.)

Miles Fidelman

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Fri, 18 Apr 2014 17:12:22 +0100

> It's still got very poor semantics.

Precisely right, and especially +1 to the concluding paragraph.

Is now the time to discuss making it policy for mail receivers to supply user-modifiable signer-domain bypasses?  Or is "Whitelisting" still considered a dirty word and "Not scalable"? :)

Cheers,
Sabahattin

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Fri, 18 Apr 2014 19:33:39 +0100

> DMARC people would want, right?

Probably.  I mean, the alternative is to upgrade DMARC so it recognises the Originally-From field as From when it is present, but that would actually require maintaining compatibility with decades-old software which didn't know that From was the arbiter of all truth. :)

> From field is what people pay attention to.

Precisely.

Of course, if we're starting just now, there's something we could try differently: write it into Internet law that "NO MUA SHALL PROMOTE FOO TO THE DEFAULT HEADER DISPLAY", where "foo" is whatever we come up with.  Then MUA software, when presented with a known-good and known-aligned authentication results for From: could start displaying the green bar or whatever nonsense they come up with to signal that all is good, just so long as the part to the right of the @ is the domain the user thought the mail was really from.  However the MUA could continue to provide conveniences such as address autocomplete, address book memorisation, search or reply that were all using our new foo.

> III.... and DMARC IV.... and it will never end.

Indeed.  Of course, none of that helps the mailing lists of yesteryear, I mean today.  Right now, we're all screwed without one of these hacks. :(

Cheers,
Sabahattin

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 18 Apr 2014 20:10:34 +0000

From: ietf [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Friday, April 18, 2014 11:41 AM
To: [email-masked]
Cc: ietf
Subject: Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists

On Fri, Apr 18, 2014 at 7:47 AM, <[email-masked]<mailto:[email-masked]>> wrote:

I'm not so sure delivery is the primary goal.  Rather, "We're tired of the fact that we are unable to control who generates mail that appear to come from our domain(s), and it's hurting us" is how that should at least start.  A tarnished domain name has repercussions beyond just delivery of email.
MH: I’m going to disagree with Murray on the fact that it’s hurting us, the company as the motivator, at least from my perspective. I see it as preventing end users from getting hurt from this particular use case (direct domain abuse). The further we (for some definition of we) can push bad actors from reality (from the users perspective), the less likely they are to fall for certain types of social engineering. I would hypothesize that increased abuse of the type Yahoo has been seeing may be in part due to increased difficulty on the part of malicious individuals in abusing brands implementing DMARC with p=reject. P to P mail becomes increasingly attractive and the use of stolen address books or user email addresses and information from stored messages can be used to improve the effectiveness of the social engineer.

Mike

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 18 Apr 2014 17:12:18 -0400

MH Michael Hammer (5304) wrote:
>
> MH: I’m going to disagree with Murray on the fact that it’s hurting 
> us, the company as the motivator, at least from my perspective. I see 
> it as preventing end users from getting hurt from this particular use 
> case (direct domain abuse). The further we (for some definition of we) 
> can push bad actors from reality (from the users perspective), the 
> less likely they are to fall for certain types of social engineering. 
> I would hypothesize that increased abuse of the type Yahoo has been 
> seeing may be in part due to increased difficulty on the part of 
> malicious individuals in abusing brands implementing DMARC with 
> p=reject. P to P mail becomes increasingly attractive and the use of 
> stolen address books or user email addresses and information from 
> stored messages can be used to improve the effectiveness of the social 
> engineer.
>

At least from the perspective of our lists, and spam traps - abuse of 
stolen address  books and such has been a much larger problem than email 
from forged addresses -- at least where Yahoo is concerned, our normal 
spam traps (spamassassin with lots of checks) caught (and continue to 
catch) most incoming spam -- EXCEPT for the stuff that comes form 
legitimate addresses.

I.e., botnets that have access to address books and legitimate login 
credentials have been the main problem we've seen.  At least so far, 
p=reject hasn't led to an increase in that.

Miles Fidelman

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 18 Apr 2014 21:19:13 +0000

> From: ietf [mailto:[email-masked]] On Behalf Of Miles Fidelman
> Sent: Friday, April 18, 2014 5:12 PM
> Cc: ietf

The assertion has been made that the mail abusing the stolen address books was being sent from places other than yahoo.com but claiming to be from [email-masked]. In this scenario p=reject would have an impact in mitigating that type of abuse for mailbox providers validating DMARC (notwithstanding the damage done to mailing lists and other 3rd parties).

Mike

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 18 Apr 2014 17:29:57 -0400

> The assertion has been made that the mail abusing the stolen address books was being sent from places other than yahoo.com but claiming to be from [email-masked]. In this scenario p=reject would ha…

All I can report is what I see in our logs, and after-the-fact analysis 
of mail that has actually made onto the lists we run.

Miles

---

From: Doug Barton <[email-masked]>
Date: Fri, 18 Apr 2014 15:35:09 -0700

On 04/18/2014 07:47 AM, Ned Freed wrote:
 >> I said:

Right, so the input here from the operators is, "Mailing list traffic is 
not important enough to us to prevent us from deploying an anti-spam 
solution that solves the vast majority of our problems with little cost 
or difficulty. The MLM software authors will have to deal with this 
problem on their end." And your response is to stamp your feet and 
shout, "But my mailing list traffic IS important! It is, IT IS!!!!!"

I'm glad that you feel that way, we should all have things that we're 
proud of after all. But in terms of actually listening to and acting on 
the input we've received from the operator community about this topic, 
the IETF has failed. The fact that people like you don't recognize this 
as a failure is a clear sign that our slippery slope into irrlevance is 
well greased.

Doug

---

From: Theodore Ts'o <[email-masked]>
Date: Fri, 18 Apr 2014 19:03:24 -0400

On Fri, Apr 18, 2014 at 03:35:09PM -0700, Doug Barton wrote:
> 
> Right, so the input here from the operators is, "Mailing list traffic is not
> important enough to us to prevent us from deploying an anti-spam solution
> that solves the vast majority of our problems with little cost or
> difficulty. The MLM software authors will have to deal with this problem on
> their end." 

... and then the operators should not be surprised if the people
modifying the MLM software do something which is best for them, and
which not necessarily best for the interest of the users of certain
operators.

Which is the default when neither side is willing compromise, and
everyone is reduced to taking unilateral action.

If you want to call that a failure of the standards process, I can
only agree.  I suspect the only difference is how the blame for the
failure gets allocated.  But at the end of the day, it is what it is.
Some people will use one kind of messaging, and say it's all the
mailing list people's fault, and some other people will use a
different messaging, and say it's all Yahoo's fault.

And the users will be stuck in the middle....  and presumably they as
their own indpendent actors, will do what is in their best interest.

Cheers,

					- Ted

---

From: Randy Bush <[email-masked]>
Date: Sat, 19 Apr 2014 08:24:29 +0900

> only agree.

it is a failure of the internet and internet operations.  the failure
of the standards process just enables an excuse.

randy

---

From: [email-masked]
Date: Fri, 18 Apr 2014 17:33:08 -0700 (PDT)

> shout, "But my mailing list traffic IS important! It is, IT IS!!!!!"

I really have to wonder where you got enough straw to build a strawman of this
size. If you actually, you know, read what I've been saying, it has been that
this was handled extremely poorly by the IETF. Just not in the way you happen
to believe.

Your view of what happened, who the operators actually are and what their
positions are, and what the likely consequences are going to be are somewhere
between a gross oversimplifications and looney tunes. But I must say they are
amusing.

> the IETF has failed.

Wrong again. The evidence shows clearly that the IETF did listen, to this group
at least. Where the IETF failed was in not looking at the big picture and
likely consequences, which I'm afraid is not laid out along the axis of "big
operators all supporting DMARC" versus "tiny insignificant list maintainer
stick-in-the-muds".

Oh, and not that it matters, but I personally have only been tangentially
involved in most of this. This is because a lot of it happened when I wasn't
unable to participate. Kidney transplants and heavy standards involvement don't
mix very well.

> The fact that people like you don't recognize this

I've been saying from the start that this was a failure on the IETF's part.

It's just not the kind of failure you think it was.

				Ned

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 18 Apr 2014 21:09:16 -0400

> unable to participate. Kidney transplants and heavy standards 

Wow... hope all is well now.  (History of kidney issues in our family - 
never has led to a transplant.  I feel for you.)
> It's just not the kind of failure you think it was.

Any suggestions on how we might approach making changes?  I guess 
overall architecture, process, and policy are IAB's purview - but how 
does one get folks to pay attention - I haven't seen any IAB members 
commenting here, for example. (Note: My own IETF involvement has always 
been one step removed - mostly in my days at BBN, where I sat next to a 
lot of active IETF participants, but spent more of my time on system 
design and application of protocols.  My direct standards involvement 
has always seemed to end up in other forums - mostly military and 
security stuff that ran under funny venues. These days, I'm more on the 
tail end of being effected by such things as this current debacle - 
which are kind of motivating me to get more seriously involved.)

Miles Fidelman

---

From: [email-masked]
Date: Sat, 19 Apr 2014 08:17:44 -0700 (PDT)

> which are kind of motivating me to get more seriously involved.)

I've been thinking about it, and I think this needs to be addressed on at least
two different fronts. First, I've come to believe that the IETF needs to say
something, in  some capacity, about the political aspects of the DMARC
situation specifically.

I also think the time has come to try and address the more general problem
of misunderstanding and/or misrepresentation of the status of various
documents. This probably needs to be addressed through a combination of
automatic labeling as well as some explicit statements here and there.

And this really needs to be spearheaded by the IESG, not the IAB. I hope the
IESG is already considering taking action. If not, they should be.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Sat, 19 Apr 2014 12:00:23 -0400

--On Saturday, April 19, 2014 08:17 -0700
[email-masked] wrote:

> something, in  some capacity, about the political aspects of
> the DMARC situation specifically.
> 

Ned,

I agree, but I also think there is another element of the
situation that got us here, and that has led us close to other
problems in the past.  When the RFC Editor is asked to publish a
non-WG document (i.e., either an individual submission through
the IETF stream or as an independent submission) that could be
construed as some sort of standard (whether actually standards
track or not) or approval of an IANA parameter registration is
on the basis of expert review, there as a potential for the
appearance of conflicts of interest.   Those conflicts need not
be of the traditional legal or financial variety.  They can
occur (or be perceived to occur) when someone's institutional or
organizational relationships outside the IETF might lead people
to suspect that review and decision-making might not be as
careful, unbiased, or primarily reflective of the interest of
the IETF or the broader Internet community as we would like it
to assume it always is.  For situations where troublesome
relationships exist or might be inferred (even by those
suffering from mild paranoid), we need to get much more careful
about disclosure of the relationships involved.

> And this really needs to be spearheaded by the IESG, not the
> IAB. I hope the IESG is already considering taking action. 
> If not, they should be.

Indeed.

    john

---

From: [email-masked]
Date: Sat, 19 Apr 2014 08:31:52 -0700 (PDT)

> available for whatever comes after the "@".

It's outrageously poor advice, for the simple reason that there's all kinds of
legitimate email that's sent for all kinds of different reasons that you don't
want people to be able to reply to. And the sooner they get a failure when they
try and reply, the better.

As such, the ability to reply to the RFC5322.From tells you almost nothing
about its legitimacy.

It's yet another case where a failure to consider the multiple semamtics
field like RFC5322.From has, and designing to a subset of those designs,
ends up screwing things up.

				Ned

---

From: [email-masked]
Date: Sat, 19 Apr 2014 10:08:31 -0700 (PDT)

> about disclosure of the relationships involved.

Good point, and I agree.

These waters are going to be difficult to nagivate, but I don't see any
alternative.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Sat, 19 Apr 2014 15:17:18 -0400

> These waters are going to be difficult to nagivate, but I don't see any

Maybe I should of followed with my gut instinct and followed through 
with my appeal a few years back when this whole situation we have 
today was the crux of the main philosophical debates of TRUST vs 
POLICY DKIM framework and a deemphasis of policy and lost of a 
standard track WG ADSP policy proposal was going down the drain with 
conflictive trust interest dominating the direction of DKIM.

But with seeing the WG chairs and ADs interest also being in conflict 
as well, including one AD recusing himself from my initial appeal 
interest AD/chairs contact, I knew it was time to give up. In a chat 
with Eric, who lead the early DKIM policy framework work, when 
Levine's poison pill ADSP hijacked the policy work, he said it was 
over as far as an IETF standard work item. It will have to be 
revisited from outside the IETF with some trade group.  DMARC is a result.

In that vain, I am partially the blame for backing off. How much 
talking can you do? At this point, now I am being excommunicated. It 
wasn't fun.  Its not like the chairs and the Ads were not aware of the 
concerns. But I guess I didn't have enough influence. I didn't attend 
meetings. I didn't have get to know the folks or them me.

But I knew this was going to be a major problem when the IETF was now 
abandoning ADSP for the same reasons you are seeing now with DMARC. 
Essentially both lacked 3rd party semantics.  So its somewhat surreal 
that DMARC would be now marketed by the IETF when the same ADSP 
problem did not get addressed. It can't be made any more simpler than 
that.

Overall, the technical issues were obvious. But there was two basic 
attitudes that was hard to overcome and I think still needs to be 
overcome:

   1) A mindset that REJECTION is bad.  Accept all mail and let users 
decide was
      the prevailing mindset.  It was a SYSTEM wide vs USER filtering 
design
      issue. As a developer, it means BOTH options would be available 
for the
      operators to work with.   But overall, the ideas of 
deterministic system
      wide rejection was too little too much for many of the IETF mail 
vets.

   2) The 3rd party Trust/Reputation Market potential was too great to 
allow
      self-signing policy based system marginalized this trust market 
potential.
      New ventures had started by the leads of the DKIM project. 
Again, brought
      up but what were you going to do.  For me, lead the way, trust 
and policy
      do co-exist and we would be better for it, if others vendors 
refused to
      see that. But no, POLICY had to go!  there was no compromising 
whatsoever.

Anyway, I'm somewhat tired of it.  Much development time was put into 
DKIM, ADSP, ATPS over the 9+.  If the attitudes don't change now that 
DMARC is here, well, I don't see any hope with this issue unless fresh 
new synergism and policy support advocates folks get involved. We got 
the usual typical relatively few people that appear to be considered 
the main leads with these IETF mail related projects and that has to 
improve or in this case, finally change a few key folks position on 
DKIM + POLICY and help lead the way with 3rd party policy support that 
is workable, acceptable for all.

If DMARC is the going to be the "method," the "language" then it can 
be fine tuned with IETF based extensions that the silly DMARC.ORG 
folks, whoever they are, can not stop from happening in the same way 
we somewhat tried to keep ADSP alive with the ATPS extension.

If thats a problem, then how about this>

      I proposed ADSP to be remove from Historic status, and 
reestablished
      as a Proposed Standard.

Why does this make sense?  Well, there are systems that support ADSP, 
there is APIs, there is running code, and its still too early with 
DMARC to completely eliminate ADSP.  Since its not perfect, a 
competing ADSP may actually get the DMARC.ORG to be more agreeable 
with IETF related concerns.

-- 
HLS

---

From: John C Klensin <[email-masked]>
Date: Sat, 19 Apr 2014 16:16:04 -0400

--On Saturday, 19 April, 2014 10:08 -0700
[email-masked] wrote:

>...
>> there as a potential for the appearance of conflicts of
>> interest.   Those conflicts need not be of the traditional
>> legal or financial variety.  They can occur (or be perceived
>> to occur) when someone's institutional or organizational
>> relationships outside the IETF might lead people to suspect
>> that review and decision-making might not be as careful,
>> unbiased, or primarily reflective of the interest of the IETF
>> or the broader Internet community as we would like it to
>> assume it always is.  For situations where troublesome
>> suffering from mild paranoid), we need to get much more
>> careful about disclosure of the relationships involved.
> 
> Good point, and I agree.
> 
> These waters are going to be difficult to nagivate, but I
> don't see any alternative.

Yes.  However, I see some parallel to the IPR situation.  We
could presumably treat members of the community like adults (I
think almost all are) and say "if you have an outside-the-IETF
relationship to the developers, or developing organization, of a
spec, you must at least disclose it", it would go a long way
and, IMO, not be particularly difficult.   Unlike the IPR
situation, this one is unlikely to require involving lawyers in
what one could or could not say/ disclose.   The waters get
difficult only if we feel a need to take the next steps toward
forced recusal or worse.  Maybe, if we just demanded disclosure
as an expected professional courtesy and act of honesty toward
the rest of the community and understood that either an
undisclosed conflict or a disclosed one that seemed to distort a
decision could be reasonable grounds for appeals, we could get
away without a requirement for a lot of hair-splitting rules.

    john

---

From: Pete Resnick <[email-masked]>
Date: Sun, 20 Apr 2014 09:57:12 -0500

> IESG is already considering taking action. If not, they should be.

The timing has been impeccable. The IESG had been privately talking 
about the "IETF relevance" issue, including why people are bringing 
"done" work to the IETF instead of working inside of the IETF. And 
related to "done" work, we have also been discussing the relative merits 
of AD-sponsored documents vs. ISE documents and what the appropriate use 
of IESG and IETF time is for these things. We've had all of that on our 
agenda for our upcoming retreat in a couple of weeks, and planned to 
discuss it with the IAB during a joint meeting. Then this DMARC thing 
happens, and Vidya published her article on "why I quit writing internet 
standards". It could not have been timed better.

I'm trying to get my head around what we should have done differently on 
this, both tactically and strategically, so that I can summarize it for 
the discussion. But I can say pretty confidently that this is a topic 
frontmost in the minds of IESG folks.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Jeffrey Altman <[email-masked]>
Date: Sun, 20 Apr 2014 12:52:59 -0400

Jeffrey Altman

> On Apr 15, 2014, at 10:38 PM, Theodore Ts'o <[email-masked]> wrote:
> 

I took a different approach.  I left the bounce detection on but switched all @yahoo.com accounts to digest mode.  Since the mail now comes from the list instead of the @yahoo.com sender there are no rejections.   Not a perfect solution but it prevents harm to [email-masked] list participants.

Jeffrey Altman

---

From: "John Levine" <[email-masked]>
Date: 20 Apr 2014 17:18:52 -0000

>I took a different approach.  I left the bounce detection on but switched all @yahoo.com accounts to digest mode. 
>Since the mail now comes from the list instead of the @yahoo.com sender there are no rejections.   Not a perfect
>solution but it prevents harm to [email-masked] list participants.

I don't see how that helps.  The problems occur when a list message
with "From: [email-masked]" is delivered to a Gmail or Hotmail or
Comcast address which follows the DMARC advice and bounces the
message.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sun, 20 Apr 2014 13:23:10 -0400

> I took a different approach.  I left the bounce detection on but switched all @yahoo.com accounts to digest mode.  Since the mail now comes from the list instead of the @yahoo.com sender there are…

Thats a good tip (Digest Mode) to pass on to our list operators.  Thanks.

However, what you going to do with when other domains begin to flip on 
the strict DMARC policy switch.  There will be more domains doing this 
now that Yahoo is showing the payoff is high in increasing the 
security quality of their domain.

Keep in mind that this is just about dealing with the legacy existing 
user accounts. You SHOULD still honor the policy for at least new 
subscribers from yahoo.com accounts.  You SHOULD also honor the policy 
for new submissions. But you believe you MAY ignore it and do some 
things to get around the domain's security policy.

The key is how to do all this in an automated protocol fashion, and it 
should begin with first honoring and correcting the DMARC draft 
specification for 3rd party resigner operations which it lacks.

-- 
HLS

---

From: John C Klensin <[email-masked]>
Date: Sun, 20 Apr 2014 13:26:38 -0400

--On Sunday, 20 April, 2014 12:52 -0400 Jeffrey Altman
<[email-masked]> wrote:

>...
> I took a different approach.  I left the bounce detection on
> but switched all @yahoo.com accounts to digest mode.  Since
> the mail now comes from the list instead of the @yahoo.com
> sender there are no rejections.   Not a perfect solution but
> it prevents harm to [email-masked] list participants.

IMO, this is quite elegant.  The Yahoo users continue to get the
messages, you don't get cluttered by rejection-related
complaints, and those Yahoo users who don't like the digest form
can take it up with Yahoo or find other accounts to use.

   john

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Apr 2014 08:26:56 +1200

> can take it up with Yahoo or find other accounts to use.

Unfortunately they can switch themselves back to normal mode
too. Digest mode is user-settable, and is very annoying because
it munges the Subject header. What's really needed is a DMARC-safe
mode (per subscriber) that optionally rewrites the From.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Apr 2014 08:37:33 +1200

On 21/04/2014 02:57, Pete Resnick wrote:
> "done" work to the IETF instead of working inside of the IETF. 

Allow me to repeat something I said a few days ago that probably
got lost in the heat and dust of the "why I quit..." discussion:

We have at least 3 modes of working, each of which has its value:

1. Preemptive standardisation: problem statement first,
then requirements, then design, then standardise, then sit
back and wait for implementation.

2. Parallel standardisation: there's some design work and
maybe some code, then retro-fit requirements, write the specs
as the code evolves, then standardise and hope that the code is
updated to match the spec.

3. Retroactive standardisation: there's some running code that
got itself deployed; write the v1 spec to be compatible with
the code, call it a standard, then develop v1.1 or v2 and
hope the code is updated.

We've done all three, and all with varying degrees of success.
I could give examples, but that would just start arguments ;-).
It isn't reasonable to expect all standards to fit the same
model. And people who don't have the desire to work in any
of these models may well prefer to quit standards work (but
still contribute code to one of the three models).

    Brian

And

---

From: Dave Crocker <[email-masked]>
Date: Sun, 20 Apr 2014 13:41:43 -0700

reference quibble...

> and envelope from fields respectively?

Not really.  In fact, I fear that that's a bit like saying that TCP 
makes IP a reliable, byte-sequenced protocol...

Rather, DMARC defines its /own, additional/ meaning, but it does not 
change DKIM or SPF.  They do what they've been doing for quite awhile. 
DMARC does something /more/.

Essentially, DMARC takes the domain name used in DKIM d= and/or SPF 
"protected" rfc2321.MailFrom and invents a new requirement, namely that 
that domain name be the one used in the author's rfc2822.From field's 
addr-spec's <domain>.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 20 Apr 2014 13:52:51 -0700

> now been utilized by insiders.

We are constantly confusing someone's attempted effect with their actual 
effect.

We need to stop giving other people control over the IETF that way.

Merely by making a claim, the get us to we scurry into fearful action, 
believing we have to prevent such claims.  We are allowing them to 
conduct a denial of service attack on us.  Or rather, by us on ourselves.

> consequences (whether they anticipated them or not), we also ran

With some regularity, over the decades, a large vendor or provider has 
applied a standard -- or modified it -- in a way other than it was 
designed to cover.

>> how to prevent this from happening in the future. I concur.

The IETF has no leverage for preventing the independent and 
consequential actions of a large player in the market.

> door approaches to deprecating multi-hop email.

Well, that's a substantive point.  And unfortunately I agree with the 
concern.  In fact, it has been impressive to see how readily some 
industry folk dismiss concerns about more complex uses of email, such as 
multi-administration handling of mail in transit.

One /can/ imagine the IETF producing a BCP about the consequences of 
applying it's technologies in various ways that change email's utility.

d/

---

From: Doug Barton <[email-masked]>
Date: Sun, 20 Apr 2014 14:23:38 -0700

> can take it up with Yahoo or find other accounts to use.

The issue with @yahoo.com and DMARC is not the @yahoo.com users' ability 
to receive mail, it's their ability to send mail to the list with From: 
[email-masked] and have it be received by list subscribers who implement 
strict DMARC policies which honor Yahoo!'s p=reject.

It's not clear how setting the @yahoo.com users to digest mode helps 
this situation at all.

Doug

---

From: Hector Santos <[email-masked]>
Date: Sun, 20 Apr 2014 18:20:46 -0400

On 4/20/2014 5:23 PM, Doug Barton wrote:

> The issue with @yahoo.com and DMARC is not the @yahoo.com users'
> ability to receive mail, it's their ability to send mail to the list
> with From: [email-masked] and have it be received by list subscribers who
> implement strict DMARC policies which honor Yahoo!'s p=reject.

Or basically, anyone with a p=reject policy will be rejected by
DMARC compliant receivers if its not signed by the author domain.  We 
have been calling this 3rd party signatures. See RFC5016 (Requirements 
for a DKIM Signing Practices Protocol) for the definition:

    http://tools.ietf.org/html/rfc5016#page-3

    o  First Party Address: for DKIM, a first party address is defined to
       be the [RFC2822].From address in the message header; a first party
       address is also known as an Author address.

    o  First Party Signature: a first party signature is a valid
       signature where the signing identity (the d= tag or the more
       specific identity i= tag) matches the first party address.
       "Matches" in this context is defined in [RFC4871].

    o  Third Party Signature: a third party signature is a valid
       signature that does not qualify as a first party signature.  Note
       that a DKIM third party signature is not required to correspond to
       a header field address such as the contents of Sender or List-Id,
       etc.

DMARC has no such separation support. Thats the problem. You know, for 
the IETF purist, this is an violation of RFC5016 if it uses the term 
DKIM in its documentation as a conforming solution.  Either that, or 
it fell thru the crack.  Lets hope its the latter and we can fix this 
problem.

> It's not clear how setting the @yahoo.com users to digest mode helps

For our MLS digest mode, the signed digest message is 5322.From the 
list domain.  Can't tell you off hand how other MLS will do this.

-- 
HLS

---

From: Christian Huitema <[email-masked]>
Date: Mon, 21 Apr 2014 01:00:17 +0000

> It's not clear how setting the @yahoo.com users to digest mode helps 

It probably does not. Trying analyze the various positions with a cool head, the obvious conclusion is that hard problems don't have easy answers.

The current mailing list practice has the mailing list as sender, and the original message composer described in the From field. The receiver sees something like:

   Sender: ietf <[email-masked]> 
   From: Christian Huitema <[email-masked]> 
   …

Of course, that particular construct could easily be abused. A phishing message does not differ much from a mailing list message:

   Sender: postmaster <[email-masked]> 
   From: Christian Huitema <[email-masked]> 
   …

I understand that the DMARC "alignment" policy is meant to protect against that by requesting that sender domain and from field match. The problem is that a mailing list would then have to invent a new from field, letting the recipient see something like:

   From: Christian Huitema <[email-masked]>
   Reply-To: Christian Huitema <[email-masked]>
   …

The obvious issue is that this particular construct is also quite friendly to phishing. The phishing message would look like:

   From: Christian Huitema <[email-masked]>
   Reply-To: Christian Huitema <[email-masked]>
   …

If we teach users to ignore the bizarre email address for the mail list messages, we are also teaching them to ignore the bizarre email address in the phishing messages. I doubt that this was the intent of the DMARC authors. 

-- Christian Huitema

(I wrote a longer version of this email at http://huitema.wordpress.com/.)

---

From: [email-masked]
Date: Sun, 20 Apr 2014 20:45:00 -0700 (PDT)

> and, IMO, not be particularly difficult.

I concur.

> Unlike the IPR
> what one could or could not say/ disclose.

I suppose it could pose difficulties for consultants in certain sorts of mixed
roles, but to be honest I don't really have much sympathy for people doing
that.

> The waters get

Indeed. Something for the IESG to consider, that's for sure.

				Ned

---

From: [email-masked]
Date: Sun, 20 Apr 2014 21:47:17 -0700 (PDT)

> frontmost in the minds of IESG folks.

On the misunderstanding/misrepresentation issue, I'm not sure asking what
could have been "done differently this time" is the right question. Our
processes were followed AFAIK. The misunderstanding/misrepresentation 
of the (preliminary) result of that process is not really a result of
what was done there, but rather the context in which the process operates.

But to my other point - what came out of the process - yes, I entirely
agree we need to look at what could have been done differently.

And on that score I'm not going to presume to offer specific advice. What I
will say is that I think you need to widen your scope to consider other
specifications. I already pointed out on the ietf-822 list how the SPFBIS
specifications contains what I consider to be totally inadequate advice on how
to address a similar, albeit less serious and far easier to address, issue. 

In fact I think some examination of how similar issues have been handled in
other recent documents is warranted.

				Ned

---

From: Yoav Nir <[email-masked]>
Date: Mon, 21 Apr 2014 10:29:18 +0300

>   From: Christian Huitema <[email-masked]> 

Right. As a mailing list provider, we have a way to make our lists work:

 From: IETF mailing list on behalf of Christian Huitema <[email-masked]>

 ...

The downside is that clicking “Reply” sends a message to the list rather than to Christian, which seems OK, but is a change of behavior. In fact it gives no natural way to reply directly (and off-list) to Christian, unless the original sender is added in CC: or Reply-To: fields.

Yoav

---

From: "John Levine" <[email-masked]>
Date: 21 Apr 2014 16:36:21 -0000

> From: IETF mailing list on behalf of Christian Huitema <[email-masked]>

It is certainly possible to create mailing-list-like things that avoid
the damage from DMARC.  The question remains why it is our job to
screw up our systems to fix their problems.  They could fix it if they
wanted, e.g., by arranging to whitelist mail sources that don't match
DMARC's authentication model but send mail people want.  This is not
just mailing lists, of course.

I subscribe to a few lists that put the list's address on the From:
line, due I think to administrative confusion, not anything
deliberate, and it is much worse than normal list mail.  When I look
at normal list mail in my inbox, I pick out the ones from people I
know first.  On the lists where it's all the same, I tend to look at
the subject and if it's not obviously interesting, dump the whole
thread.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Mon, 21 Apr 2014 09:42:35 -0700

On 4/21/2014 9:36 AM, John Levine wrote:
> They could fix it if they

Sorry, but I'm not quite understanding what additional mechanism you 
have in mind.

Exactly who does exactly what?

Who has to adopt it?

How will it scale?

d/

---

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

> ends up screwing things up.

If you say so, but I can't think of an example off the top of my head.  Is
that still a currently-used tactic?  Most of the examples I can think of
involve a valid address that produces an automated response when someone
replies, rather than using something that is completely unreachable.

I seem to recall common use of From: field validation back when that
capability was introduced into open source sendmail as an anti-spam tactic,
though it was never supported by the vendor directly.  Maybe it's less
common now.

-MSK

---

From: Doug Royer <[email-masked]>
Date: Mon, 21 Apr 2014 12:04:00 -0600

If yahoo sends out an email from list-name@yahoo, then that is where the 
email is from.

So it would be correct to set the from/sender in the email to be 
[email-masked].
Why try to make it fake anything?

If you want to preserve any digital signature in the original message, 
then send the original email as a mime body part in the forwarded message.

--

---

From: [email-masked]
Date: Mon, 21 Apr 2014 11:42:25 -0700 (PDT)

> If you say so, but I can't think of an example off the top of my head.

What planet are you on? I get mail with intentionally invalid From: fields all
the time. The domain usuall (but not always) exists, but the mailbox returns an
error.

I also get mail that says something like "this goes to a mailbox that's
unmonitored" somewhere in the message. But rather less of that.

> Is

Autoresponders for such things produce blowback spam. Not good. If the mailbox
is valid, it's usually a black hole.

Indeed, while I cannot talk about the details, I know there was a lawsuit
against an ISP that was doing this sort of checking very aggressively and
blocking lots of legitimate email. The ISP lost and was forced to remove this
check.

> though it was never supported by the vendor directly.  Maybe it's less

A lot less common. See above.

				Ned

---

From: Theodore Ts'o <[email-masked]>
Date: Mon, 21 Apr 2014 14:56:42 -0400

On Mon, Apr 21, 2014 at 12:04:00PM -0600, Doug Royer wrote:
> If you want to preserve any digital signature in the original message, then
> send the original email as a mime body part in the forwarded message.

Because this message that you just sent was sent _from_ Doug Royer, in
the sense that it was authored by Doug Royer.  It was not authored by
"[email-masked]", and that's in fact what most users would find more
interesting, since they have other ways of determining that a
particular message was sent via a particular mailing list reflector.

Fundamentally, this is going to be main issue.  For mailing list
users, when they are following a particular conversation, they want to
be able to easily identify which e-mails were contributed by which
participant.  This has historically been done via the "From" field.
It's possible to reinvent some other field, to indicate who had
originally authored the message --- say, adding a
"X-Originally-Authored-By".  But the fundamental issue is that it's
useful and interesting and wanted that people be able to get the
"originally authored by" message.  And so eventually, MUA are going to
be responsive to users' needs.

The fact that spammers could then use this confuse naive users is not
likely going to stop them, because if you are having a multi-user
conversation via e-mail, to make all of them appear to come from
"[email-masked]" is just not acceptable to the users of that
mailing list.  They will want to know who originally authored the each
e-mail message.

	   	       	    	  - Ted

---

From: Dave Crocker <[email-masked]>
Date: Mon, 21 Apr 2014 12:13:08 -0700

> If yahoo sends out an email from list-name@yahoo, then that is where the

Unfortunately, email is more complicated than that.  There are multiple 
actors, taking multiple roles.  The most important one to represent 
properly in the message is the author, shown in the rfc5322.from header 
field.

At the top level, an author is communicating with recipients, and often 
they need to be able to reply to to that author, without copying the 
other recipients.  Mess with the original From field and the ability to 
reply is typically affected.

A mailing list is a mediator to this exchange, such that, yes, it takes 
formal delivery and formally posts a new message.  However the 
'original' author and the 'final' recipients still treat this as an 
exchange between them.  The recipients are aware of the role of the 
mailing list, but they do not consider the mail to be 'from' the mailing 
list.

The mailing list is an originator, in formal terms, which is typically 
represented by the rfc5322.sender field.

Changing the rfc5322.From field to be different than what the original 
author created alters communication among the the participants.

> So it would be correct to set the from/sender in the email to be

from/sender?  those are two different fields.

> then send the original email as a mime body part in the forwarded message.

Encapsulating the original message into a subordinate message has some 
appeal.  It also well might have some additional attack vectors.  In any 
event, it's an end-to-end change, probably affecting every entity 
handling the message.

d/

---

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Apr 2014 12:20:10 -0700

On Apr 21, 2014, at 9:42 AM, Dave Crocker <[email-masked]> wrote:

> Sorry, but I'm not quite understanding what additional mechanism you have in mind.
> 

Dear Dave,

Each domain can simply point to their desired white-list. This can be one published directly or simply referenced as described in:

http://tools.ietf.org/html/draft-otis-dkim-tpa-label-06#page-8

This has elements from the moribund ADSP.  The sender wishing to protect a domain while also applying policy like that of ADSP or DMARC can offer receivers a rapid and scalable method to check third-party domain authorizations.  This means senders are always able to defend recipients who trust messages from their domain.  Please note, authorizations can also require presence of a List-ID.  Other schemes, such as SRS, end up treating third-parties the same, which never works. 

Perhaps being a bit crass, those who have decided to adopt DMARC for their user accounts have a vested interest in seeing mailing-lists fail.  Their revenue is often based on ads displayed in a user's browser.  Forcing use of some social web site has an advantage of injecting ads while also balkanizing group efforts.  Is the IETF ready to offer their own version of a social website or start an email version of a three-card monte game of "Where is the From?  Must all other group endeavors demand some social allegiance or can these sites become federated using something like XMPP and give up on email?

Regards,
Douglas Otis

---

From: "John Levine" <[email-masked]>
Date: 21 Apr 2014 19:53:08 -0000

>> about its legitimacy. ...

>though it was never supported by the vendor directly.  Maybe it's less

If people start rejecting because .INVALID is on the From: line, it
is the work of a moment to adjust it to something like this:

 From: Marissa <[email-masked]>

and the work of about three moments to spin up a fake MTA that accepts
any RCPT TO and rejects at DATA.  Or I suppose it could just be an
open relay.  

This of course trains people to be phished, by telling them that
<[email-masked]> is the same as <[email-masked]>.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Apr 2014 08:07:25 +1200

> mailing list.  They will want to know who originally authored the each

In fact it's a lie: the message is *not* from the mailing list, it's
from its originator. I have no doubt some ingenious lawyer could
discover a tort in the lie, so it might even be legally dangerous for
the mailing list operator to tell this lie on every message.

Among other things, it makes it virtually impossible to filter trolls.
I am on a couple of lists at the moment where troll filtering is
essential for one's sanity (and where DMARC has been discussed too, as
it happens).

   Brian

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 21 Apr 2014 13:48:36 -0700

> the time. The domain usuall (but not always) exists, but the mailbox

Rudeness aside, I'm on a planet where I can't remember the last time I got
a message where the stuff after the "@" was a domain name that doesn't
exist.  Maybe you get them, but I don't.  Sorry to burst your blustery
bubble.

> unmonitored" somewhere in the message. But rather less of that.

Yes, I get those too.

-MSK

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 21 Apr 2014 23:07:29 +0200

Hi, Doug,

On 04/21/2014 09:20 PM, Douglas Otis wrote:
>
> On Apr 21, 2014, at 9:42 AM, Dave Crocker <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Each domain can simply point to their desired white-list. This can be 
> one published directly or simply referenced as described in:
>
> This has elements from the moribund ADSP.  The sender wishing to 
> protect a domain while also applying policy like that of ADSP or DMARC 
> can offer receivers a rapid and scalable method to check third-party 
> domain authorizations.  This means senders are always able to defend 
> recipients who trust messages from their domain.  Please note, 
> authorizations can also require presence of a List-ID.

This doesn't answer Dave's questions: who has to adopt it and how will 
it scale.

Adoption: of course the owner of the sending domain has to adopt it, but 
is there also a role for the owners of mailing lists, invite services 
etc.? How will the sending domain ever know whether a mailing list is 
open or closed for example? How will it know which invite services will 
need a TPA exemption?

Scaling: how does the owner of the sending domain (potentially very 
large numbers of users) know to what mailing lists its users are 
subscribed, what invite services will potentially need this TPA 
authorization etc.? Furthermore, will it scale if mailing lists can be 
members of mailing lists and how will the sending domain know about this 
hierarchy or chain of mailing lists? So the technical howto might be the 
easy part of the solution, while the organizational howto will 
definitely be the difficult part...

/rolf

---

From: [email-masked]
Date: Mon, 21 Apr 2014 15:50:29 -0700 (PDT)

> exist.  Maybe you get them, but I don't.  Sorry to burst your blustery
                                                                       
And have you bothered to read what I actually said, you would have noticed that
my statement and your "bubble burster" are not very far apart. To repeat, I
said that in my experience "the domain usually (but not always) exists".

You might also want to consider that people have implemented the .invalid hack.
I'm not hearing any reports of widespread message rejection because of it. Are
you?

				Ned

---

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Apr 2014 18:16:36 -0700

On Apr 21, 2014, at 2:07 PM, Rolf E. Sonneveld <[email-masked]> wrote:

>> This has elements from the moribund ADSP.  The sender wishing to protect a domain while also applying policy like that of ADSP or DMARC can offer receivers a rapid and scalable method to check third-party domain authorizations.  This means senders are always able to defend recipients who trust messages from their domain.  Please note, authorizations can also require presence of a List-ID.  
> 
> This doesn't answer Dave's questions: who has to adopt it and how will it scale.

Dear Rolf,

Sorry, I thought the scheme was easy to understand.

The basic white-list hash-label publication scheme is a single and small DNS query referenced at a _tpa subdomain within the sender's domain in much the same manner _dmarc  and other policy schemes operate.  RRs TTL can be set at levels that provide sustainable query burdens.  DNS can also scale using anycast and support very high query rates.  DMARC senders would need to publish their white-list indicating support of this protocol and of course it could also be signaled within DMARC.  Since this list offers a low overhead service for recipients there should be quick implementation at the other end of the exchange by recipient ESPs.  This also affords senders full control over all of their desired policy exceptions. If there is a problem, senders would only have themselves to blame.

Please note, MLM software or From header fields do not change at all.  The major portion of the effort would be by sending domains having a goal of offering better protection while preserving desired use.  The white-list can also be shared with other DMARC domains who trust the list's administration. Technically, this should be seen as a change to DKIM and SPF in a similar manner as ATSP did.  Of course, the change can be appended to existing processes.  There were necessary elements missing from ATPS which also required DKIM signatures to change that made deployment impractical.

> Adoption: of course the owner of the sending domain has to adopt it, but is there also a role for the owners of mailing lists, invite services etc.? How will the sending domain ever know whether a mailing list is open or closed for example? How will it know which invite services will need a TPA exemption?

At one time, we provided a reputation list that answered that very question, but there has not been a need for the MLM list for several years now.  If a sender receives any report of abuse, they can notify the list.  If there is not a timely response, the MLM can be de-authorized by the sender. Quick and painless.

> Scaling: how does the owner of the sending domain (potentially very large numbers of users) know to what mailing lists its users are subscribed, what invite services will potentially need this TPA authorization etc.?

Perhaps senders could ask their users which MLM they wish to use.  They could also monitor their DMARC feedback as well.

> Furthermore, will it scale if mailing lists can be members of mailing lists and how will the sending domain know about this hierarchy or chain of mailing lists? So the technical howto might be the easy part of the solution, while the organizational howto will definitely be the difficult part...

There is nothing wrong in having all the trusted MLMs listed to then permit list to list traffic.  It would not involve any complex changes to message signing or header field use either.   Use of TPA would have dramatically lower overhead than that caused by reverse DNS queries or that of chained SPF records. 

Regards,
Douglas Otis

---

From: Doug Barton <[email-masked]>
Date: Tue, 22 Apr 2014 15:50:39 -0700

On 04/18/2014 05:33 PM, Ned Freed wrote:
>>>> I said: Rather than throwing up our hands and telling the DMARC
>>>> folks that we refuse to work with them unless their solution
>>>> solves the problem of our anachronistic use case that that
>>>> constitutes only a tiny percentage of their overall traffic;
>>>
>>> Again with the traffic size as justification for poor behavior.
>>> Not all messages are created equal, and some functions have
>>> utility entirely disproportionate to the amount of bandwidth they
>>> use.
>
>> Right, so the input here from the operators is, "Mailing list
>> traffic is not important enough to us to prevent us from deploying
>> an anti-spam solution that solves the vast majority of our problems
>> with little cost or difficulty. The MLM software authors will have
>> to deal with this problem on their end." And your response is to
>> stamp your feet and shout, "But my mailing list traffic IS
>> important! It is, IT IS!!!!!"
>
> I really have to wonder where you got enough straw to build a
> strawman of this size. If you actually, you know, read what I've been
> saying, it has been that this was handled extremely poorly by the
> IETF. Just not in the way you happen to believe.
>
> Your view of what happened, who the operators actually are and what
> their positions are, and what the likely consequences are going to be
> are somewhere between a gross oversimplifications and looney tunes.
> But I must say they are amusing.

First, I acknowledge that you seem to be interested in addressing the 
IETF's failings, the problem is that small matter of disagreement on 
what those failings are. You say that my version of events is "looney 
tunes," and yet there is "rough consensus and running code" backing it 
up. Even before AOL joined the p=reject team, but much more so now.

It's incredibly obvious that the IETF either didn't listen to, or didn't 
act on clear messages from the operator community on this topic. Trying 
to re-paint the failure as one of process (or whatever weird rathole you 
appear to be willing to travel) doesn't help the situation at all.

For this issue what would help is for the IETF to admit its failure, and 
take in hand the problem of solving mailing list delivery for DMARC 
protected domains (along with the MLM software authors of course). If 
there are other places where DMARC has weaknesses that can be shored up, 
let's tackle those too.

What won't help is sitting on the sidelines and whinging that the "DMARC 
cabal" "doesn't get it" and has to listen to us about how it should 
conduct their business. Because not only do they clearly not have to do 
that, they are not doing it. You will see more and more large mail 
providers implementing p=reject because it's good for them, and the 
fallout from Yahoo!'s implementation has been marginal (from their 
perspective).

 From a larger perspective it would be very useful for the IETF to take 
this message to heart in other areas, like say ... DHCPv6. But I digress. :)

> Wrong again. The evidence shows clearly that the IETF did listen, to
>  this group at least. Where the IETF failed was in not looking at the
> big picture and likely consequences, which I'm afraid is not laid out
> along the axis of "big operators all supporting DMARC" versus "tiny
> insignificant list maintainer stick-in-the-muds".

I'm not sure who you're defining as "the IETF" in this context, but the 
record seems to show that there was a non-zero number of people telling 
the DMARC folks that their spec should not be implemented because it 
doesn't solve the mailing list problem, among others. So rather than 
listening to the operators and working to solve the MLM problem, there 
was whinging, and intransigence. I don't care how you want to 
characterize the problem, the failures of communication and inaction are 
pretty clear.

Doug

---

From: [email-masked] (Martin Rex)
Date: Thu, 24 Apr 2014 23:35:16 +0200 (CEST)

Doug Barton wrote:
> that, they are not doing it.

But that is exactly what happens here, they obviously don't get it at all.

In case you didn't know or realize, what DMARC specifies for p=reject
is actually a real felony crime in Germany (no kidding!), and this may
apply to all over Europe (since the basic idea was spread out all over
europe with a EU directive), unless each individual receipient(!!) has
explicitly opted-in for this to happen.  It should be fairly easy 
to get a cease-and-desist order against European ISPs for blocking
EMail on DMARC p=reject.

It also should stop since it is technically wrong.  It is the tail
trying to wag the dog and some form of company-level bullying.

Get all those stupid MUAs fixed that misrepresent the meaning of rfc5322.From,
and in particular the meaning of rfc5322.From when a rfc5322.Sender is
present in the same message.

-Martin

---

From: Doug Barton <[email-masked]>
Date: Thu, 24 Apr 2014 15:18:03 -0700

> But that is exactly what happens here, they obviously don't get it at all.

... and yet the DMARC rollout continues. My point being that complaining 
about it has been ineffective so far, and is likely to continue to be 
ineffective.

> is actually a real felony crime in Germany (no kidding!),

I can't comment intelligently on that point. However I would assume that 
the high-powered attorneys at the large multi-national corporations 
(Yahoo! and AOL) who have already deployed it don't think you're right. 
OTOH if you are right, it will make an interesting side show. :)

> It also should stop since it is technically wrong.

That's your opinion, and the opinion of a non-trivial number of people 
on this list. But again, even if you're right, the thing is being 
deployed anyway. So fixing the mailing list software is the right thing 
to do regardless.

> It is the tail trying to wag the dog

You have "the tail" and "the dog" reversed. Mailing list traffic is a 
tiny fraction of what the big providers carry. IT is the tail.

Doug

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 24 Apr 2014 19:28:20 -0400

Martin,

> to get a cease-and-desist order against European ISPs for blocking
Can you provide a legal citation?  That would be really cool!

 From where I sit, it also looks like a violation of the US Computer 
Fraud and Abuse Act (effectively, knowingly causing damage to other 
systems - which has been applied to DDoS attacks).  But I haven't heard 
any lawyers or prosecutors stand up and confirm that.

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 24 Apr 2014 19:24:32 -0400

Doug Barton wrote:
> ... and yet the DMARC rollout continues. My point being that 
> complaining about it has been ineffective so far, and is likely to 
> continue to be ineffective.
>
> I can't comment intelligently on that point. However I would assume 
> that the high-powered attorneys at the large multi-national 
> corporations (Yahoo! and AOL) who have already deployed it don't think 
> you're right. OTOH if you are right, it will make an interesting side 
> show. :)
>
> deployed anyway. So fixing the mailing list software is the right 
> thing to do regardless.
>
Is that really true, after you eliminate all of the spam, and the ads 
that fall just this side of "legitimate?"

Given that spam is now, what, 80+ percent of net traffic (some sources 
claim >90%), I wonder what the real breakdown is between:
- personal email
- work email
- notifications from social media sites
- "real" commercial traffic (bills, statements, order confirmations)
- list traffic (including work/company/university lists, user support, 
project-specific, affinity groups, churches, one's kids' schools, etc.)

And then I wonder how that differs for:
- personal mailboxes
- work mailboxes
- separate mailboxes set up to insulate one's personal mailbox from 
things other than personal and work traffic

In that later regard, I see an awful lot of people who set up mailboxes 
on free services, specifically for list-related traffic.

Speaking personally for a moment, and I'm certainly atypical, what I see is:
- personal account (been around a long time, highly visible, aggregates 
a lot of older accounts, a lot of admin traffic is routed to it as well)
--- 5000 messages a day
--- 4500, automatically filtered to /dev/null (spam, admin traffic I 
really don't want to look at, some old lists)
--- of the remaining traffic:
------ 200 or so - spam that gets past loose spam traps, deleted by eyeball
------ 225 or so - admin and list traffic (more these days, given the 
DMARC and IANAxfr discussions)
------ 25 - a mix of personal, notifications, various other stuff

- AOL and Yahoo accounts - rarely used - whenever I check, ALL spam
- work account: mostly 1-1 and some professional newsletters (1-way lists)

I'd be really interested in profiles of typical user accounts from big 
providers who claim that most of what they handle isn't list traffic.

Miles Fidelman

---

From: [email-masked] (Martin Rex)
Date: Fri, 25 Apr 2014 02:26:22 +0200 (CEST)

> Can you provide a legal citation?  That would be really cool!

1. Blocking EMail based on DMARC policy is illegal per §206 Abs. 2 Nr. 2 StGB.

2. Actually, even looking at rfc5322.From (rather than MAIL FROM:) for
   the purpose of looking up DMARC policy records 
   is illegal per §206 Abs. 2 Nr. 1 StGB.

3. Any DMARC-triggered reporting about forwarded emails is also illegal
   per §206 Abs. 1 StGB and §88 TKG.

And while I'm currently not sure whether the first two are similar
all over europe, the last one DEFINITELY is under the current EU data
protection directive.

Technically, EMail is an issue between a sender of a telecommunication,
a receiver of a telecommunication and a telecommunication service provider.

If an MTA is relaying (or delivering to a mailbox), then the sender is
whoever talks at the other end of the TCP connection that is used to
transfer the EMail to the MTA on port 25.  The receiver is what is
named by the sender in the RCPT TO: command (the mail contents is off limits),
and the MTA is an agent of the telecommunications provider.

What appears in the rfc5322.from of the message is legally, none of the
MTAs business.  And even if is be an attribution of authorship
of some third party in rfc5322.from, this party has absolutely no say
in what contents sender transfers to receiver.  It is also illegal
for the telecommunications service provider to reveal the fact of
this communication to other parties. This even applies to failed
communication attempts.  The only party to which the telecommunications
provider would be allowed to report a failed delivery is the address
(if any) supplied by the sender (i.e. the MAIL FROM: envelope address).

> any lawyers or prosecutors stand up and confirm that.

The DMARC policy scheme is actually censoring of a telecommunication 
between a messge sender and a message receiver through a telecommunications
provider by some _outside_ third party.  So in the US a p=reject DMARC policy
might potentially be freedom of speech (1st Amendment) violation.

-Martin

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 24 Apr 2014 20:44:37 -0400

On Friday, April 25, 2014 02:26:22 Martin Rex wrote:
...
> provider by some _outside_ third party.  So in the US a p=reject DMARC
> policy might potentially be freedom of speech (1st Amendment) violation.

No idea about the rest of it, but this is nonsense.  The 1st Amendment to the 
constitution is a restriction on government action, not on private action.  
See http://xkcd.com/1357/ .

Scott K

---

From: [email-masked] (Martin Rex)
Date: Fri, 25 Apr 2014 02:51:33 +0200 (CEST)

> See http://xkcd.com/1357/ .

OK.  I'm terribly sorry for you across the pond then.

In the German constitution and in the European Human Rights Convention
this is a basic right, and it protects not just from your own government,
but also from private actors and other governments.

-Martin

---

From: "John Levine" <[email-masked]>
Date: 25 Apr 2014 01:17:16 -0000

>   per §206 Abs. 1 StGB and §88 TKG.

If that's true, how can spam filtering be legal?  The phrase "without
authorization" is pretty elastic, and all the ISPs I know consider themselves
authorized to mange user mail any way they want.

>might potentially be freedom of speech (1st Amendment) violation.

Uh, no.  The First Amendment does not affect private entities, and
case law (White Buffalo vs. Texas) says that government entities have
broad discretion to do network management when acting as ISPs.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Thu, 24 Apr 2014 18:41:12 -0700

> See http://xkcd.com/1357/ .

Dear Scott,

Strongly disagree.  The US government failed to protect citizen's rights by not declaring ISPs common carriers.  People's ability to meet and freely associate is now being steadily eroded by policies hostile to decades of neighborhood and small communities' normal meeting practices. This has nothing to do with someone being abusive and shunned.  This is about ISPs taking greater control over content carried on the Internet.  The usurping of control over Internet use is very likely to put democracy in greater peril as content control is taken over by an oligarchy.

The TPA scheme would have allowed DMARC to shun abusers without impacting perfectly legitimate communication methods being used in support of our growing communities.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 24 Apr 2014 21:50:28 -0400

On Thursday, April 24, 2014 18:41:12 Douglas Otis wrote:
> > No idea about the rest of it, but this is nonsense.  The 1st Amendment to
> > the constitution is a restriction on government action, not on private
> > action. See http://xkcd.com/1357/ .
> 
> Dear Scott,
> 
> Strongly disagree.  The US government failed to protect citizen's rights by
> not declaring ISPs common carriers.  People's ability to meet and freely
> associate is now being steadily eroded by policies hostile to decades of
> neighborhood and small communities' normal meeting practices. This has
> nothing to do with someone being abusive and shunned.  This is about ISPs
> taking greater control over content carried on the Internet.  The usurping
> of control over Internet use is very likely to put democracy in greater
> peril as content control is taken over by an oligarchy.

I didn't say it was a good idea.  I said it wasn't unconstitutional.  No all 
constitutional ideas are good ones.  It's a case of law, not fundamental 
rights.

Scott K

---

From: [email-masked] (Martin Rex)
Date: Fri, 25 Apr 2014 04:02:08 +0200 (CEST)

John Levine wrote:
[ Charset UTF-8 unsupported, converting... ]
> >1. Blocking EMail based on DMARC policy is illegal per ?206 Abs. 2 Nr. 2 StGB.
> >
> >   is illegal per ?206 Abs. 2 Nr. 1 StGB.
> >
> >   per ?206 Abs. 1 StGB and ?88 TKG.
> 

"without authorization" is a quite well-defined concept in telecommunication
legalese in Europe.  Only the sender, and the recipients specified by the
sender are authorized.  The telecommunications service provider is NOT
authorized, and neither is an employer.

SPAM filtering MUST be implemented as voluntary opt-in, otherwise it will be
illegal, as you correctly notice.  Spam-filtering can only be legal when
it is performed strictly on behalf of the recipient, the receipient is
in full control over the behaviour all the time, and the blocking or
deletion of any messages is performed with explicit and voluntary
(i.e. condition-free) consent of the receipient himself.

A preselection to tag Mails as potential spam or to store potential
spam in a second inbox might be permissible, a preselection to block
or delete potential spam would certainly be illegal.

-Martin

---

From: "John R Levine" <[email-masked]>
Date: 24 Apr 2014 22:10:31 -0400

> (i.e. condition-free) consent of the receipient himself.

If that were true, there would be no Gmail, Hotmail, or Yahoo mail users 
in Germany, since they offer only limited control over spam filtering, and 
some stuff, e.g. DNSBL blocks, is unconditional.

I expect that the mail systems make it a condition of subscription that 
the recipients consent to the mail system doing whatever it has to do to 
filter incoming mail.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Apr 2014 22:23:58 -0400

On Apr 24, 2014, at 9:41 PM, Douglas Otis <[email-masked]> wrote:
> The US government failed to protect citizen's rights by not declaring ISPs common carriers.

Is this conversation really appropriate for the IETF mailing list?

---

From: [email-masked]
Date: Thu, 24 Apr 2014 19:45:02 -0700 (PDT)

> up.

What is this "rough consensus and running code of which you speak?" My
understanding of that phrase has always been that it refers to the assessment
of documents within the IETF process. Exactly how is that supposed to apply
to independent documents such as this one?

And if you're talking about there being a consensus among serevice providers
regarding the use of p=reject in the fashion of AOL and Yahoo, I've seen
absolutely no evidence of that. Indeed, I've seen exactly the opposite. Our
customers tend to be very large concerns, and while I cannot get into specifics
for obvious reasons, I can assure you that they are not all hunkey-dorey with
what Yahoo and AOL are doing.

> Even before AOL joined the p=reject team, but much more so now.

Seriously? A move by a single provider, now joined by another, represents some
sort of industry consensus?

> act on clear messages from the operator community on this topic.

Well, here I sort of agree. What the IETF didn't do is react to the danger this
posed in a timely way. Either on a technical or political level.

> Trying

And that means... what, exactly? Of course fixing process issues after the fact
aren't going to help the present situation any.

> there are other places where DMARC has weaknesses that can be shored up,

Again, what part of "unwilling to make any changes" did you not understand?

> conduct their business.

Of course it wouldn't help. Which is why I never did that.

> Because not only do they clearly not have to do

I have no doubt that some other providers who have mixed business transaction
mail on the same domain with personal email will follow suit. I'm skeptical
this will extend to those like Google who have kept them separate, or providers
that focus on providing personal mail accounts.

Only time will tell.

> characterize the problem, the failures of communication and inaction are

Suffice it to say I don't see it that way.

And with this reply I'm done with this conversation. You have a view of the
email world as well as the events that have transpired that is so completely at
odds with reality that this is no point in further discussion with you.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Thu, 24 Apr 2014 20:23:47 -0700

On 4/24/2014 7:45 PM, [email-masked] wrote:
>> It's incredibly obvious that the IETF either didn't listen to, or
>> didn't act on clear messages from the operator community on this
>> topic.
>
> Well, here I sort of agree. What the IETF didn't do is react to the
> danger this posed in a timely way. Either on a technical or political
> level.

The fundamental flaw in this sort of view is that the IETF initiates 
organization efforts. Or that it acts on "messages".  It doesn't.  It 
provides an environment for workers from the community to organize open 
standards efforts.

In other words, the failure is of the industry to formulate an effort 
and bring it to the IETF.  Other than SPF, DKIM and DMARC, of course, 
which have variously been brought to the IETF.  (I'm not trying to 
re-open a debate on the details of those three, but merely to note that 
they are examples.)

Were there examples of efforts to bring work to the IETF and have it be 
rejected, that might be the IETF's 'fault'.  DMARC is the closest 
example to that and, as has been thoroughly hashed and re-hashed, it did 
not match the usual IETF model for doing work.

So sorry, but no, there have been essentially no 'clear messages from 
the operator community' and more importantly, no /efforts/ other than 
SPF, DKIM and DMARC.

d/

---

From: [email-masked] (Martin Rex)
Date: Fri, 25 Apr 2014 05:54:50 +0200 (CEST)

> some stuff, e.g. DNSBL blocks, is unconditional.

Why?  Germans are allowed to use/subscribe to services that hosted/operated
outside of Europe and under foreign jurisdiction, i.e. without the
protections that European and national jurisdiction provides.
But we do not have to.  So it would be unreasonable to do so,
where viable local alternatives exist.  But certainly it is permitted.

> the recipients consent to the mail system doing whatever it has to do to 

What telecommunication service providers can legally offer depends on the
jurisdiction under which they're operating.

Fortunately our legislators are not that naive.  The statue explicitly says,
that pretty much all such "under the condition" consent agreements signed by
the subscriber will be legally void.  (§95 Abs. 5 TKG)

Under German jurisdiction, at least, telecommunication service providers
that (a) offer their services to the public and (b) connect to public
communication networks and (c) enable communication between at least
one of their own subscribers and any public communication networks
becomes subject to the exact same regulations as all big TelCos,
and MUST respect the protection of the telecommunication privacy for
*ALL* of their subscribers and all communications between subscribers
(own subscribers as well as subscribers of other service providers).

-Martin

---

From: Douglas Otis <[email-masked]>
Date: Fri, 25 Apr 2014 02:13:07 -0700

> Is this conversation really appropriate for the IETF mailing list?

Dear Ted,

Protocols related to pervasive monitoring, reduced security, or granting overwhelming control to a select few at an expense of many should be valid topics within the IETF.  These larger questions can and should provide some guidance in setting group priorities.

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Fri, 25 Apr 2014 08:27:39 -0400

On 4/24/2014 11:23 PM, Dave Crocker wrote:
> provides an environment for workers from the community to organize
> open standards efforts.
>
> re-open a debate on the details of those three, but merely to note
> that they are examples.)
>
> ....
>

Dave, you were involved in all this.  You resisted POLICY and threw 
out ADSP, yet you supported DMARC without resolving any of the exact 
policy concerns involving middle ware.

Your approach was to just allow the problem to continue to exist as if 
it was only a small use case.  You blindly and also intentionally and 
neglectfully ignored everything that had to do with this issue.  You 
told others to also ignore these concerns. Yet, you are now promoting 
DMARC which has the same exact problem.  It doesn't make any sense.

No, I'm sorry to say. you can't push this issue on any one else but 
yourself.  You were the KEY COG in this entire DKIM+POLICY+TRUST 
effort.  But you  didn't CHAMPION POLICY, nor did the author of ADSP 
and it suffered the consequences.  You can't expect high quality in 
work when the author doesn't champion his own work.  When others cited 
interest to take it over, it was ignored as well.  We can blames the 
chairs and ADs of the DKIM-WG too for allowing this to happen.

All the concerns, desires, integration issues, are in the archives and 
also in I-Ds and also RFCs.  Instead, you had a policy of intentional 
ignorance, filtering mail you just didn't wish to read.  Not important 
in your book. You also used INFORMATIONAL non-wg fast tracked 
documents to change proposed standard track items and the course of 
their WG direction, in the case of ADSP - down the tubes.  You made it 
historic. Perhaps millions of combine IETF-MAN-YEARS wasted down the 
tubes, and for what?  To get DMARC which had the same 3rd party 
signature problem that you desperately need to get working in order 
for the DKIM+TRUST framework to work.  You don't need to explain 
yourself but please don't you dare put this on others in the 
community, including myself, who worked hard for the past 9+ years on 
all this and yes even implemented all these protocols with "running 
code" only for you to say, it doesn't matter, too small, lets get rid 
of it!!

Ok, put all that past stuff away. What are you going to do NOW!?  How 
are you going to help lead the way?  If not, you need to allow others 
begin to solve the problem without all this interfering philosophical 
b-llsh-t that has held back the IETF DKIM+POLICY efforts and hurt its 
reputation - big time.   You are a highly respected person, but you 
were completely wrong with how your were pushing DKIM.  You didn't 
help with its original policy framework and now DMARC has forced the 
issue.  What are you going to do now?

-- 
HLS

---

From: [email-masked]
Date: Fri, 25 Apr 2014 07:56:54 -0700 (PDT)

I'm done with the original thread on this topic, but there's a bit here that
warrants a separate response.

> provides an environment for workers from the community to organize open

You may want to argue that's how the IETF should work, but I'm afraid I don't
see it matching up with how it actually works.

An obvious counterexample is what recently happened in perpass and the various
works it has started. Regardless of what anyone thinks of perpass or its
outcome, a fair characterization is that it was an IETF repsonse to the
message delivered by Snoden et al.

And maybe something has changed since the four years I spent going to IESG
retreats, but I recall lots of discussion of how the IETF as an organization
should respond to various industry trends.

Now, I suppose you could characterize both of these as "people  coming together
to work on stuff", with the IETF just providing the environment. But it seems
pretty clear that people regard the IETF as a bit more than that. Maybe they
shouldn't, but they do.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 Apr 2014 08:21:43 -0700

On 4/25/2014 7:56 AM, Ned Freed wrote:
> An obvious counterexample is what recently happened in perpass and
> the various works it has started. Regardless of what anyone thinks of
> perpass or its outcome, a fair characterization is that it was an
> IETF repsonse to the message delivered by Snoden et al.

Yup.  It's a singular example, but that's the point.  It's not what the 
IETF (usually) does.

It's fine that it's being attempted and it might (or might not) prove 
useful.  But there is no pattern of the IETF doing such a thing.

My point was not meant as a statement of philosophy or criticism of the 
IETF, but a description of the long-term operational model that covers 
its actual history.

That model is for initiatives to come from the grass roots of the 
community, seeking facilitation within the IETF.  These do not depend 
upon strategic management directions being set.

> And maybe something has changed since the four years I spent going to
> IESG retreats, but I recall lots of discussion of how the IETF as an
>  organization should respond to various industry trends.

Yes, we often have such discussions.  My observation is that it has 
typically had little or no effect on what work is actually done, absent 
initiative from the community.

With respect to getting work done, this is a bottom-up organization, not 
a top-down one.  (That's why I think Area "Director" is a serious 
misnomer and Area "Facilitator" would be far more accurate.)

>  But it seems pretty clear that people regard the IETF as
> a bit more than that. Maybe they shouldn't, but they do.

Yes, there is quite a bit of mythology about the IETF.  Sometimes it 
borders on mysticism...

d/

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 25 Apr 2014 16:31:47 +0100

This is a handy thread and brings into question what the 'S' in IESG is supposed
to mean.

On the whole I take it as Dave to mean that the IESG should facilitate. That may
mean spotting when people have focus and energy for a topic and helping to put
them together and make space for the work. But it also may mean spotting when
work "needs to be done" and encouraging people to get together to do that work.

(Internet Engineering Spotter Group?)

Adrian

> From: ietf [mailto:[email-masked]] On Behalf Of Dave Crocker
>

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 25 Apr 2014 11:56:25 -0400

Dave Crocker wrote:
>
> With respect to getting work done, this is a bottom-up organization, 
> not a top-down one.  (That's why I think Area "Director" is a serious 
Bottom up is generally a good thing, and that's certainly been IETF's 
traditional modus operandi.  But... in that IETF is the official 
standard body for the Internet - and it's ultimately the standards that 
hold the Internet together -- isn't the real discussion about:

1. Are the emerging scale, scope, complexity, and issues involved in 
Internet operation/management/<your favorite term> highlighting the 
limits of that bottom-up (or perhaps, arms-length) approach to the way 
IETF is playing its role?

2. Are there changes needed?

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 25 Apr 2014 12:05:03 -0400

Dave Crocker wrote:
> Yup.  It's a singular example, but that's the point.  It's not what 
> the IETF (usually) does.
>

Silly question, but perhaps relevant in the context of the IANAxfr 
discussions:
So, a lot of what IANA does is covered by an MOU between IETF and IANA.  
What happens if IANA doesn't honor it's end of the MOU?  I don't believe 
it has any recourse measures spelled out.  Beyond that, how would "the 
IETF" actually notice and respond? (Both informally and formally.)

Seems to be another example of a key role that belongs to the IETF that 
contrasts a bit with its historical way of operating.

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 25 Apr 2014 12:16:47 -0400

Thanks for the citation!  Also see below...

> might potentially be freedom of speech (1st Amendment) violation.
Not 1st amendment - as others pointed out, it's not an action of Government.

To elaborate on the CFAA, however - I copied this from: 
http://www.technicallylegal.org/the-legality-of-denial-of-service-attacks/ 
-- it's from a discussion of what laws might apply against a DDoS 
attack, but it sure seems to sound like what those who set DMARC 
p=reject are doing:

In terms of criminal violations, there’s the Computer Fraud and Abuse 
Act <http://en.wikipedia.org/wiki/Computer_fraud_and_abuse_act> (the 
“CFAA”), which prohibits a person from “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” (see 18 U.S.C. § 1030(a)(5)(A) 
<http://www.law.cornell.edu/uscode/html/uscode18/usc_sec_18_00001030----000-.html#a_5>). 
The requisite “damage” element under the CFAA is “any impairment to the 
integrity or availability of data, a program, a system, or information” 
(see 18 U.S.C. § 1030(e)(8) 
<http://www.law.cornell.edu/uscode/html/uscode18/usc_sec_18_00001030----000-.html#e_8>) 
and a “protected computer” is defined as a computer “which is used in or 
affecting interstate or foreign commerce, including a computer located 
outside the United States that is used in a manner that affects 
interstate or foreign commerce or communication” (see 18 U.S.C. § 
1030(e)(2)(B) 
<http://www.law.cornell.edu/uscode/html/uscode18/usc_sec_18_00001030----000-.html#e_2>). 

DoS attacks almost unquestionably fall under the broadly-worded 
prohibited activity in this portion of the CFAA (“transmitting … 
information, code, or command”) and would likely meet the low standard 
of damage (“any impairment to the integrity or availability of data, 
program, system, or information”). The CFAA may also apply to 
unsuccessful attempts (see 18 U.S.C. § 1030(b) 
<http://www.law.cornell.edu/uscode/html/uscode18/usc_sec_18_00001030----000-.html#b>).

The CFAA also has a civil component that permits “[a]ny person who 
suffers damage or loss by reason of a violation of this section may 
maintain a civil action against the violator to obtain compensatory 
damages and injunction relief.” In other words, the target of the DoS 
attack can sue the individual(s) who were responsible for the damages 
incurred as a result of the attack (e.g., server downtime, costs to 
repair, and in some lost revenue (see 18 U.S.C. § 1030(g) 
<http://www.law.cornell.edu/uscode/html/uscode18/usc_sec_18_00001030----000-.html#g>). 
There is a limitation that requires the damages exceed $5,000; however, 
some courts have liberally construed its calculation to include 
consultation services (e.g., IT/security persons) used to assess the 
extent of damage caused by the attack.  Also, this provision does not 
require that a person ever be convicted before being sued for damages.

--------
That last paragraph kinda makes me think about a civil lawsuit :-)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 25 Apr 2014 09:32:58 -0700

> Thanks for the citation!  Also see below...

I'm just curious: Is anyone on this thread a lawyer?

-MSK

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 25 Apr 2014 18:34:15 +0100

On Friday, April 25, 2014, Miles Fidelman wrote:

>> a top-down one.  (That's why I think Area "Director" is a serious misnomer
>> and Area "Facilitator" would be far more accurate.)
>>
> traditional modus operandi.  But... in that IETF is the official standard
> body for the Internet - and it's ultimately the standards that hold the
> Internet together -- isn't the real discussion about:
>
> Internet operation/management/<your favorite term> highlighting the limits
> of that bottom-up (or perhaps, arms-length) approach to the way IETF is
> playing its role?

That role is done by IETF WGs, that makes WGs very important to represent
the approach of bottom-up-decision-making. Just or General Area has no
WGs!!!

> 2. Are there changes needed?

We need to think of our IETF areas more seriously, and we need some WGs in
the IETF general area to represent bottom-up-consultations. WGs that make
more procedure drafts for IETF within the big changes of the internet in
future.

AB

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 25 Apr 2014 14:54:27 -0400

> From: "Adrian Farrel" <[email-masked]>

> This is a handy thread and brings into question what the 'S' in IESG
> is supposed to mean.

As far as I can see, the IETF primarily develops protocols.  Work
which does not revolve around developing protocols does not happen in
the IETF.  Perpass is an example of this, because although it
*considers* pervasive monitoring, its *purpose* is the development of
protocols that are resistant to monitoring and creating an attitude
that monitoring must be considered in the development of other
protocols.  Perpass *exists* because a critical mass of people want to
work on such protocols.

In regard to the IESG, it "steers" by deciding whether or not to
charter working groups.  But its biggest job is reviewing standards
developed by the working groups.  It certainly does not "allocate
resources", that is, decide that some topic needs to be worked on and
recruit people to do the work.

Dale

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Apr 2014 16:15:35 +1200

...
> initiative from the community.

I don't think that's completely fair. Yes, of course nothing will
get done unless there are people willing to do it. But if the
IAB holds a workshop on ploomdoogleblits, which will undoubtedly
include some IESG members and some people who aren't members of
the I* at all, some ideas will emerge about how the IETF should
respond to the ploomdoogleblit work that is going on in academia or
industry. Drafts will appear, apparently from the "bottom", and
a BOF proposal maybe - which certain IESG members will be ready
to pay attention to, because they were at the ploomdoogleblit
workshop.

Of course that's not the only path to getting work into the
IETF, but it's one of the paths, and it happens. (Maybe it
would happen more if the IAB became the Internet Innovation
Board.)

    Brian

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 Apr 2014 21:59:23 -0700

On 4/25/2014 9:15 PM, Brian E Carpenter wrote:
>   But if the
> industry. Drafts will appear,

It could be interesting to document this presumed cause/effect relationship.

Start with a listing of every workshop.  Then indicate the related I-Ds 
that were initiated afterwards.  Then indicate which ones made it to RFC.

d/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 26 Apr 2014 13:28:52 -0400

On Fri, Apr 25, 2014 at 11:21 AM, Dave Crocker <[email-masked]> wrote:
> Yup.  It's a singular example, but that's the point.  It's not what the IETF
> (usually) does.
>

There is really no precedent for discovering that a rogue agency was
conspiring to sabotage efforts to provide Internet security.

It is not just the IETF that has ben responding in unusual ways.

For the past thirty years we have been building a technology trap that
civilization now depends on. And anyone who looks into the structure
of that technology trap will realize that all the critical
infrastructure is now linked to the net in ways that can create
enormous amounts of fear and panic albeit with little risk of
catastrophic consequences.

Fear and panic are themselves capable of creating serious
consequences, consider that the response to 9/11 was to start not just
one but two wars.

And now we find that the government agency charged with COMSEC
assurance was actually committing resources to subverting COMSEC
efforts. In many cases efforts that were funded by other parts of the
US government.

This is really not a usual situation at all.

-- 
Website: http://hallambaker.com/

---

From: Hector Santos <[email-masked]>
Date: Mon, 28 Apr 2014 08:25:43 -0400

> I'm just curious: Is anyone on this thread a lawyer?

Murray,

You don't need to be a lawyer to understand one's ethical engineering 
obligations. Generally, it would the product development engineer that 
recognizes ethical design issues and product liability issues and it 
would be him/her that would bring a particular issue with their legal 
council.   There has been similar (mail blocks) court/lawsuits 
precedence for what has been described in this thread.

Keep in mind what DMARC purports to offer.  If someone intentionally 
and neglectfully ignores it knowing full well that it can be used as a 
highly reliable fraud detection mechanism which the domain owner has 
given you full authorization to apply ("reject"), if you don't, well, 
that will put you at risk -- despite local policy overrides. Don't let 
yourself hide behind local policy. It may ultimately excuse you with 
the changes in some laws in the past decade, but it won't eliminate 
you from risk.

---
Hector Santos/CTO
Santronics Software, Inc.
http://www.santronics.com

---

From: S Moonesamy <[email-masked]>
Date: Mon, 28 Apr 2014 07:45:25 -0700

Hi Phillip,
>conspiring to sabotage efforts to provide Internet security.

The IETF have been considering security in its protocols for the last 
11 years.  It has also been considering cryptography for use on the 
Internet.  About a year ago it was found that all does not provide 
the security one would expect.  There hasn't been such a 
precedent.  Perpass is an unusual occurrence.

The comments on the thread describe the IETF environment as "people 
coming together
to work on stuff" whereas people from the outside consider the IETF 
as more than that.  The question which has not been discussed is 
whether the IETF accepts the responsibility for all aspects of its 
protocols.  If the answer to that question is "yes" it would be up to 
the IESG to figure out how to solve the problem(s) in a timely manner.

Regards,
S. Moonesamy

---

From: Dave Crocker <[email-masked]>
Date: Mon, 28 Apr 2014 08:24:28 -0700

On 4/28/2014 7:45 AM, S Moonesamy wrote:
> The IETF have been considering security in its protocols for the last 11
> years.

Picking an historical nit:  More like 20-25 years.

Not sure whether anything pre-dates PEM, but that will do as a start.

d/

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 28 Apr 2014 11:27:52 -0400

S Moonesamy wrote:
> Internet.  About a year ago it was found that all does not provide the 
> security one would expect.  There hasn't been such a precedent.  
> Perpass is an unusual occurrence.
>
> to work on stuff" whereas people from the outside consider the IETF as 
> more than that.  The question which has not been discussed is whether 
> the IETF accepts the responsibility for all aspects of its protocols.  
> If the answer to that question is "yes" it would be up to the IESG to 
> figure out how to solve the problem(s) in a timely manner.

I think it's more accurate to say that the IETF has an "official role" 
as the standards body for Internet protocols - and there may be a 
mismatch between:

- how that role is "officially defined" (such that it is)

- what responsibilities go with such a role (based on expectations and 
experience with analogous environments and standards bodies that have a 
longer history - such as IEEE, ANSI, ISO, ITU, ...)

- how IETF understands and executes its role (and given the somewhat 
bottom-up, ad hoc nature of IETF - how it's organization, policies, and 
operating procedures map onto exercising "official" roles and 
responsibilities"

- what holes there are that might need to be plugged, and how they might 
be plugged

Miles Fidelman

---

From: Christian Huitema <[email-masked]>
Date: Mon, 28 Apr 2014 17:03:44 +0000

>> 11 years.

RFC 1636 was published 20 years ago. From the introduction:

   In summary, the objectives of this workshop were (1) to explore the
   interconnections between security and the rest of the Internet
   architecture, and (2) to develop recommendations for the Internet
   community on future directions with respect to security.  These
   objectives arose from a conviction in the IAB that the two most
   important problem areas for the Internet architecture are scaling and
   security.  While the scaling problems have led to a flood of
   activities on IPng, there has been less effort devoted to security.

Time passes...

-- Christian Huitema

---

From: S Moonesamy <[email-masked]>
Date: Mon, 28 Apr 2014 11:28:15 -0700

Hi Miles,
At 08:27 28-04-2014, Miles Fidelman wrote:
>I think it's more accurate to say that the IETF has an "official 
>role" as the standards body for Internet protocols - and there may 
>be a mismatch between:

I was looking at the matter from an appeals perspective.  I think 
that it might be more effective than discussing about "official role".

>- what responsibilities go with such a role (based on expectations 
>and experience with analogous environments and standards bodies that 
>have a longer history - such as IEEE, ANSI, ISO, ITU, ...)

I'll leave the above questions to people with expertise about these topics.

>bottom-up, ad hoc nature of IETF - how it's organization, policies, 
>and operating procedures map onto exercising "official" roles and 
>responsibilities"

That's an IETF governance question. :-)

>- what holes there are that might need to be plugged, and how they 
>might be plugged

The missing question in the above is "who is going to do the work".

Regards,
S. Moonesamy

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 28 Apr 2014 15:16:22 -0400

S Moonesamy wrote:
>> role" as the standards body for Internet protocols - and there may be 
>> a mismatch between:
>
> I was looking at the matter from an appeals perspective.  I think that 
> it might be more effective than discussing about "official role".
>

Well, that's kind of implied :-)

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Apr 2014 08:53:04 +1200

> that were initiated afterwards.  Then indicate which ones made it to RFC.

It may be more subtle than that. Other possible effects of workshops
include *preventing* work, or diverting work to another SDO. And the
sample size is low - I certainly didn't mean to imply that this is
the major source of IETF innovation. Also, counting drafts and RFCs
doesn't measure value.

Another thing is timescale. Let me give you an example which is not
IAB related. In December 1998 there was an ad hoc workshop on
middleware, reported in RFC 2768 in 2000. It was part of the thread
of activity that led to the Globus toolkit and the Global Grid Forum
(now the Open Grid Forum) and then to this stuff called Cloud Computing.
So for *big* innovations, we're talking about very complex threads of
activity and timescales of more than a decade. Picking apart the
contribution of a single workshop is going to be very hard.

On balance I decline to make an amateur analysis of all this. I think
it needs a much deeper study by someone who is an expert in tracking
the history of technology.

One thing I'm fairly sure of. Some of what the IRTF+IETF does is
R&D, and R&D is allowed to fail. If there's no risk of abject failure,
there's also no chance of great success.

    Brian