Subject: [dmarc-ietf] documenting x-original-from usage

From: Tim Draegen <[email-masked]>
Date: Fri, 3 Oct 2014 12:28:17 -0400

Although a bit forward looking, I've created this page:

  http://trac.tools.ietf.org/wg/dmarc/trac/wiki/XOriginalFrom

..for people to add their smarts of how X-Original-From is being used today.  I haven't fleshed it out with content, please feel free to do so!

This page is being linked from the next milestone's wiki page, fwiw:

  http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki

1/2 of WG Chair,
=- Tim

---

From: Dave Crocker <[email-masked]>
Date: Fri, 03 Oct 2014 09:38:51 -0700

The X-* construct has been deprecated.

It was a worthy experiment, and had an entirely reasonable value
proposition, but it has a significant downside:  If the header field
becomes popular and standardized, the field name has to be changed.
That's a /very/ serious barrier to adoption of the 'standard' form.

So the rule now is:  choose a name that works as a long-term standard,
even when it's initial used privately.

I realize there is already some installed base for x-original-from, but
let's make the change now rather than later.

Along an entirely different line of analysis, note that Original-From is
merely adding complexity to the 'who was the author of this message'
assessment, very possibly creating yet-another security hole.

d/

On 10/3/2014 9:28 AM, Tim Draegen wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
> 
> 

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Tim Draegen <[email-masked]>
Date: Fri, 3 Oct 2014 12:43:30 -0400

> The X-* construct has been deprecated.

Yes.  Let's collect everything around what people have been using "X-Original-From:" for as a starting point.  The application of this header in different contexts brushes up against what the WG is trying to address.

=- Tim

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 04 Oct 2014 12:41:53 +0900

> assessment, very possibly creating yet-another security hole.

Messrs Chairguys,

Inquiring Minds Question a Point of Order: doesn't this kind of
comment belong on the wiki page, now that it's been created?

Feeling-guilty-about-own-too-long-threads-so-really-wanna-know-ly y'rs,

Steve

---

From: Tim Draegen <[email-masked]>
Date: Tue, 7 Oct 2014 17:23:05 -0400

> Feeling-guilty-about-own-too-long-threads-so-really-wanna-know-ly y'rs,

Yes, it does.  I've added it to the wiki, 'cause it would have taken longer to ask Dave to do it.

WORDS OF ENCOURAGEMENT FOR THIS WG:

Everybody should feel free to add to the wiki.  If a long discussion thread doesn't end up creating wiki content for newcomers, whatever nuggets of wisdom are shared will remain buried.  IMO that's no good, 'cause there is deep and varied expertise in this WG already, but it's very difficult to get at it (and therefore for a newcomer to figure out where their own expertise fits in).

=- Tim

---

From: Dave Crocker <[email-masked]>
Date: Tue, 07 Oct 2014 14:38:31 -0700

On 10/7/2014 2:23 PM, Tim Draegen wrote:
> 'cause it would have taken longer to ask Dave to do it

minutes vs. infinity, most probably.  so yeah and thanks.

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 08 Oct 2014 10:42:33 -0700

> Everybody should feel free to add to the wiki.  If a long discussion thread doesn't end up creating wiki content for newcomers, whatever nuggets of wisdom are shared will remain buried.  IMO that's…

Hmmm...

I find myself unclear about whether the wiki is intended to be an
alternative to posting one's thoughts, in which case how with the wg see
them?

I'd expect the wiki to be a place to capture thoughts/issues/decisions
after they've been discussed to some level of stability -- note that
stability doesn't require actual resolution.

With respect to adding Origina-From, I don't see it at:

   http://wiki.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki

and don't know where else to look for it...

d/

---

From: Tim Draegen <[email-masked]>
Date: Wed, 8 Oct 2014 15:17:10 -0400

> stability doesn't require actual resolution.

You've got it.  Capturing tidbits from the list discussion using the wiki is it.  There's not a lot of wiki modification going on, which is why I'm pointing folks at it.

> and don't know where else to look for it...

It's linked off of http://wiki.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki
This is the "Milestone 2" wiki, as the topic appeared to be about how people are using
headers to convey information to determine "real source".  A bit ahead of the WG's focus.

-= Tim

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 08 Oct 2014 15:20:28 -0400

On Wednesday, October 08, 2014 15:17:10 Tim Draegen wrote:
> You've got it.  Capturing tidbits from the list discussion using the wiki is
> it.  There's not a lot of wiki modification going on, which is why I'm
> pointing folks at it.
> It's linked off of
> http://wiki.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki This is the
> "Milestone 2" wiki, as the topic appeared to be about how people are using

We have one?

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Wed, 08 Oct 2014 12:26:45 -0700

> It's linked off of http://wiki.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneTwoWiki

ack. tnx.

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 08 Oct 2014 12:32:29 -0700

>> and don't know where else to look for it...

fwiw, I just added links on the dmarc wiki homepage to pages for all 3
milestones and added mnemoic labels to the phase numbers.

d/

---

From: Tim Draegen <[email-masked]>
Date: Wed, 8 Oct 2014 15:34:21 -0400

On Oct 8, 2014, at 3:20 PM, Scott Kitterman <[email-masked]> wrote:
>> A bit ahead of the WG's focus.
> 
> We have one?

Ha!  The WG is supposed to be focused on collecting all known issues between DMARC and indirect email flows.  Based on the collected set of issues, we'll then switch gears and argue the heck out of possible solutions.

=- Tim

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 8 Oct 2014 19:44:50 +0000

> -----Original Message-----
> From: dmarc [mailto:[email-masked]] On Behalf Of Tim Draegen
> Sent: Wednesday, October 08, 2014 3:34 PM
> To: Scott Kitterman
> Cc: [email-masked]
> Subject: Re: [dmarc-ietf] wiki vs. list? (was Re: documenting x-original-from
> usage)
> 
> Ha!  The WG is supposed to be focused on collecting all known issues
> between DMARC and indirect email flows.  Based on the collected set of
> issues, we'll then switch gears and argue the heck out of possible solutions.
> 

To that point, everyone seems focused on MLMs. I was looking at data for DMARC pass/fail rates for IPs/hosts other than our own and was struck by the variability of the rates across various domains. Excluding "known bad actors", DMARC pass rates ranged from low 60-something percent up to mid-90 something percent. Such a large range is interesting. Because (aligned) SPF should almost always fail, the implication is that there are potentially better and worse ways to maintain the integrity of the DKIM signature in transit. Just a reminder, the mailstreams I'm looking at are transactional and overwhelmingly do not include traffic transiting mailing lists.

Mike

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 09 Oct 2014 14:44:56 +0900

MH Michael Hammer (5304) writes:

 > To that point, everyone seems focused on MLMs.

Sure, and that's unfortunate.  I discuss MLMs because that's what I
do, and that's what I know.

 > I was looking at data for DMARC pass/fail rates for IPs/hosts other
 > than our own and was struck by the variability of the rates across
 > various domains. Excluding "known bad actors",

By "bad actors", do you mean spammers and other miscreants, or do you
mean 3rd party filtering services that append ads to the message body
and other incompetents?

 > DMARC pass rates ranged from low 60-something percent up to mid-90
 > something percent. Such a large range is interesting. Because
 > (aligned) SPF should almost always fail, the implication is that
 > there are potentially better and worse ways to maintain the
 > integrity of the DKIM signature in transit. Just a reminder, the
 > mailstreams I'm looking at are transactional and overwhelmingly do
 > not include traffic transiting mailing lists.

I guess the obvious questions are "why are they transiting other
hosts, then?" (eg, secondary MX provided by a third party should not
break DKIM signatures), and "can you see anything about the
mailstreams themselves that is different across mailstreams?"

And then, can you ask those transited hosts what they're doing that
might break DKIM?

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Thu, 9 Oct 2014 12:44:32 +0000

> From: Stephen J. Turnbull [mailto:[email-masked]]
> Sent: Thursday, October 09, 2014 1:45 AM
> To: MH Michael Hammer (5304)
> Cc: [email-masked]
> Subject: Re: [dmarc-ietf] wiki vs. list?
> 
> Sure, and that's unfortunate.  I discuss MLMs because that's what I do, and
> that's what I know.
> 
>  > I was looking at data for DMARC pass/fail rates for IPs/hosts other  > than
> our own and was struck by the variability of the rates across  > various
> domains. Excluding "known bad actors",
> 
> mean 3rd party filtering services that append ads to the message body and
> other incompetents?
> 

By bad actors I mean spammers, phishers and other miscreants. I determine this by looking at the headers and (message body) URLs that I get through feedback loops in addition to whether the message was DKIM signed at all. I'm not overly concerned about 3rd party filtering services that append ads to the message body before DKIM is validated. That falls into the category of incompetents as you rightly point out. As an aside, I did notice one message that the receiving validator apparently did 2 SPF checks on (this is mail direct from our MTA to them) - the first one passed but the second one failed because they were attempting to validate (aligned) SPF in a DMARC context for our domain against their IP - DOH! 

>  > DMARC pass rates ranged from low 60-something percent up to mid-90  >
> something percent. Such a large range is interesting. Because  > (aligned) SPF
> should almost always fail, the implication is that  > there are potentially
> better and worse ways to maintain the  > integrity of the DKIM signature in
> transit. Just a reminder, the  > mailstreams I'm looking at are transactional
> and overwhelmingly do  > not include traffic transiting mailing lists.
> 
> I guess the obvious questions are "why are they transiting other hosts,
> then?" (eg, secondary MX provided by a third party should not break DKIM
> signatures), and "can you see anything about the mailstreams themselves
> that is different across mailstreams?"
> 

My hunch is that much of it is somehow related to forwarding by end users to other accounts they control (consolidation of mail in one place?) That is just a guess though. I may reach out to a couple of mailbox providers to see if we can figure out the details of what is happening. I would assume that providers at the low of the range would want to improve performance in terms of less rejected mail. On the other hand, from my perspective, the numbers of mail involved for our mail streams are relatively small so it is more curiosity on my part than a significant problem.

> And then, can you ask those transited hosts what they're doing that might
> break DKIM?

As a first step I'd be interested in knowing if anyone else is seeing similar variations for transactional mail streams that one would not expect to be going through mailing lists. That is, is this a significant enough community problem that we should be collectively spending time on it?

Mike

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 09 Oct 2014 23:28:41 +0200

> Ha!  The WG is supposed to be focused on collecting all known issues between DMARC and indirect email flows.  Based on the collected set of issues, we'll then switch gears and argue the heck out of…

FYI, I added some information about Sieve 'redirect', 'addheader', 
'deleteheader' and 'replace' actions to the Wiki.

A more general comment: reading the wiki and the discussions on this 
list, it get the impression that we seem to focus more on the issues 
related to the 'DKIM part of DMARC' then on issues related to the 'SPF 
part of DMARC'. Is my observation correct, do we tend to forget SPF here?

/rolf

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 10 Oct 2014 00:00:14 -0400

> part of DMARC'. Is my observation correct, do we tend to forget SPF here?

Possible, but also we (in SPFbis) just finished up RFC 7208 and it goes into a 
lot of detail about ways SPF can fail and what can be done about it.  I don't 
think there's a lot of fertile ground to plow.  If someone has the 
time/motivation, it might be useful to see what of the SPF failure mitigations 
cause problems with DMARC alignment (as an example, SRS will allow the mail 
from to be changed when a message is forwarded, so the forwarder's SPF can be 
used, but the doesn't preserve DMARC alignment).

Scott K

---

From: "John Levine" <[email-masked]>
Date: 10 Oct 2014 04:12:09 -0000

>part of DMARC'. Is my observation correct, do we tend to forget SPF here?

I agree with Scott, there's not much to say about it.  If you forward
or remail a message, the origin IP changes, and there's nothing you
can do about it.

Perhaps we can note that in theory the original sender could add
mailing list IPs to its own SPF, but I never heard of anyone doing
that.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 10 Oct 2014 11:13:12 +0200

> or remail a message, the origin IP changes, and there's nothing you

+1 if we are focusing on indirect flows, SPF is out of the game.

> mailing list IPs to its own SPF, but I never heard of anyone doing

I don't think that solution can be recommended, because of the
guesswork implied in adding addresses in bulk.  For example, the
advice given in the first bullet of Appendix D.1[1] gives a "neutral"
result, which is good for local SPF policies but not for DMARC.

Ale

[1] http://tools.ietf.org/html/rfc7208#appendix-D.1

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 10 Oct 2014 12:29:13 +0000

> From: dmarc [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Friday, October 10, 2014 12:12 AM
> To: [email-masked]
> Cc: [email-masked]
> I agree with Scott, there's not much to say about it.  If you forward or remail a
> message, the origin IP changes, and there's nothing you can do about it.
> 
> Perhaps we can note that in theory the original sender could add mailing list
> IPs to its own SPF, but I never heard of anyone doing that.
> 

An issue that I have been thinking on - and it is the reverse of this discussion - is that it is operationally difficult to maintain accurate SPF records for organizations with a lot of domains where the SPF records vary across the domains. I recently found this situation with one of our domains (an acquisition). This is similar to other situations where organizations are fairly good with adds and changes but not so much with deletes. This isn't anything that can be addressed through an RFC but I think it is worth noting.

Mike

---

From: [email-masked]
Date: Fri, 10 Oct 2014 08:07:20 -0700 (PDT)

> An issue that I have been thinking on - and it is the reverse of this
> discussion - is that it is operationally difficult to maintain accurate SPF
> records for organizations with a lot of domains where the SPF records vary
> across the domains. I recently found this situation with one of our domains (an
> acquisition). This is similar to other situations where organizations are
> fairly good with adds and changes but not so much with deletes. This isn't
> anything that can be addressed through an RFC but I think it is worth noting.

<chair hat off>

This looks to me to be an operational issue with deploying SPF at scale. This
WG"s charter is pretty specific that we're focusing on issues caused by "mail
that does not flow from operators having a relationship with the domain owner,
directly to receivers operating the destination mailbox". I don't see how this
fits within that scope.

So, while I'm sympathetic to the difficulties using SPF in this way,
I don't think it's in scope for the present effort.

				Ned

---

From: Brett McDowell <[email-masked]>
Date: Wed, 15 Oct 2014 10:30:38 -0400

(note: this is my first post to [email-masked] but I participated in the original creation of DMARC and I look forward to participating in this WG)

>> anything that can be addressed through an RFC but I think it is worth noting.

I was surprised to see you take your chair hat off when responding to a discussion of scope.  Being still fairly green when it comes to IETF process I’m not sure about this, but I would have presumed one role of the chair is to help ensure the WG stays within its approved scope.  I’m asking about this because I believe managing scope is critically important to the success of this WG and I’d like to know who plays what role in helping us stay on track.  Thank you.

> I don't think it's in scope for the present effort.

The charter also states the WG "will also provide technical implementation guidance and review possible enhancements elsewhere in the mail handling sequence that could improve DMARC compatibility.”  While I’m personally not too concerned about deploying SPF at scale, I am concerned about this particular aspect of the charter and preserving it.  If we forget this aspect of our charter then we are left with nothing in our toolbox but to change DMARC itself to accommodate MLM’s and other "mail that does not flow from operators having a relationship with the domain owner, directly to receivers operating the destination mailbox” with no ability to at least “guide” other processors toward practices that would help them improve their compatibility with DMARC.

-Brett

---

From: [email-masked]
Date: Fri, 17 Oct 2014 11:09:37 -0700 (PDT)

> I was surprised to see you take your chair hat off when responding to a
> discussion of scope.  Being still fairly green when it comes to IETF process
> I’m not sure about this, but I would have presumed one role of the chair is to
> help ensure the WG stays within its approved scope.

Your presumption is correct.

> I’m asking about thi because I believe managing scope is critically
> important to the success of this WG and I’d like to know who plays what 
> role in helping us stay on track. Thank you.

That would be the chairs.

> The charter also states the WG "will also provide technical implementation
> guidance and review possible enhancements elsewhere in the mail handling
> sequence that could improve DMARC compatibility.”  While I’m personally not too
> concerned about deploying SPF at scale, I am concerned about this particular
> aspect of the charter and preserving it.  If we forget this aspect of our
> charter then we are left with nothing in our toolbox but to change DMARC itself
> to accommodate MLM’s and other "mail that does not flow from operators having a
> relationship with the domain owner, directly to receivers operating the
> destination mailbox” with no ability to at least “guide” other processors
> toward practices that would help them improve their compatibility with DMARC.

So let me see if I understand you correctly. You were surprised that I posted
a query (not an assertion) about something being in scope in my capacity
as a WG participant rather than as chair. And you are concerned that
there be effective scope management.

But at the same time you're concerned that we not tighten the scope so much as
to exclude implmentation guidance that you view as an important tool in
addressing DMARC issues.

If that's correct, then I confess I completely fail to understand your
concern/point here. The reason I posted as a participant and not as chair was
precisely because I *didn't* want to make an ex cathedra statement about the
appropriateness of discussing this SPF issue.

What I wanted was feedback as to whether or not people consider SPF deployment
advice on this issue to be in scope of the WG. I received one private response
to that agreeing that it isn't in scope and notihng on the list. And since
public discussion of that point has ceased, further consideration of the matter
seems moot.

Finally, in regards to the implementation advice aspect of our work, and again
speaking as a participant, I don't see how this particular issue meets the
criteria for that either since it has everything to do with not sending out
bogus SPF information and nothing to with with the interaction of SPF with
DMARC.

				Ned

---

From: Brett McDowell <[email-masked]>
Date: Sat, 18 Oct 2014 13:06:06 -0400

> On Oct 17, 2014, at 2:09 PM, Ned Freed <[email-masked]> wrote:
> 

Correct.

> to exclude implmentation guidance that you view as an important tool in

Correct, and I believe that is consistent with my concern that there be effective scope management.

> concern/point here.

That is probably because the topic at hand was SPF.  To clarify, I was not trying to weigh-in on SPF at all.  I was raising an orthogonal issue, motivated by how the SPF topic was being discussed vis-a-vis scope and charter, but entirely unrelated to SPF.  

> The reason I posted as a participant and not as chair was

I appreciate your approach.  I was seeking clarity.  I was not trying to insinuate that you should not have commented as a participant.  I just wanted to be sure I understood who was helping us manage scope effectively and you clarified that.  It’s all good.  Just chalk this up to me being new to this WG.

---

From: Hector Santos <[email-masked]>
Date: Thu, 23 Oct 2014 14:04:56 -0400

I'm already lost of whats going on. It seems we are waiting of Murray. 
Its all Murray. Geez, Its all really Murray's framework to all this. 
Not a negative, but there has to be more.  There is more. There has 
always been more, that is why we are lost here after 9 years.

We need policy and we are wasting so much time not establishing how 
DMARC has brought back the importance of a DKIM Policy Framework back 
into the picture as it always was the case but became unfocused with a 
3rd party trust framework, which btw breaks down when no signature is 
valid, i.e. no valid SDID (Signer Identity)  The 1st party author 
party provides the best pure anchoring information on whats to be 
expected .

If we wish to include 1st party authorization for a list path and/or 
SPF path, it all needs to be discussed.  We always know that DMARC 
always fails on a SPF failure as well.

    DMARC =  DKIM + SPF

So any failure on DKIM or SPF is part of a DKIM failure.  If that is 
not TRUE, then it needs to be part of the discussion.  A SPF failure 
fails DMARC despite how verifiable the DKIM layer is.

--
HLS

On 10/17/2014 2:09 PM, [email-masked] wrote:
>> I�m not sure about this, but I would have presumed one role of the chair is to
>> I�m asking about thi because I believe managing scope is critically
>> important to the success of this WG and I�d like to know who plays what
>> sequence that could improve DMARC compatibility.�  While I�m personally not too
>> to accommodate MLM�s and other "mail that does not flow from operators having a
>> destination mailbox� with no ability to at least �guide� other processors

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 23 Oct 2014 15:14:02 -0700

On Thu, Oct 23, 2014 at 11:04 AM, Hector Santos <[email-masked]> wrote:

> I'm already lost of whats going on. It seems we are waiting of Murray. Its
> all Murray. Geez, Its all really Murray's framework to all this. Not a
> negative, but there has to be more.  There is more. There has always been
> more, that is why we are lost here after 9 years.
>

Sorry, but I have no idea what this is about.  The only thing I think
anyone's waiting on me for is a revision to draft-kucherawy-dmarc-base for
publication as an RFC through the ISE.  It will contain no technical
changes, so either way, this WG shouldn't be blocked waiting on me for
anything.

Confused,
-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 24 Oct 2014 07:50:10 +0900

> changes, so either way, this WG shouldn't be blocked waiting on me for

+1.  I don't think it's blocked on Murray; I certainly am not waiting
on Murray (or anybody else) for anything.  I just don't have time to
do much more than I already have done, nor any pressing new ideas that
make it worth sacrificing other work to get them out in front of
people immediately.

As for the "there is more", I don't agree with your position on Domain
Owner control of all uses of mailboxes.  As I see it, most Domains
where the mailboxes are primarily for transactional mail flows already
have that control and enforce it externally to Internet standards, and
p=reject works fine for them.  Domains where the mailboxes are used by
individuals for personal use don't have the control and can't exercise
it, and another Internet standard won't help -- it will be honored
more in the breach than the observance just as Yahoo!'s "p=reject" is
already.

I gather that most WG participants are closer to my position than to
yours, which is why no progress is being made in the direction you
think best.  You're going to have to stop asserting your position, and
start persuading others of its correctness, if you want to move
discussion in that direction.

Regards,
Steve

---

From: Douglas Otis <[email-masked]>
Date: Thu, 23 Oct 2014 16:16:06 -0700

Dear Hector and Murray,

Those in a good position to deal with an abuse problem don't want resulting disruptions seen as being within their bailiwick.  Instead expect documentation explaining why it is not affordable for DMARC domains to directly deal with their policy induced disruptions of legitimate email, such as discussion forums and other third-party services employed by their users.  Without taking ownership, results of this WG efforts seem at best modest changes in the nature of abuse while disrupting many valuable and legitimate email services.  There is a genuine scaling concern when suggested solutions expect millions of users to "vote with their feet".  Without taking greater ownership as permitted by schemes like TPA-Label, or allowing valid and compatible exceptions such as a permitted and conditional group syntax policy exclusion, is there another reasonable strategy to be moved forward?

I'll be the first to say expanding on SPF authorized address list won't work, but related limitations can be avoided with a cacheable domain hash list.  This approach would be more proactive at curtailing abuse and we would like to help large ISPs prove the feasibility of this strategy.  Then again, perhaps a rewriting scheme would be able to safely deal with From domain conflicts without use of a broken alias scheme such as  *.invalid.  In that light, a group syntax scheme seems much less problematic.  How does the base document currently deal with this valid form of email?

Regards,
Douglas Otis

On Oct 23, 2014, at 3:14 PM, Murray S. Kucherawy <[email-masked]> wrote:

> I'm already lost of whats going on. It seems we are waiting of Murray. Its all Murray. Geez, Its all really Murray's framework to all this. Not a negative, but there has to be more.  There is more. There has always been more, that is why we are lost here after 9 years.
> 
> Sorry, but I have no idea what this is about.  The only thing I think anyone's waiting on me for is a revision to draft-kucherawy-dmarc-base for publication as an RFC through the ISE.  It will contain no technical changes, so either way, this WG shouldn't be blocked waiting on me for anything.
> 
> Confused,
> -MSK

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Oct 2014 08:19:32 -0400

Stephen,

This is not about you and me. POLICY has been reestablished as the 
DKIM framework long ago. It just had taking a white before its impact 
was felt. Things were neglected and we are here today to finally try 
to resolve the issues for LIST operators.

But DKIM DOMAIN POLICY is HERE.  No need to prove that anymore. 
Doug's TPA proposal is now officially part of the charter.  I wanted 
Murray's simpler version of the solution for the 3rd party extension. 
  TPA is actually very simple, the spec is complex. So if that is 
where we go, we go.

But until them are we wasting time?  Yes, I think so.

Thanks and have a great day.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Oct 2014 10:07:58 -0400

> Those in a good position to deal with an abuse problem don't want resulting disruptions seen as being within their bailiwick.  Instead expect documentation explaining why it is not affordable for D…

All I am saying it needs to be part of the protocol framework so that 
implementators provide it as operational choice to admins, sysops and 
list operators who are looking and waiting for these software changes 
to take place.  Otherwise most of them are clueness about what's going 
on.

First, its complex. To the layman, its either ON and OFF and if ON, 
automated to the point where there is minimal false positives. I 
prefer ZERO false positive because it  minimizes the support cost for 
our small low overhead software company.  But on occasion, an operator 
will find a frustrating reason to the turn off the "out of the box" 
AVS feattures. Some do only to find there spam problem is worst, so it 
goes back on. But for most, along with an advanced Greylisting system, 
Callback Verifiers, etc, for nearly 10 years now, with very little 
negative impact, its all on auto-pilot.

Of course,  if I was to add DMARC by replacing or adding it to the 
current ADSP+ATPS+ASL framework, I will immediately have to consider 
this stupid rewrite thing. But thats it, consider it, no way I will 
help contribute to opening Pandora's box here. If I do, only to give 
the 3rd party developers an API way to script it themselves. But not 
built-in, out of the box, for operators.  Too problematic and I have a 
strong feeling it goes to bite people here in the future.  I advise 
the younger mail engineers to reconsider the product design ethical 
choices being made here.

> I'll be the first to say expanding on SPF authorized address list won't work, but related limitations can be avoided with a cacheable domain hash list.  This approach would be more proactive at cur…

Consideration of rewriting MUST come with the Authorizing Domain 
Expectation and Authorization to do so or if the policy is relax or 
non-existing, the default, it would implicitly allow for any operation 
to take place on its domain, i.e no strong controls.

Its going to be a very complex change and for more complex than just 
having a "database" of authorized list.  That is simpler, i.e. create 
a database for simple queries.  Today, we currently lean towards doing 
this with DNS with TXT based DNS Applications. But there is no reason 
why it can't be an other socket port protocol, UDP/TCP, whatever, if 
its more optimal to do so.  Whatever, it can be done.  Our small 
company did it.  Any big company it can handle it too.  But DNS is 
fine too.

Is this a BIG DATA problem?

I am suppose to believe that the "Yahoo's" don't have the engineering 
to explore if they can't handle the high potential of 30,000 list to 
authorized?   Its going to take a while for them to even collect them. 
I bet its very limited, 500? 1000? Maybe just 40. Whatever. Its doable 
folks, the software dudes at these "BIG" companies are not exploring 
enough.  The Project R&D was done!!  Where is the Product R&D?

Have a great day guys.

-- 
HLS

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 25 Oct 2014 06:17:05 +0900

Hector Santos writes:

 > POLICY has been reestablished as the DKIM framework long ago.

I have no clue what this sentence means.  What is "POLICY"?  What is
"the DKIM framework"?

 > Things were neglected and we are here today to finally try to
 > resolve the issues for LIST operators.

As I see it, no, we're not.  The issues go beyond mailing lists, and
since the lists and other affected indirect mailers do not themselves
participate in these protocols, talking about the list operators is
moot.  It's somebody else who has to "do something", and what is here
today is destinations which are interpreting Author Domain DMARC
policy to suit themselves and their users.

 > But until them are we wasting time?  Yes, I think so.

Let me rephrase what I wrote before:

    Most WG participants seem to be closer to the position that
    currently available proposals are unlikely to solve the indirect
    mail problems, and are unlikely to achieve widespread adoption by
    Author Domains just because they get standardized here or in other
    venues.  The proposals themselves (TPA, John Levine's delegation
    scheme, Dave Crocker and Murray Kucherawy's delegation scheme,
    others?) have been developed and will contine to be discussed and
    improved here and in other channels, but they don't seem to be
    anything like a general solution, and most WG participants seem to
    be of the opinion that clarifying and documenting the issues and
    their relation to proposed solutions is not a waste of time.

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Oct 2014 21:38:02 -0400

On 10/24/2014 5:17 PM, Stephen J. Turnbull wrote:
> I have no clue what this sentence means.  What is "POLICY"?

DMARC rev 4 spec has 184 global search references to the term POLICY. 
DKIM has a 9 year history regarding a POLICY framework.

> What is "the DKIM framework"?

Framework is a well understand term, Stephen.

>      venues.

DMARC is a DKIM Policy Framework. According the marketing, it has gain 
widespread adoption especially among your list users domains.  Isn't 
why you are here, to stop it?

>The proposals themselves (TPA, John Levine's delegation

Great,  then since you have purport to have a "consensus," with "most 
WG participants," you should be able to get something done pretty quickly.

Thanks for your comments.

-- 
HLS

---

From: "J. Gomez" <[email-masked]>
Date: Sat, 25 Oct 2014 18:34:55 +0200

> why you are here, to stop it?

If by "widespread adoption" you mean that major mailbox providers (Gmail and others) are ignoring the Sender's DMARC policy (Yahoo, AOL and others), then yes: DMARC defines a DKIM policy which has widespread adoption.

Regards,

J. Gomez

---

From: Dave Crocker <[email-masked]>
Date: Sat, 25 Oct 2014 12:57:47 -0400

> If by "widespread adoption" you mean that major mailbox providers (Gmail and others) are ignoring the Sender's DMARC policy (Yahoo, AOL and others), then yes: DMARC defines a DKIM policy which has…

DMARC defines DMARC-related 'policies'.

It does not affect DKIM in any way.  It is an overlay to DKIM and/or SPF
use.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 26 Oct 2014 07:10:31 -0700

> I have no clue what this sentence means.  What is "POLICY"?  What is

For any definition of "the DKIM framework", the claim is incorrect.  DKIM
has never had policy inherent within it since it was published.  ADSP and
ATPS are failed experiments to add some.

>     their relation to proposed solutions is not a waste of time.

I don't think we've finished hashing on these, so some solution may rise
from their collective ashes.  I do agree though that none of them seem to
have enough favor here at this point to be a clear winner, all for good
reasons.  If such a possible solution does exist, we still have to put more
work into finding, testing, and describing it.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 26 Oct 2014 07:11:24 -0700

On Sat, Oct 25, 2014 at 9:57 AM, Dave Crocker <[email-masked]> wrote:

> > If by "widespread adoption" you mean that major mailbox providers (Gmail
> and others) are ignoring the Sender's DMARC policy (Yahoo, AOL and others),
> then yes: DMARC defines a DKIM policy which has widespread adoption.
>

Yes, this.  +1, etc.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Sun, 26 Oct 2014 11:08:59 -0400

> ATPS are failed experiments to add some.

This is MY VIEW as an external long time participant with early 
explorer SPF/DKIM add-on products in our mail system.  Nothing 
personal nor negative intended, especially towards you, but you are in 
fact the "leader" and in charge of this work.

DKIM had its origins from Domainkeys (DKEYS) which had a built-in 
POLICY framework Murry. DKIM, when it was first released, also carried 
over the built-in policy framework and it public domain APIs with API 
functions "hooks" for POLICY logic. DKIM had an expanded set above and 
beyond what DKEYS offered.  For the most part, the specs and API 
reduced the functional logic to:

    IF DKIM.VALID and DKIM.SIGNER.DOMAIN != FROM.DOMAIN then
      LOOKUP AUTHOR POLICY FOR EXCLUSIVE/RESTRICTIVE OPERATIONS

Thats no claim. Thats a public domain API fact with original API 
libraries for DKEYS and DKIM.  It is an historical, public domain fact 
and there shouldn't any debate about its origins nor how it been 
reestablished with your new published draft DMARC work.  The concept 
of policy is peppered all over the document. There should be no 
dispute DMARC is a "DKIM Policy Framework" or "DKIM Policy Protocol" 
or "DKIM Policy Specification" or "DKIM Policy Layout" whatever other 
terminology we wish to use.

DKIM had two frameworks -- a POLICY and TRUST and there lied the long 
time problem and continued conflict when in fact, DMARC itself is 
about POLICY and DKIM STD is about TRUST.  When Policy was removed 
from the DKIM RFC/STD work and replaced with TRUST. Folks were warned 
of the mistake to inherently exclude the Author Domain Identity (ADID) 
from the assessment algorithm (remember that discussion?) and we are 
here today because it was left out, trying to reestablishing it via 
DMARC.

Finally, Its easy to dispute ADSP/ATPS as "failed experiments" by the 
fact it wasn't giving a chance at all.  In other words, the effort 
didn't have the proper both project/product development champions and 
the fact that DMARC is being adopted and now discussed, proves the 
Proof of Concept (Policy in principle) had never gone away and it is 
still alive and well.   It won't go away either as it should finally 
realized by now. Call it any name we want -- it is a DKIM POLICY 
framework and we should save time by recognizing this fact and develop 
the proper tools to allow the world to adjust to it.

Its unfortunate the DKIM progress for both an integrated TRUST and 
POLICY framework has been held back for some time now.  Policy was 
always the first layer (expectation), TRUST was always the second 
layer (valid signature true).  But DKIM project leaders pushed for 
TRUST only which the POLICY advocated warned that was going to be a 
problem in the future -- and it did, hasn't it?  But ignoring POLICY, 
we weren't ready for it.  I should note, that DMARC repeated what 
Levine did with ADSP -- ignore all 3rd party control concepts in an 
attempt to reduce conflicts with 3rd party resigners.  I think it 
should be determine asap if 3rd party policy ideas are in fact going 
to be developed for DMARC, and by that, I mean, you PUSH IT, You 
CHAMPION IT.  Otherwise it ain't going anywhere for awhile.

It shouldn't had never been a difficult total TRUST/POLICY integrated 
product solution and since the same folks are behind it, well, its 
progress seems to be in a status quo direction for its future.

Not a negative towards you, you are doing good work for all the work 
you do. But it does seem to be too much and overwhelming.  You need 
help. No doubt. But thats also a management problem. So, I'll leave it 
at that.

I really hope you guys moving with this.

--
HLS

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 27 Oct 2014 20:23:11 +0100

On Saturday, October 25, 2014 5:57 PM [GMT+1=CET], Dave Crocker wrote:

> > > DMARC is a DKIM Policy Framework. According the marketing, it has
> > > gain widespread adoption especially among your list users
> > > domains.  Isn't why you are here, to stop it?
> > 
> > If by "widespread adoption" you mean that major mailbox providers
> > (Gmail and others) are ignoring the Sender's DMARC policy (Yahoo,
> > AOL and others), then yes: DMARC defines a DKIM policy which has
> > widespread adoption.   
> 
> It does not affect DKIM in any way.  It is an overlay to DKIM and/or
> SPF use.

DMARC defines DMARC-related 'policies' which are an overlay on DKIM, which to me could be also aptly phrased as "DMARC creates a policy framework for DKIM", and more succintly "DMARC is a DKIM Policy Framework".

Yes, DMARC does not change DKIM de-iure. But also, yes, DMARC does bring POLICY to DKIM.

The truth here is that DMARC is going to be a de-facto DKIM 2.0. And when I say "de-facto", I mean in production systems, on the trenches, in the muddy world of reality where support costs do exist and ivory towers are far in the distance and rest high away from all the mudd.

Regards,

J. Gomez

---

From: Dave Crocker <[email-masked]>
Date: Mon, 27 Oct 2014 13:58:50 -0700

On 10/27/2014 12:23 PM, J. Gomez wrote:
>> It does not affect DKIM in any way.  It is an overlay to DKIM
>> and/or SPF use.
> 
> DMARC defines DMARC-related 'policies' which are an overlay on DKIM,
> which to me could be also aptly phrased as "DMARC creates a policy
> framework for DKIM", and more succintly "DMARC is a DKIM Policy
> Framework".
> 

No it does not.

The relationship between DMARC and DKIM (and SPF) is like the
relationship between TCP and IP.  TCP does not 'bring reliability and
congestion control to IP'.  Rather, TCP /uses/ IP as a transfer
component to the TCP reliability and congestion control framework that
TCP creates.

DMARC creates an authorization framework for the rfc5322.From (author)
field.  It uses DKIM and SPF for some authentication components to the
DMARC framework.

This is a fundamentally different relationship than what you are
asserting.  Your statement confuses roles and relationships.

> The truth here is that DMARC is going to be a de-facto DKIM 2.0. And

Nope.

d/

---

From: Brett McDowell <[email-masked]>
Date: Mon, 27 Oct 2014 17:16:27 -0400

I’m not sure what the relevance of this particular debate is, but in hopes of moving us forward, I offer another data point.

Please remember that you can deploy DMARC and get exactly the desired result from your DMARC deployment, without deploying any DKIM infrastructure.  Example: you can push a p=reject on a domain that never sends mail.  You can push any p= value for a domain that is only “protected” by SPF records, even one that is in use, and get exactly the desired result.  DKIM is of course required to achieve the desired result for most mail flows, but DKIM it is not in any way required for all successful deployments of DMARC.

Given that fact, perhaps we can stop debating whether or not DMARC is a DKIM Policy Framework.  But what was the point of that debate in the first place?  If we all agreed that DMARC was a DKIM Policy Framework, what outcome would that have brought us closer to?  I suspect there was a purpose for that argument that might still be relevant to our work even though the argument doesn’t seem to be supported, but I’m not seeing it yet.

-Brett

> On Oct 27, 2014, at 4:58 PM, Dave Crocker <[email-masked]> wrote:
>

---

From: Douglas Otis <[email-masked]>
Date: Mon, 27 Oct 2014 14:49:21 -0700

> Given that fact, perhaps we can stop debating whether or not DMARC is a DKIM Policy Framework.  But what was the point of that debate in the first place?  If we all agreed that DMARC was a DKIM Pol…

Dear Brett,

DMARC/SPF hinders third-party services to a greater extent, since DKIM still permits messages that lack modification and SPF does not.  A DMARC policy of p=reject against user email accounts will not obtain desired results when third-party services are utilized.  This problem can be transparently repaired through the use of TPA-Label at any scale, or eventually through adoption of an excluded but obvious group syntax.  An excluded group syntax would not be as secure as TPA-Label, since use of group syntax depends on cautious recipients.  There are still many cases where email includes malicious active-content acted upon by MUAs where users prove themselves easily intrigued, even to the point of opening messages in their spam folder (where growing amounts of legitimate email is being found largely because of downgraded DMARC policy).

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Tue, 28 Oct 2014 15:22:30 -0400

> Please remember that you can deploy DMARC and get exactly the desired result from your DMARC deployment, without deploying any DKIM infrastructure.  Example: you can push a p=reject on a domain tha…

This was always possible with all DKIM Policy Framework proposals 
since 2003 -- you can piggy back of the idea that receivers would be 
checking for specific exclusive operations.  This is in fact, the 
highest benefit one can receive with any of the Domain Policy 
Protocols where the "expectation" bar has risen beyond the standard 
expectation and the highly abused legacy operation.

> Given that fact, perhaps we can stop debating whether or not DMARC is a DKIM Policy Framework.  But what was the point of that debate in the first place?

Probably because there has been resistant to the idea of a "lookup." 
In addition, the term "Policy" has been swapped around with the idea 
of an operational "practice" in place.  So its the practice|policy of 
a domain to expect mail to have certain attributes, i.e. be sign or 
not sign, no mail at all, or allow a 3rd party to sign, etcs.   Whats 
lacking in DMARC are 3rd party policies and the point I wish to stress 
is that we are not going to resolve this issue until that is 
recognized.   We had too much resistance by the 3rd party MLM market 
to allow the 1st party to dictate what is valid or not.  See RFC5016 
and how it makes this a MLM market protection, replace SSP with DMARC 
and we have:

    Section 5.3, item 10

    10. DMARC MUST NOT provide a mechanism that impugns the existence of
        non-first party signatures in a message.  A corollary of this
        requirement is that the protocol MUST NOT link practices of first
        party signers with the practices of third party signers.

          INFORMATIVE NOTE: the main thrust of this requirement is that
          practices should only be published for that which the publisher
          has control, and should not meddle in what is ultimately the
          local policy of the receiver.

          Refs: Deployment Consideration, Section 4.3.

This corollary added at the last minute and ever since then, we had no 
SOLUTION to this issue.  It destroyed SSP, ADSP and now it threatens 
DMARC.   Only this time, by using radical rewrite concepts to bypass 
the DMARC security offered by 1st party.

> If we all agreed that DMARC was a DKIM Policy Framework, what outcome would
>that have brought us closer to?

To accept the fact that DMARC lacks policies or certain practices that 
has long cause the conflict  that currently exist.  We are trying to 
see how to fit" in an authorized or allowed a 3rd party signer.  The 
DMARC Policy Framework has no provision for this other than an 
allowance for a 3rd party extension to be added to it, see 
draft-kucherawy-dmarc-base, section 3.1.4.3

    3.1.4.3.  Alignment and Extension Technologies

    If DMARC is extended to include the use of other authentication
    mechanisms, the extensions will need to allow for domain identifier
    extraction so that alignment with the RFC5322.From domain can be
    verified.

There is where the focus should be at.

> I suspect there was a purpose for that argument that might still be relevant
>to our work even though the argument doesn’t seem to be supported, but 
I’m
> not seeing it yet.

Thats unfortunate, because based on your marketing efforts (spams from 
agari regarding presentations you are making), you should be on top of 
these very important total mail integration concepts.  These are ALL 
integrated ideas and you can't just isolate one from the other if 
there is expectation of a wide spread, across the board, adoption:

    RFC4405  SUBMITTER SMTP Service Extension
    RFC4406  Sender ID: Authenticating E-Mail
    RFC4407  Purported Responsible Address (PRA)
    RFC4408  Sender Policy Framework (SPF)
    RFC4686  Analysis of Threats Motivating DKIM
    RFC4870  DomainKeys
    RFC4871  DKIM (RFC5672.TXT,  RFC6376.TXT)
    RFC5016  Requirements for a DKIM Signing Practices Protocol
    RFC5451  Message Header Field for Indicating Message 
Authentication Status
    RFC5518  Vouch By Reference
    RFC5585  DKIM Service Overview
    RFC5617  DKIM Author Domain Signing Practices (ADSP)
    RFC5863  DKIM Development, Deployment, and Operations
    RFC5965  An Extensible Format for Email Feedback Reports
    RFC6376  DomainKeys Identified Mail (DKIM) Signatures
    RFC6377  DomainKeys Identified Mail (DKIM) and Mailing Lists
    RFC6541  DomainKeys Identified Mail (DKIM) Authorized Third-Party 
Signatures

In particular, I suggest a quick review of RFC4686, RFC5016 and 
RFC5585 to gain a high total system view appreciation of whats going on.

Thanks

-- 
HLS

---

From: Brett McDowell <[email-masked]>
Date: Tue, 28 Oct 2014 16:16:07 -0400

On Tue, Oct 28, 2014 at 3:22 PM, Hector Santos <[email-masked]> wrote:
> I’m not seeing it yet.
> these very important total mail integration concepts.

Hector, don't confuse your inability to put forward a coherent argument
with my inability to understand these concepts.

---

From: Hector Santos <[email-masked]>
Date: Tue, 28 Oct 2014 16:32:01 -0400

On 10/28/2014 4:16 PM, Brett McDowell wrote:
>>
>>> Brett McDowell wrote:
>>> I suspect there was a purpose for that argument that might still be
>>> relevant to our work even though the argument doesn’t seem to be supported,
>>> but I’m not seeing it yet.
>>
>> Hector Santos <[email-masked]> wrote:

Thats it?  Is that all you have, is to attack my integrity? I won't 
bother to issue an complaint to the WG chairs.  I wasn't attacking 
you. You questioned the concept and reasons for the DKIM Policy 
framework discussions when in fact, DMARC is all about a policy layer 
for DKIM/SPF. I felt its unfortunate you are not seeing the problem. 
There is a 184 references towards the idea.  There is a long time 
history and tons of R&D work. There is a problem regarding 3rd party 
signers.  What else is there to understand?

-- 
HLS

---

From: Tim Draegen <[email-masked]>
Date: Tue, 28 Oct 2014 16:49:54 -0400

Hello, please remember to keep this dialogue respectful.

Feel free to review:

  http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki

...as it forms the basis for meeting the WG's first milestone.

1/2 of this WG's Chair,
=- Tim

---

From: Hector Santos <[email-masked]>
Date: Tue, 28 Oct 2014 16:57:51 -0400

Brett, my main point is that, if you, of all people, don't understand 
the problem, then we seriously are having a basic understanding of the 
long time conflict and its resolutions.

You (speaking in general) either support a policy concept or you 
don't.  Thats been the dilemma all these years.

But you do understand policy, because you pointed out the idea that 
you don't need DKIM per se to use DMARC, i.e. you have a restrictive 
policy to handle legacy abused operations (where mail is not signed or 
there is no mail operation for a domain).  These are not new ideas. 
They are 10 years old DKIM POLICY concepts.

However, I find it hard to understand how the advocates of DMARC are 
not pushing for 3rd party solutions.  Thats the odd thing about it.

My apology to you if you felt offended by my comments.  It wasn't 
intended.  If the new DMARC advocates and DKIM Policy Marketing was as 
strong during SSP/ADSP, the original proof of concept with DKIM, we 
probably would of solved this problem long ago and MLM/MLS systems, 
including our own MLS product, would be better off without the radical 
rewriting hacks suggestions.

--
HLS

-- 
HLS

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 28 Oct 2014 16:59:07 -0400

Can we please start using meaningful subject lines.  We're now 
discussing about 6 different topics under "wiki vs. list" - none of 
which have to do with "wiki vs. list."

Miles Fidelman

---

From: Brett McDowell <[email-masked]>
Date: Tue, 28 Oct 2014 17:30:47 -0400

On Tue, Oct 28, 2014 at 4:57 PM, Hector Santos <[email-masked]> wrote:

> intended.

Thank you for saying so Hector.  I appreciate it.

>> Thats it?  Is that all you have, is to attack my integrity?
>
>
I apologize if my effort to defend my own integrity (and that of Agari)
came across as an attack on yours.  You are obviously extremely well versed
in "the literature" of Internet mail.  I didn't mean to imply you were
incapable of making a coherent argument, just that you hadn't thus far and
that I wasn't going to accept the implications of your comment aimed at
Agari and myself.  But it's all water under the bridge, as they say.

FWIW, I actually think I now understand what you were trying to get at with
the original argument about DMARC being a DKIM Policy Framework.  We were
simply talking past each other.  So yes, I obviously support what DMARC
does to make the inboxes of the world a safer place every day.  So if you
want to call that "a policy framework", I don't see the downside in
agreeing with you.

But let's get back to closing out Milestone 1, which is orthogonal to this
discussion.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 29 Oct 2014 13:43:14 +0900

> don't.  Thats been the dilemma all these years.

If "policy" means that destinations "must" or "should" (in the RFC
2119 sense) *do* what the Author Domain publishes as policy, both as
an MLM developer and as a user of the Internet I can't support a
"policy concept".  Of course, this is what "policy" means in most
everyday contexts, so it's easy to get confused.

If "policy" means that Author Domains can publish information about
their particular circumstances vis-a-vis various threats that exist,
associated with recommendations (BCP) for disposition of messages
that meet (or fail to meet) various criteria in those particular
circumstances, along with discussion of how blindly following rules
can hork the whole 'net, of course I'm all for it.

 > However, I find it hard to understand how the advocates of DMARC
 > are not pushing for 3rd party solutions.  Thats the odd thing about
 > it.

Most advocates of DMARC have no need for 3rd party solutions.  They
are concentrating on transactional, direct mailflows, and where they
need indirect mailflows, it seems that they have little trouble
establishing sister domains with appropriate DMARC policies for those
exceptional mailflows.  AFAIK even the "we know better than DMARC"
services like Gmail *reject* when these domains publish "p=reject".

The heavy DMARC users whose use of p=reject are causing problems for
third parties aren't really experiencing much pain themselves, or at
least the concentrated attacks in April were *much* more painful.  A
few users complain, but the services have plausible deniability and
their users' hate for spam to protect them from mass revulsion, let
alone revolution.  I doubt they consider it their business to develop
such solutions, especially since they say they are still under attack,
and presumably are experiencing new forms of attack all the time.

The third parties who *do* have an interest in "real" solutions didn't
have time to develop one in April, let alone persuade the many DMARC
participants to implement it.  Most MLM users, for example, are quite
nontechnical, and have little experience with the issues that the IETF
has to grapple with in creating a viable *standard* solution.  Nor do
we trust, specifically, Yahoo! and AOL to adopt one if it existed.  At
least at Mailman we have a long history of users suffering from their
arbitrary decisions and inflexible policies, and we don't believe that
they will adopt a standard solution even if one were created.  The
Mailman community has little incentive and less optimism for pushing
for standardized "third-party solutions".  (Not to mention that IETF
standardization processes are considered arcane and slow.)

Note: Above in referring to "Mailman", I'm reporting the general
opinion of the Mailman community.  I am personally hopeful, after
interacting with technical staff at Yahoo!, that Yahoo! will play
along (but I'm sure it will take time).  I don't have the same
confidence about AOL (no similar interaction), but I suppose that they
won't want to be odd man out if Yahoo! participates.  (As for IETF
standardization, I'm here, OK? :-)  And I'm saying those things to the
Mailman folks, too.  But it's going to take time to convince them.

 > If the new DMARC advocates and DKIM Policy Marketing was as strong
 > during SSP/ADSP, the original proof of concept with DKIM, we
 > including our own MLS product, would be better off without the
 > radical rewriting hacks suggestions.

They're not "suggestions".  They're de facto BCP.  You need to wrap
your head around that fact.  No, they're not good.  In fact, they suck
badly in my opinion, and as you know I've argued against suggestions
like "List-Original-Author" that encourage and enable them.  But they
*are* in wide use and nobody has come up with a better idea we can use
*now* -- they are indeed *best* *currently*.  Denying that just
confuses the heck out of the rest of us.

Sincere regards,

Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 28 Oct 2014 23:14:20 -0700

>  > don't.  Thats been the dilemma all these years.

Stephen's summary of the state of things matches my understanding pretty
much exactly.

The "dilemma" has nothing to do with not supporting policy.  It has
everything to do with the fact that the policy mechanisms we've come up
with so far don't work; they are too complicated, they're easily beaten,
they don't scale to large ESP size, they only apply to some kinds of mail,
they don't provide enough bang for the buck, or some combination of those.

It's untrue that we never gave them a chance.  ADSP and ATPS, for example,
became RFCs and got released as part of commercial and open source products
because we thought they might be worth trying out.  For ATPS, there was
absolutely no interest; for ADSP, people tried it and didn't like what they
saw.  If there were other things that were tried that actually stood a
chance of working, I've yet to hear about them.

As far as I'm concerned, the "policy concept" that will succeed is
something that meets most or all of those requirements.  But I would rather
release email authentication protocols without a third-party capability, or
even without a policy capability at all, than saddle it with some kind of
broken extension that's got some or all of these flaws.  That's what we did
with DKIM, and in retrospect, it was certainly the right thing to do.
Moreover, it'll take some pretty strong arguments, or actual data would be
even better, to form consensus around such a thing.

Hopefully we've now said enough on this thread about policy and third-party
stuff, especially since it has nothing at all to do with reaching our first
milestone.

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Wed, 29 Oct 2014 11:56:29 -0700

On Oct 28, 2014, at 11:14 PM, Murray S. Kucherawy <[email-masked]> wrote:

> On Tue, Oct 28, 2014 at 9:43 PM, Stephen J. Turnbull <[email-masked]> wrote:
> Hector Santos writes:
> 
> Stephen's summary of the state of things matches my understanding pretty much exactly.
> 
> The "dilemma" has nothing to do with not supporting policy.  It has everything to do with the fact that the policy mechanisms we've come up with so far don't work; they are too complicated, they're easily beaten, they don't scale to large ESP size, they only apply to some kinds of mail, they don't provide enough bang for the buck, or some combination of those.
> 
> It's untrue that we never gave them a chance.  ADSP and ATPS, for example, became RFCs and got released as part of commercial and open source products because we thought they might be worth trying out.  For ATPS, there was absolutely no interest; for ADSP, people tried it and didn't like what they saw.  If there were other things that were tried that actually stood a chance of working, I've yet to hear about them.
> 
> As far as I'm concerned, the "policy concept" that will succeed is something that meets most or all of those requirements.  But I would rather release email authentication protocols without a third-party capability, or even without a policy capability at all, than saddle it with some kind of broken extension that's got some or all of these flaws.  That's what we did with DKIM, and in retrospect, it was certainly the right thing to do.  Moreover, it'll take some pretty strong arguments, or actual data would be even better, to form consensus around such a thing.
> 
> Hopefully we've now said enough on this thread about policy and third-party stuff, especially since it has nothing at all to do with reaching our first milestone.

Dear Murray,

May I add a minor point, ATPS introduced optional authorization label encodings signaled with a "special" unsupported third-party DKIM signature.  It seems IESG suggested there might be DoS concerns and that adding signaling via a "special" third-party DKIM signature would be less prone although this ignores additional namespace diversity that could be created by DKIM selectors which might actually increase DoS concerns. TPA-Label instead solved this by adding a simple flag in the DMARC record.

Another advantage claimed for ATPS was these "special" third-party signatures permitted authorization labels to also be simple strings rather than a deterministic hash. Unfortunately, this change induced by IESG then required ALL third-party services introducing an unsupported DKIM signature lacked any way to convey the authorization label encoding schemes used by what is now called DMARC domains.  Imagine the dilemma this would cause those operating services such as mailing-lists being forced to remain current of all unpublished practices employed by the domains of their users.   This added encoding option signaled using a special DKIM signature prevented any reliant third-party signature adoption, although it was ostensibly done to make this protocol easier to implement by allowing the option of plain labels.  This too can now be signaled using the DMARC record directly.  As such, it should not have been surprising there was no interest in ATPS, nor, IMHO, should there have been.  That said, you should be commended for having taken this scheme as far as you did.  For all your hard work, I truly thank you.

Regards,
Douglas Otis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 29 Oct 2014 12:16:01 -0700

On Wed, Oct 29, 2014 at 11:56 AM, Douglas Otis <[email-masked]>
wrote:

> May I add a minor point, ATPS introduced optional authorization label
> encodings signaled with a "special" unsupported third-party DKIM
> signature.
> [...]
> As such, it should not have been surprising there was no interest in ATPS,
> nor, IMHO, should there have been.  That said, you should be commended for
> having taken this scheme as far as you did.  For all your hard work, I
> truly thank you.
>

I appreciate the recognition.

As for the rest, you've made these claims before.  I still don't buy it.
If you were right, there would have been some feedback somewhere from the
community (other than you, I mean) explaining why it was an unacceptable
solution and perhaps making suggestions about improving it to make it more
palatable.  There has not been a single message of this nature since.

Instead, I believe it's simply the case that nobody's looked at it.  We
published it as an Experimental RFC and made it available in open source
for free, and announced its availability in a few key places (MAAWG, for
example).  According to our automated feedback, exactly two operators tried
it (one of them me, the other a hobbyist).  There has been no active
response of any kind in almost three years.  I take this to indicate that,
prior to DMARC, third-party stuff in general has simply not been enough of
a pain point for anyone to care.

DMARC may be changing that perspective finally.  It remains to be seen
where consensus will take us, and again, whether the email community at
large will be interested.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Wed, 29 Oct 2014 18:56:54 -0400

> palatable.  There has not been a single message of this nature since.

This is not a fair assessment, especially among this group.

> it (one of them me, the other a hobbyist).

You always forget our commercial product and the few thousands of its 
operators, and also the interest I recorded and shown via the 
ADSP/ATPS wizards.  All that is never repeated nor acknowledged by you.

> There has been no active

This is a contradiction.  DMARC is policy. You choose to limit it 
based on the ADSP rough experiences we had regarding 3rd party in a 
TRUST ONLY group and you learned not to add it.  You admitted as much.

You did do ATPS because of the interest in the DKIM-WG but you also 
said it was not a GOOD IDEA following the doctrine of a few others so 
no one followed you.   You can't do that. Levine did the same with 
ADSP and it also had a hard time.

DMARC would had also had a hard time if introduced in DKIM-WG.  It was 
the same thing and problems as ADSP.  ADSP was pushed out to be 
replaced for DMARC.

That doesn't make sense -- to say ADSP was a failed 
experienced/experiment and DMARC is not?  Whats the difference?

You got to champion what you produce. It doesn't work any other way. 
You championed DMARC. You took the same technology and added reporting 
to it, something that was pushed back during SSP/ADSP.  DSAP offered a 
little reporting.  People, ADMINS, like reporting. So that was the 
entry point to what we have. But its the same problem was ADSP. 
Nothing was solved with DMARC.

> large will be interested.

DMARC, like ADSP is a contradiction in proper total mail integration. 
They were both half-baked, incomplete solutions and anyone can see it 
was going to be a problem from the git-go.  That is why it has been a 
thorn on a side for a long time.

Its not a matter of not wanting 3rd party solutions, it needs to be 
PART of the PROTOCOL to complete or fill all holes in it.  In other 
word, you didn't give anyone to chance to adjust to it because you 
failed to believe in it.  If you don't see it, I can understand it. 
But people did it and in this group, a different set of folks from the 
DMARC arena, it hards to understand why they don't want the DMARC 
thorn removed by provided 3rd party OPTIONS.  Make it optional at 
least.  You don't even want to do that.

Its odd to write something that you don't believe in.  Others see that 
and won't give it a chance.   I understand you also had pressure from 
the trust groups to not support it.

But from a product standpoint, you have to provide the OPTIONS to do 
offer this.  You don't even want to do that.

I still don't buy the arguments against it because it is the BEST 
solution we have available and definitely the most simplistic of 
everything being proposed especially the rewriting hacks, which for 
sure is not going to be widely acceptable and also borders on ethical 
engineering and intentional damages.  It could be appealed material 
for sure.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Wed, 29 Oct 2014 19:20:35 -0400

> which have to do with "wiki vs. list."

When you generalize the problem for any "indirect flow" or "list 
system" it was long understood and documented in RFC5016 by defining 
two terms, first party and third party signatures.

    https://tools.ietf.org/html/rfc5016#section-2

    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.

In other words, when it comes to "INDIRECT FLOWS"  at the end of day, 
we are talking about software detecting the difference between two 
identities:

   From: user@author-domain
   DKIM-Signature: d=signer-domain

where the author-domain identity (ADID) either matches or is different 
from the signer domain identity (SDID).

In other words, INDIRECT FLOWS are 3rd party signers:

     ADID != SDID

The solution is to make the AUTHORIZED ASSOCIATION between the ADID 
and SDID.

It really doesn't matter what "indirect flow" is out there, at the end 
of the day, its about the two parameters not matching and that is what 
the SOFTWARE will see.

The question is what do we teach the SOFTWARE to do about it.

This GROUP wants to MUNGE the ADID the bypass the DMARC security.

I say that is a TERRIBLE IDEA but I understand how some are very 
passionate about DMARC interfering in some of their users 
participation in their operations.

If they are going to rewrite, then at the very least we MUST make 3rd 
party protocol options and algorithms available as well to ALL 
implementators as part of the DMARC protocol to complete the total 
picture.

-- 
HLS

---

From: Tim Draegen <[email-masked]>
Date: Wed, 29 Oct 2014 22:32:42 -0400

> On Oct 29, 2014, at 7:20 PM, Hector Santos <[email-masked]> wrote:
> 
> If they are going to rewrite, then at the very least we MUST make 3rd party protocol options and algorithms available as well to ALL implementators as part of the DMARC protocol to complete the total picture.

Hi Hector, this thread is no longer productive to the work that this working group needs to immediately accomplish.  What you're referring to is more properly part of a latter phase/milestone, but first the WG needs to finish compiling the actual list of "indirect email flows".

The WG is focused now on compiling this list to avoid issues that arise when the problem space is too narrowly defined.  Unfortunately this means you need to wait for the WG to catch up to you.  To make sure the WG isn't delayed, I'm asking for reviews of the current work:

Anything else right now is simply a distraction.

1/2 of the WG Chair,
=- Tim

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 30 Oct 2014 13:03:13 +0900

Hector Santos writes:

 > The solution [to the third-party problem] is to make the AUTHORIZED
 > ASSOCIATION between the ADID and SDID.

This is a *first* party solution, and I have seen no evidence that
Yahoo! and AOL are going to buy in to TPA-labels-style authorized
associations.  In fact, I am pretty sure that AOL *will refuse*,
because over the past few years they have been chasing out and then
firing exactly the staff who would be responsible for authorizing the
associations.

 > This GROUP wants to MUNGE the ADID the bypass the DMARC security.

Please stop that.  It does not *want* to do any such thing.  It simply
acknowledges that it is *already* current practice.  (I dropped the
"best" just for you!)

 > implementators as part of the DMARC protocol to complete the total 

We can't make them available to "all".  Those options, as you and Doug
advocate them (that is, requiring "policy lookup"), are available only
to first parties.  This is the stumbling block that forces indirect
mail operators to consider ADID-munging (From-munging).

Are you willing to support the Levine or Crocker-Kucherawy proposals
for delegation to explicit addressees?

Steve

---

From: [email-masked]
Date: Wed, 29 Oct 2014 21:44:37 -0700 (PDT)

> 1/2 of the WG Chair,

+1 from the other 1/2.

				Ned

---

From: Brandon Long <[email-masked]>
Date: Thu, 30 Oct 2014 15:00:32 -0700

> firing exactly the staff who would be responsible for authorizing the

I'm not happy with the idea because I have >400M users, and I'm not even
sure how I would validate any given service to gain enough trust to allow
it to send for any one of those users.  And there are always going to be
some services that we haven't seen before or won't make the trust bar
(you're running a mailing list on your linux virtual server for your N
friends?  That's nice, not going to meet the bar or the bar is useless).

Speaking for an enterprise use case, we have relaying, expanding SPF or
passing out a specific dkim key to handle those senders, but at the very
least, a business domain is at least a restricted set of users with likely
a similar trust domain and policies and such.

And now I'm not sure if I'm responding to a thread that was officially
closed by the wg or not, so my apologies if that's the case.

Brandon

---

From: Douglas Otis <[email-masked]>
Date: Thu, 30 Oct 2014 17:47:46 -0700

On Oct 30, 2014, at 3:00 PM, Brandon Long <[email-masked]> wrote:

> On Wed, Oct 29, 2014 at 9:03 PM, Stephen J. Turnbull <[email-masked]> wrote:
> Hector Santos writes:
> 
> I'm not happy with the idea because I have >400M users, and I'm not even sure how I would validate any given service to gain enough trust to allow it to send for any one of those users.  And there are always going to be some services that we haven't seen before or won't make the trust bar (you're running a mailing list on your linux virtual server for your N friends?  That's nice, not going to meet the bar or the bar is useless).
> 
> Speaking for an enterprise use case, we have relaying, expanding SPF or passing out a specific dkim key to handle those senders, but at the very least, a business domain is at least a restricted set of users with likely a similar trust domain and policies and such.
> 
> And now I'm not sure if I'm responding to a thread that was officially closed by the wg or not, so my apologies if that's the case.

Dear Brandon,

As the DMARC introduction states, it determines authorized identifiers.  The draft unfortunately also muddles authorization with authentication.  We have been seeing an increasing level of spoofing that leverages weaknesses in SPF and even DKIM.  Preventing authorized messages from being placed into spam folders must not be seen as claiming to have "authenticated" a message's originating domain.  Neither DKIM nor SPF really does this.  It is misleading to oversell the function of DMARC, SPF, and DKIM.  In addition, having a growing amount of legitimate email placed into spam folders also carries comparable risks as this too lowers the bar in what a user is more likely to open. 

A DMARC domain can determine legitimate third-party services by comparing outbound message domains against their DMARC feedback. Offering receivers domain specific third-party feedback will increase protections (raising the bar) as well as allowing DMARC restrictive policies to be applied in more environments. The DMARC domain could even proactively vet these domains.  Why give a malicious domain grist for their phishing mill?

Regards,
Douglas Otis