Subject: DMARC-4-ML: Can the IETF call a demonstration?

From: Alessandro Vesely <[email-masked]>
Date: Wed, 14 May 2014 13:52:01 +0200

After some discussion on ietf-822, two viable methods were identified
for DMARC for mailing lists (ML).  Someone cutely suggested to do both:

*Tweak DKIM signatures*
To be applied on sending, produce a partial author's domain signature
which can be verified along with the ML signature.  To be refined a
bit, in order to account for chaining from a ML to another.

*Whitelist*
To be applied on receiving, for MLs endorsed by each domain's users.

Both methods require each domain to build a DB of MLs.  That can be
done by a "manual process" (see picture) for the time being.  The
process consists of each ML admin extracting a per-domain list of
subscribers and sending it to the relevant domain postmaster, after
obtaining subscribers' consent.  The volume of data is so huge as to
be akin to an on-line demonstration.

Will the admins go marching in?

Doing nothing will result in a mix of three reactions.  1, ML admins
changing the From: of domains who publish strict DMARC policies;  2,
some users changing mailbox provider; and 3, less domains publishing
strict DMARC policies.  The combined effect seems to weaken both DMARC
and mailing lists.

Ale

---

From: John C Klensin <[email-masked]>
Date: Wed, 14 May 2014 08:39:40 -0400

--On Wednesday, May 14, 2014 13:52 +0200 Alessandro Vesely
<[email-masked]> wrote:

> After some discussion on ietf-822, two viable methods were
> identified for DMARC for mailing lists (ML).  Someone cutely
> suggested to do both:
> 
> *Tweak DKIM signatures*
>...
> *Whitelist*
>...
> Both methods require each domain to build a DB of MLs.  That
> can be done by a "manual process" (see picture) for the time
> being.  The process consists of each ML admin extracting a
> per-domain list of subscribers and sending it to the relevant
>...

Ale,

At the risk of repeating myself...

(1) I think it is a bad idea for the IETF to be formally
spending effort to work around damage caused by a non-IETF
protocol.   I note that, if this were a protocol that was
specified in the IETF and over which the IETF had change
control, we would be trying to fix the protocol itself or would
withdraw or depreciate it because of the damage caused.  

(2) I believe it is unacceptable for a new protocol or
capability to impose costs on operators of other systems in the
absence of clear and broad consensus about why the changes are
needed and appropriate. That consensus may well exist for DMARC
and its policy statements among the contributors/ supporters of
dmarc.org, but it is fairly clear to me that it does not exist
in the IETF.   Contrast that with, e.g., privacy issues about
which there have been consensus statements in the IETF, perhaps
even statements strong enough to justify some additional costs.

(3) Since I mentioned privacy, I should note that developing,
keeping, and maintaining the database you mention could have
significantly more privacy risks than simple recording of
envelope information in server logs.  If IETF is now committed
to privacy as a significant goal, that question needs careful
evaluation.

> Doing nothing will result in a mix of three reactions.  1, ML
> admins changing the From: of domains who publish strict DMARC
> policies;  2, some users changing mailbox provider; and 3,
> less domains publishing strict DMARC policies.  

There are two more options you didn't mention: (4) more systems
either not implementing DMARC or ignoring strict policy
specifications, and (5) driving some users and activity away
from the use of mailing lists entirely in favor of using more
"social network" web sites and activities.  I note that some
people believe that DMARC and strict policies are part of a
business model to force that result.  I don't believe that
personally, but the optics are unfortunate.

> The combined
> effect seems to weaken both DMARC and mailing lists.

So?  Perhaps we should be focusing more on strategies that
weaken DMARC to the degree necessary or appropriate without
weakening mailing lists or imposing added costs on those who
operate or subscribe to them.  

The analogy is obviously not exact, but, if some external group
came up with a protocol that weakened TCP and undermined all of
our congestion control mechanisms, we might be pointing out the
damage and encouraging people to not use that protocol --
perhaps even figuring out ways to block its use -- but would not
be scurrying to alter TCP to better accommodate the behavior of
that new protocol, especially if the alterations made "normal"
use of TCP less efficient or effective.

   best,
   john

---

From: [email-masked]
Date: Wed, 14 May 2014 08:36:09 -0700 (PDT)

> withdraw or depreciate it because of the damage caused.

This misrepresents the situation so substantially it is essentially a strawman
argument. In particular, DMARC did not emerge, full formed, out of the void.
It's the logical evolution of ADSP, a standards-track IETF protocol.

In fact an argument can be made that in terms of responsible mail handling,
DMARC is actually an improvement over ADSP. In particular, ADSP provides policy
choices of "unknown", "all", and "discardable", wheras DMARC provides "none",
"quarantine", and "reject". Honoring a "discardable" policy causes mail to be
lost, whereas at least "reject" provides an indication that something went
wrong.

The fact that ADSP was developed in tandem with DKIM also means that the IETF
cannot reasonably claim that attaching these sorts of semantics to From: fields
was in any way unexpected. As such, there was at least a resposibility to
document likely interoperability problems use of DKIM in this way would cause.

But let's suppose for a moment the assertion that this is simply a case of a
non-IETF protocol coming at us out of the blue. I still categorically reject
the assertion that it's not our responsibility to address the issues it has
raised. Our job is to write documents that improve email.

Of course a line has to be drawn somewhere; the IETF can't possibly respond to
every single stupid thing that people do on the Internet. But when three of the
largest MSPs in existence decide to publish problematic DMARC policies and
large numbers of email receivers have implemented DMARC checks,  resulting in
widespread damage, and subsequently refuse to reconsider those policies, I
think the line was crossed.

> in the IETF.

The "new protocol" of which you speak is, in fact, a combination of three
pieces: DMARC, SPF, and DKIM. Two of thoese are standards-track protocols, and
one of those (SPF) has a built-in policy mechanism which, if used, most
assuredly does "impose costs on operators of other systems".

And as I noted above, it's not like the IETF didn't publish ADSP on the
standards track, or that this usage of DKIM was a surprise.

So it seems that the IESG felt there was an IETF consensus in this area.

> Contrast that with, e.g., privacy issues about

> to privacy as a significant goal, that question needs careful

Good point. I don't think the database approach is remotely viable for other
reasons - mostly that I've yet to encounter an ISP or MSP willing to take on
the task of building and maintaining such a thing - but the privacy aspect
do warrant some consideration.

> > less domains publishing strict DMARC policies.

Or 4. ML revoking the posting rights of users from domains that
report policy errors. Or 5. Rather than unsubscribing the failing
recipients, either ignore the error or report the failures to the
original message sender, thus making it clear to them the cost
they're paying for the provider they have chosen.

Except in order to do either of these well you need some additional status
codes, codes which only the IETF can assign. (And yes, I'm aware that a ML can
perform its own check on the From: domain and if it lists a reject policy
refuse the mail, thus avoiding the need for new error codes. Except that's both
a lot more work with a less reliable outcome.)

The good news, such as it is, is that the relevant registry is "Specification
Required", meaing this can be done in the DMARC base specification or some
other informational RFC. Which I guess would avoid significant IETF
involvement.

> personally, but the optics are unfortunate.

I'll note that "ignoring stricy policy specifications" is not necessarily
a good thing. Having a DMARC failure contribute to an overall spam score
can easilt lead to mail being silently lost instead of being rejected,
with all that implies.

> operate or subscribe to them.

Well, yeah, that's kinda the point of this exercise.

> use of TCP less efficient or effective.

On the contrary, if the protocol that external group came up with was widely
deployed and there were reasonable tweaks that could make them coexist, I think
that's exactly what the Transport Area would do.

				Ned

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 14 May 2014 19:20:26 +0200

John,

On Wed 14/May/2014 14:39:40 +0200 John C Klensin wrote:
> --On Wednesday, May 14, 2014 13:52 +0200 Alessandro Vesely wrote:
> 

That sounds like yet another instance of the not-invented-here
syndrome.  FWIW, much the same solutions were put forward for ADSP.
IETF or non-IETF, the difference seems to be that DMARC currently has
more traction and deployment than ADSP ever had.

> even statements strong enough to justify some additional costs.

Getting a rough gauge of consensus is exactly the reason why I wrote.
 I'm less confident than you on the opinion of DMARC people, since a
change in DMARC is implied.  I noted some inclination toward
reasonable changes from a few ML admins on this list, though.

Let me make explicit it is not consensus on DMARC we're talking about.
 It is consensus on the workaround and the demonstration.

> to privacy as a significant goal, that question needs careful

That's why the DB has to be build by hand.  Although I doubt it is
realistic for users to hide out from their mailbox providers, I agree
special care is needed.  For those who trust their mailbox provider,
it is convenient to have it control their subscriptions.  A possible
method to automate that task was called water-tight-opt-in[1].

[1] http://fixforwarding.org/wiki/Water_tight_opt-in

> "social network" web sites and activities.

Thanks to you and Ned for completing the analysis.

> I note that some people believe that DMARC and strict policies are
> part of a business model to force that result.  I don't believe
> that personally, but the optics are unfortunate.

Me too.  Spam is the selective pressure.

>> The combined effect seems to weaken both DMARC and mailing
>> lists.
> 

I'm not sure it would be good to go for a head-on collision, even if
we were granted getting out safe.  For another inexact analogy, we let
SPF die down that way.  Had we agreed on a viable compromise, perhaps
we would have enjoyed less spam, who knows?  Now DMARC comes harder.
The question is when the next will come, and whether it will be so
better as to be worth the while.

Yours
Ale

> came up with a protocol that weakened TCP [...]

---

From: John C Klensin <[email-masked]>
Date: Wed, 14 May 2014 13:36:40 -0400

--On Wednesday, May 14, 2014 19:20 +0200 Alessandro Vesely
<[email-masked]> wrote:

>> wrote:
>> control, we would be trying to fix the protocol itself or
>> would withdraw or depreciate it because of the damage caused.
> 
> syndrome.  FWIW, much the same solutions were put forward for
> ADSP. IETF or non-IETF, the difference seems to be that DMARC
> currently has more traction and deployment than ADSP ever had.

No, it is not NIH.  It is that the IETF has no change control
over DMARC and hence does not have the option of controlling the
damage by withdrawing or adjusting the protocol itself.  There
is no plausible reason why the IETF should be forced into the
role of policeperson for protocols developed elsewhere or,
worse, in aiding those who created a protocol elsewhere in their
(I hope accidental) efforts to inflict pain and costs on others
in the community in order to make their systems work better.

>> capability to impose costs on operators of other systems in
>> the absence of clear and broad consensus about why the
>> changes are needed and appropriate. That consensus may well
>> exist for DMARC and its policy statements among the
>> contributors/ supporters of dmarc.org, but it is fairly clear
>> to me that it does not exist in the IETF.   Contrast that
>> with, e.g., privacy issues about which there have been
>> consensus statements in the IETF, perhaps even statements
>> strong enough to justify some additional costs.

> Getting a rough gauge of consensus is exactly the reason why I
> wrote.  I'm less confident than you on the opinion of DMARC
> people, since a change in DMARC is implied.  I noted some
> inclination toward reasonable changes from a few ML admins on
> this list, though.
> 
> Let me make explicit it is not consensus on DMARC we're
> talking about.  It is consensus on the workaround and the
> demonstration.

And I am suggesting that, if you want to initiate a proposal for
work on damage control wrt DMARC, nothing prevents you from
proposing that as a work item for some existing WG or a new WG.
I have no opinion about the "opinion of DMARC people" re a
change in DMARC.  IETF does not have change control, so the
question of their opinion is irrelevant.  If IETF did have
change control, their opinions would be part of the general
community consensus... or not.
 
> That's why the DB has to be build by hand.  Although I doubt
> it is realistic for users to hide out from their mailbox
> providers, I agree special care is needed.  For those who
> trust their mailbox provider, it is convenient to have it
> control their subscriptions.  A possible method to automate
> that task was called water-tight-opt-in[1].

As you suggest, building by hand only changes the "who do you
trust and about what" equation.  If someone felt forced to
switch email providers because they trusted their provider to
handle mail but not to keep databases of lists subscribed to,
that would be another instance of the design of DMARC and those
specifying restrictive rules imposing costs, perhaps significant
ones, on others.

> I'm not sure it would be good to go for a head-on collision,
> even if we were granted getting out safe.  For another inexact
> analogy, we let SPF die down that way.  Had we agreed on a
> viable compromise, perhaps we would have enjoyed less spam,
> who knows?  Now DMARC comes harder. The question is when the
> next will come, and whether it will be so better as to be
> worth the while.

Again, from my perspective, the question is whether the IETF
actually has responsibility for protocols for which there has
been no effort to obtain IETF consensus and over which the IETF
does not change control.  Until and unless some process decides
that the IETF is in charge of the Internet and allocates
Protocol Police to enforce IETF policies over things it didn't
create, I think the answer to that question has got to be "no".

best,
   john

---

From: Hector Santos <[email-masked]>
Date: Wed, 14 May 2014 13:44:00 -0400

John,

Right, its not the same analogy when you consider the IETF did now 
change "TCP" with a now new IETF STD level change/addition to TCP. 
The problem has alway been that the change was for a last signer trust 
model at the expense of original source policy model which the 
industry clearly desired if TCP was going to be now potentially 
challenged with new TCP signature stamps.

-- 
HLS

---

From: John C Klensin <[email-masked]>
Date: Wed, 14 May 2014 15:11:44 -0400

--On Wednesday, May 14, 2014 08:36 -0700 Ned Freed
<[email-masked]> wrote:

> This misrepresents the situation so substantially it is
> essentially a strawman argument. In particular, DMARC did not
> emerge, full formed, out of the void. It's the logical
> evolution of ADSP, a standards-track IETF protocol.

A standards-track IETF protocol that was deprecated by a process
that claimed it was unused and harmful.   If it had been the
intent to replace ADSP with an IETF-developed DMARC, that would
properly have been handled by submitting the DMARC specification
for standards-track publication, one that obsoleted and
deprecated ADSP and that, to the degree appropriate,
demonstrated that it solved the problems that made ADSP
problematic.

> In fact an argument can be made that in terms of responsible
> mail handling, DMARC is actually an improvement over ADSP. In
> particular, ADSP provides policy choices of "unknown", "all",
> and "discardable", wheras DMARC provides "none", "quarantine",
> and "reject". Honoring a "discardable" policy causes mail to be
> lost, whereas at least "reject" provides an indication that
> something went wrong.

So?  Based on the argument that ADSP was broken, there was an
IETF discussion and a decision by the IESG that community
consensus justified deprecating it and moving it historic.
Whether DMARC is better or not, derived from IETF work or not,
it was not developed as an IETF protocol and the IETF was not
consulted before it was deployed.

> The fact that ADSP was developed in tandem with DKIM also
> means that the IETF cannot reasonably claim that attaching
> these sorts of semantics to From: fields was in any way
> unexpected. As such, there was at least a resposibility to

Yes, I agree with that.  I don't know why that wasn't done when
either DKIM or ADSP were published, but suggest that, had DMARC
been exposed to the IETF consensus process, it would have
provided an additional opportunity to get those problems noticed
and documented.  Of course, no one can guess whether that
opportunity would have led to anything.

> But let's suppose for a moment the assertion that this is
> simply a case of a non-IETF protocol coming at us out of the
> blue. I still categorically reject the assertion that it's not
> our responsibility to address the issues it has raised. Our
> job is to write documents that improve email.

I don't recall saying anything about "out of the blue".  All
I've asserted is that DMARC itself was not developed within the
IETF, using an open process, was not approved via an IETF
consensus process, and that the IETF does not have change
control over its evolution.

Now, if dmarc.org wanted to turn the protocol over to the IETF,
give IETF change control, and propose it for the standards
track, we would be having a different discussion.   And I assume
that many of us would join in trying to insist that
standards-track publication not occur without at least a clear
set of health warnings and possibly modifications to other
protocols and procedures to contain the damage.

> Of course a line has to be drawn somewhere; the IETF can't
> possibly respond to every single stupid thing that people do
> on the Internet. But when three of the largest MSPs in
> existence decide to publish problematic DMARC policies and
> large numbers of email receivers have implemented DMARC
> checks,  resulting in widespread damage, and subsequently
> refuse to reconsider those policies, I think the line was
> crossed.

Suppose I agree (I've got mixed feelings about that, but set
them aside).  IETF participants can discuss the issue using IETF
facilities.  That has been happening and I certainly don't
object to it.  However, for the IETF to actually recommend an
action requires that we have a document and some sort of
community consensus.  To my best recollection, we've never said
"don't use that" or "use that only this way" to something that
was not an IETF (or predecessor)-developed protocol without
providing a substitute.  If people want to do the work and there
is any hope of adoption, I'd be in favor of a DMARC2 effort in
the IETF.  

Of course, if "three of the largest MSPs in existence decide to
publish problematic DMARC policies" that result in advantages to
them but cause harm to others, that could also be interpreted in
other ways that are outside IETF scope and should stay that way. 
 
>> to me that it does not exist in the IETF.

> The "new protocol" of which you speak is, in fact, a
> combination of three pieces: DMARC, SPF, and DKIM. Two of
> thoese are standards-track protocols, and one of those (SPF)
> has a built-in policy mechanism which, if used, most assuredly
> does "impose costs on operators of other systems".
> 
> And as I noted above, it's not like the IETF didn't publish
> ADSP on the standards track, or that this usage of DKIM was a
> surprise.
> 

Or that the IESG and the community were not paying sufficient
attention.  I would agree if you said "that is no excuse", but
it calls the way we do some sets of protocols like this into
question.
 
>...
>> > Doing nothing will result in a mix of three reactions.  1,
>> > ML admins changing the From: of domains who publish strict
>> > DMARC policies;  2, some users changing mailbox provider;
>> > and 3, less domains publishing strict DMARC policies.
> 
> report policy errors. Or 5. Rather than unsubscribing the
> failing recipients, either ignore the error or report the
> failures to the original message sender, thus making it clear
> to them the cost they're paying for the provider they have
> chosen.
> 
> Except in order to do either of these well you need some
> additional status codes, codes which only the IETF can assign.
> (And yes, I'm aware that a ML can perform its own check on the
> From: domain and if it lists a reject policy refuse the mail,
> thus avoiding the need for new error codes. Except that's both

Agreed.

> The good news, such as it is, is that the relevant registry is
> "Specification Required", meaing this can be done in the DMARC
> base specification or some other informational RFC. Which I
> guess would avoid significant IETF involvement.

Yes.
 
>> There are two more options you didn't mention: (4) more
>> systems either not implementing DMARC or ignoring strict
>> policy specifications, and (5) driving some users and
>> activity away from the use of mailing lists entirely in favor
>> of using more "social network" web sites and activities.  I
>> note that some people believe that DMARC and strict policies
>> are part of a business model to force that result.  I don't
>> believe that personally, but the optics are unfortunate.
 
> I'll note that "ignoring stricy policy specifications" is not
> necessarily a good thing. Having a DMARC failure contribute to
> an overall spam score can easilt lead to mail being silently
> lost instead of being rejected, with all that implies.

Yes (and see below).
 
>> The analogy is obviously not exact, but, if some external
>> group came up with a protocol that weakened TCP and
>> undermined all of our congestion control mechanisms, we might
>> be pointing out the damage and encouraging people to not use
>> that protocol -- perhaps even figuring out ways to block its
>> use -- but would not be scurrying to alter TCP to better
>> accommodate the behavior of that new protocol, especially if
>> the alterations made "normal" use of TCP less efficient or
>> effective.
> 
> On the contrary, if the protocol that external group came up
> with was widely deployed and there were reasonable tweaks that
> could make them coexist, I think that's exactly what the
> Transport Area would do.

It would be an interesting experiment in some ways.  Beyond
that, we'd have to get down to what tweaks (and by whom) would
be considered reasonable.

Disclaimer: As you know, but other readers may not, I've got an
extremely bad attitude toward mail changes that, in the interest
of mitigating delivered spam, violate the basic design
assumptions of Internet email or reduce its functionality.  That
is undoubtedly affecting my attitude toward this situation even
though it probably shouldn't.

    john

---

From: "John Levine" <[email-masked]>
Date: 15 May 2014 04:03:19 -0000

>lost, whereas at least "reject" provides an indication that something went

Discardable was supposed to be a feature, to avoid backscatter, and on
the theory that if the mail is that awful, the sooner it goes away the
better.  Given the current DMARC fiasco, I'd say it was not a bad
choice.  I pointed out at the time that "discardable" did not mean
your mail was important, on the contrary it meant that your mail was
unusually unimportant, since you were telling people to throw it away
if there were any doubt about it.

>was in any way unexpected. As such, there was at least a responsibility to

Well, I tried.  I shoehorned my way into the ADSP draft because I
anticipated almost exactly the problems with ADSP that we're seeing
with DMARC.  The other authors didn't disagree, but did say that they
wanted each domain to be able to publish its own policy.  I thought
that was a lousy idea, because I saw no reason to expect that domain
owners would publish reasonable policies, but instead would tend to
publish overly strict policies in the mistaken belief they were "more
secure".  I turned out to be right, since around the time that ADSP
was published, some subscriber to IETF lists published a discardable
policy, which was wrong, and someone else overimplemented ADSP with
rejections rather than discards, which was really wrong, and the
latter group promptly bounced themselves off the IETF list.

What I said at the time was that rather than ADSP, you wanted credible
third parties publishing lists of domains for which strict ADSP-like
behavior was appropriate.  That's exactly what happened--look inside
spamassassin and you'll find a module nominally about ADSP, but with
the real ADSP checks turned off by default and a short list of fake
ADSP entries for the usual suspects, ebay, paypal, etc.

The only thing I got wrong was that I expected the damage to come from
large numbers of small clueless operators publishing strict policies,
like a flock of tiny gorillas beating their wee chests and shouting
"Fear us, O Internet!" in high squeaky voices.  It never occurred to
me that two of the largest and most sophisticated mail operators in
the world would do such a thing.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Thu, 15 May 2014 08:46:20 -0400

> the world would do such a thing.

And this is how we design protocols in the IETF.  The saga continues...

-- 
HLS

---

From: Dave Crocker <[email-masked]>
Date: Thu, 15 May 2014 08:13:05 -0700

(What follows makes no comment on the appropriateness or efficacy of the
recent expansion of DMARC usage.  Rather, what follows comments on the
discussion within the IETF about it.)

One of the problems with reactive policy development is that is tends to
be driven more by emotion than actual principle.  Rationales tend to be
convenient, rather than careful.

What results starts to look more like Procrustean, religious dogma,
rather than pragmatic technical consideration.  As a community
developing technical details, the IETF has a good track record.  As a
religion, no to much.

So we are seeing some odd claims...

> needed and appropriate. 

  1.  Protocols do not impose costs.  Some /uses/ of them might, which
is the choice of those deploying them to that effect.

      Used in the original scenario for which it was developed, DMARC
only imposes costs on those choosing to adopt it.  That largely remains
true even for the expanded application we've just seen.  Those most
affected are users of operators choosing to expand the usage of DMARC.

  2.  There is nothing that requires mailing lists to make adjustment.
Arguably, it is better for mailing lists NOT to make adjustments, so
that those affected users can consider the efficacy of their current
account.

  3.  The discussion here is consistently confusing the difference
between the protocol, DMARC, versus some recent applications of it, and
confuses the work of dmarc.org with the independent decisions of
specific email operators.

      Further, note that the problems with the recent uses were
extremely well-understood beforehand. In other words, those making the
recent usage choices did so aware of the implications.  The IETF has no
obvious leverage over operational organizations that make such decisions.

> weaken DMARC to the degree necessary 

This postulates a power struggle between the IETF, versus those deemed
by the IETF to be misbehaving.  It's difficult to imagine the IETF being
effective with such an approach.

>>   DMARC did not

Perhaps folk should review Thaler's RFC 5218, What Makes for a
Successful Protocol?  In effect, it documents that (at least recent)
IETF successes primarily come from efforts that began outside the IETF.

So the DMARC effort derives from significant prior IETF work and, by the
way, was subject to an effort to bring it into the IETF.

The core problem with the considerable effort made at bringing DMARC
into the IETF was that, in spite of repeated efforts in multiple venues,
there was no consensus developed in the IETF about technical work to do.

Also note that a draft BCP was posted, has been repeatedly referenced,
and yet folk seem more intent on complaining about DMARC than working on
practical documentations like the BCP.

>> track, we would be having a different discussion. 

What a wonderfully revisionistic assertion, given that such an effort
was made, over a six month period.

And to anticipate the inevitable fault-finding responses, please
consider whether it really is unreasonable for operators having made
recent and substantial investments in deploying a new technology to
resist a demand that they encourage a de-stabilizing change process that
imposes no constraints on what can be changed or why.

Further revisionism happens when it is claimed that the IETF doesn't
accept new technology that comes with constraints on changes permitted
for the initial IETF work on the technology.

> damage by withdrawing or adjusting the protocol itself. 

The curious premise to this claim is that the IETF's 'withdrawing' a
protocol carries leverage that will cause major operators to stop using
it, independent of those operators' own assessment of efficacy.

There's also the ironic theme running through this thread that the IETF
doesn't do normative work relating to specifications it does not
directly control.

The irony within this thread, of course, is unicode.  Other examples
about, but that one is particularly amusing.

> proposing that as a work item for some existing WG or a new WG.

+1

Except that that point seems to contract some of the others made in this
thread, by the same speaker and possibly even in the same posting...

> been no effort to obtain IETF consensus 

Again, that's not correct.

There's real technical work to be done in this space.  It's probably not
as much fun as complaining about the situation, but it would be quite a
bit more useful for the community.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 16 May 2014 15:48:34 +0200

> that those affected users can consider the efficacy of their current

I'm disappointed.  I know p=reject, like dkim=discardable before it,
was meant to be used by domains that "don't have individual human
users".  I cannot help comparing it to SPF's -all.  In fact, DMARC's
overview[1] suggests that the monitoring step be followed by policy
adjustment.  Looking at DMARC reports, one can guess whether an
authentication failure originates from abuse or from a possibly
forwarded mailing list post.  Setting a strict policy would kill both.
 OTOH DMARC is perfectly useless with p=none.

What does it take to set up a "human" domain, then?  It's way harder
than a web site.  Several organizations give up working out their own
way to configuring a mail server.  Google do an excellent job at
filtering.  Besides marking as spam and email authentication, they
deploy literally hundreds of signals, whose relative importance is
dynamic and determined on complex algorithms[2], which are definitely
beyond the reach of an average company with a smallish IT dept.

Now, being forced to outsource email has obvious privacy issues.  I
want to ask whether the onset of giant, all-monitoring, central email
plants is part of "the basic design assumptions of Internet email".
If not, we ought to consider putting the restoring of a well-defined,
simple email functionality among the Internet 2020 goals.  Can DMARC
generalization be regarded as a spontaneous move in that direction?
It requires adjustments in mailing lists and other niches such as WSJ
send-an-article and gmail sending.  But what are the alternatives?

Ale

[1] How Senders Deploy DMARC in 5-Easy Steps, bottom section in
http://www.dmarc.org/overview.html

[2] summary of a talk with Sri Somanchi on Gmail's Anti-Spam Team
http://www.campaignmonitor.com/blog/post/4196/gmail-focus-on-engagement

---

From: Hector Santos <[email-masked]>
Date: Fri, 16 May 2014 16:24:27 -0400

Alessandro,

There is still a status quo between the two different camps; one that 
believes in a policy framework and one that doesn't. It really has 
nothing to do with technical issues because they all has been already 
worked out. But rather an unwillingness to even acknowledge policy 
existence.

That approach has not worked and it was predictable because it was 
always a fallacy to believe that strict policies were limited to 
certain use cases and certain domains. It provided a flawed rationale 
and basis to allow DKIM resigning by ignoring policy with the 
acceptability of a limited damage.

The DKIM RFC6376 preferred method of looking up the signer domain has 
simply failed to materialize in the market place.  And even if it did, 
it would still not address the filtering of the obvious protocol 
expected faults resulting from legacy mail operations and adapting 
spoofers.  In other words, via policy, if you raise the "expectation bar":

    Does this domain send any mail?
    Does this domain always sign its own mail?
    Does it allow others to sign freely?
    Does it allow authorized resigners?

The first two could be ignorant spammers who don't have a clue about 
new 5321/5322 methods. Its getting by with a legacy SMTP mode of 
operation.   The last two helps to deal with those spammers that may 
adapt and try to "fake" out the receivers with unchecked DKIM signatures.

These and other similar questions are real DKIM situations the signer 
domain trust model can not answer.  You can only get this info from 
the author.  Even if the signer domain was used, it would need to 
still reflect the author domains intent and authorization for resigning.

None is this is new. Many documents were produced. But we didn't have 
the full IETF DKIM project leaders support and endorsement to finish 
up ADSP.  Levine refused to fix/update ADSP despite all the interest 
to do so.  It was an unfortunate mistake for the DKIM WG chairs and 
Ads to allow this lack of ADSP engineering leadership situation to 
occur.  The chairs and ADs were clearly aware there was a concern and 
also the threat of appeal.

Anyway, the available solution is still very simple. Given all the 
work already explored, DMARC needs an ATPS extension.  ATPS piggy back 
off the ADSP record.  We can just update ATPS to piggy back of the 
DMARC record.  I already started this using my idsg.net DMARC record:

_dmarc TXT ("v=DMARC1; p=reject; atps=y; rua=mailto:[email-masked];" )

The atps=y tag tells the compliant DMARC+ATPS receiver to do an 
authorized third party signature check against the DKIM-Signature "d=" 
signer domain.  I have an _atps record for ietf.org:

pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT	( "v=atps01; d=ietf.org;" )

So in theory, when ietf.org breaks and resigns my isdg.net list 
submissions, any download DMARC+ATPS receivers can see that isdg.net 
authorizes ietf.org to resign list mail from isdg.net.  I already 
began to modify our WCADSP Wizard web site for DMARC:

      http://winserver.com/public/wcdmarc

It is pretty much done with the backend scripts updated to create 
DMARC records. I am just playing/cleaning the FORM UI, single sourcing 
it for mobile/tablet UI.

Of course, it all means nothing without further support for ATPS.  It 
provides an OUT for YAHOO and AOL to get a resigner whitelist using 
ATPS records.  If they can support this simple extension to DMARC, 
then we would be headed in the right direction for all parties.  Even 
if the certain LIST operators continues to refuse to support policy, 
at the very least, the download receivers would be able to handle it 
better by checking for the list signer domain authorization.

Without the support, you can see the attached dmarc-gmail-warning.png 
image where the GMAIL mail reader (via my iPAD) shows a warning for 
the unauthorized 3rd party signature DMARC failure.  A simple ATPS TXT 
lookup for:

     base32(sha1("ietf.org"))._atps.isdg.net

would of addressed this problem.

---
HLS