Subject: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions Considerations For DMARC

From: Scott Kitterman <[email-masked]>
Date: Mon, 16 Sep 2013 19:45:44 -0400

The recent discussion about moving ADSP to historical brought up the issue of 
people being inadvertently unsubscribed from mailing lists due to rejecting 
mail that failed ADSP tests.

AIUI, the following would happen:

 - A user at a domain that signs DKIM and has an ADSP "discardable" policy 
published sends a mail to a mailing list.

 - Like most mailing lists, the mail gets munged and the signature is broken.

 - At the border MTA of the domain of a subscriber that checks ADSP, it is 
determined that the message fails ADSP and bounces/rejects it.

 - Rejects/bounces from this user accumulate in the list manager and 
eventually they get unsubscribed for excessive bounces.

There are arguably several things done wrong here:

 - Sending user: why are you sending mail to a ML with an ADSP protected 
domain.

 - Receiving border MTA: why are you bouncing/rejecting and not discarding?

So in theory, this should be fine, but it's not.  This (assuming I got it 
right) is one of the arguments for moving ADSP to Historic (since it's not 
only lightly used, it's known to cause damage when it does.

I got to thinking about this and asked myself how DMARC might be better in 
than ADSP in this situation, and as far as I can tell, it's not.  Most mailing 
lists use their own Mail From, so even if SPF passes on the mailing list 
message, it won't have identity alignment.

Did I miss something?

Scott K

---

From: Franck Martin <[email-masked]>
Date: Mon, 16 Sep 2013 19:04:57 -0500 (CDT)

----- Original Message -----
> From: "Scott Kitterman" <[email-masked]>
> To: [email-masked]
> Sent: Monday, September 16, 2013 4:45:44 PM
> Subject: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions	Considerations For DMARC
> 

Because you can... You can't control all your users and it is hard to know when an email address is the one of a mailing list...
As for the argument you should not put an ADSP on a domain with users, well, any domain from a targeted entity becomes eventually a target that needs protection too...

>  - Receiving border MTA: why are you bouncing/rejecting and not discarding?

Because they are told to do so by the policy, but with DMARC they can overwrite the result, while it is not possible with ADSP (see what is a mailing list question)

> message, it won't have identity alignment.

Yes, ;) 

Why the mailing list software would consider such a bounce as a hard bounce, while it is clearly not and identified as such with extended smtp error codes. For instance, EZMLM handles this better than Mailman by sending probes before unsubscribing members.

As a receiver, how do I know I'm dealing with a mailing list?

Why MLM have to break DKIM? It seems the lists at apache.org do not break DKIM on transit and do not suffer these problems.

I'm not trying here to provide answers but just describe the problem space.

---

From: Roland Turner <[email-masked]>
Date: Tue, 17 Sep 2013 10:50:32 +0800

>> mail that failed ADSP tests.

Time to rush in where angels fear to tread :-)

>> eventually they get unsubscribed for excessive bounces.

Yes, and much the same scenario can arise for DMARC.

> As for the argument you should not put an ADSP on a domain with users, well, any domain from a targeted entity becomes eventually a target that needs protection too...

+1

This is a domain-owner's choice. They take their chances with the 
consequences of course. What we're not able to do is provide a 
child-safe environment in which there are no trade-offs and where 
actions have no consequences.

>>   - Receiving border MTA: why are you bouncing/rejecting and not discarding?

This is not "wrong", as the spec acknowledges 
(draft-kucherawy-dmarc-base-01 
<http://www.ietf.org/id/draft-kucherawy-dmarc-base-01.txt> 15.4). There 
are strong arguments in favour of both SMTP refusal (5xx response) and 
silent discard (2xx response, then delete the message); different 
receivers will make different choices. This dilemma is part of why 
mailing lists complicate the "let's authenticate everything" desire that 
many people share.

Bouncing (2xx response, followed by generating and sending a new DSN to 
the RFC5321.MailFrom) arguably is wrong - or at least unwise - because 
it contributes to backscatter risk however, again, this is a receiver's 
choice and some receivers may still do this.

> Because they are told to do so by the policy, but with DMARC they can overwrite the result, while it is not possible with ADSP (see what is a mailing list question)

I don't think that was Scott's question; p=reject is a proposal by the 
domain owner to the receiver refuse/discard/bounce at receiver's 
discretion messages which fail both authentication methods. Scott 
appeared to me to be positioning anything other than silent discard as 
being "wrong" for p=reject. The DMARC spec makes clear that this is not so.

>> only lightly used, it's known to cause damage when it does.

Barry or Dave may correct me on this, but the argument for moving ADSP 
to historic is simply that its use is negligible (and perhaps that 
having it retain a standards status may lead unwitting implementers 
astray) and - in light of DMARC's adoption - unlikely ever to grow. 
There is _*more*_ harm in ADSP than in DMARC (because DMARC adds various 
protective and softening mechanisms: rua/ruf, p=quarantine, pct), but 
this is more the driver for the adoption of DMARC than the argument for 
moving ADSP to historic.

>> than ADSP in this situation, and as far as I can tell, it's not.

In the sense that DMARC provides rua/ruf to improve a domain owner's 
situational awareness and decision making, DMARC actually is 
[marginally] better than ADSP in this situation, however this is the 
wrong question. Interoperating with [existing] mailing lists is not part 
of the goals of either protocol, consequently the failure to do so is 
not a large concern.

It would be nice if it were straight-forward (or even possible) for this 
level of interoperability to exist, but no-one can currently see a way 
for this to work. This is largely because all technically viable 
approaches require all mailing list operators to implement them ahead of 
evidence that they're appropriate. Like everybody else, their budget for 
speculatively expending resources in the hope that they might fix other 
people's problems is rather small. The practical upshot is that any 
receiver implementing DMARC filtering requires an accurate database of 
mailing list servers which host lists to which the receiver's users are 
subscribed. This is untidy but workable and, again, is not a large 
concern because it doesn't impede DMARC's objective.

>>    Most
>> mailing

That's clever; I'd wondered how it was avoiding the problem.

> As a receiver, how do I know I'm dealing with a mailing list?

As part of your ongoing monitoring and assessing of mailstreams...

> Why MLM have to break DKIM? It seems the lists at apache.org do not break DKIM on transit and do not suffer these problems.

"Have to" is a bit strong, but see RFC 6377. To avoid DKIM breakage, a 
list must avoid doing _*all*_ of those things.

I'd suggest that there is a way forward and not too much need to worry 
about it:

  * In the short term, receivers are likely to need to maintain a
    database of list servers from which authentication failures can be
    ignored. It would be helpful for such receivers to report this to
    domain owners as reason={forwarded|trusted_forwarder|mailing_list}.
  * As receiver adoption proceeds, it may be the case that mailing-list
    mapping is of sufficiently low importance to enough receivers that
    list operators start to see real (rather than hypothetical) benefit
    in addressing this, in which case any of the following will work, at
    the list operator's discretion:
      o Leave the message sufficiently unaltered to still pass DKIM
      o Replace the RFC5322.From with something that points to the list
        operator
      o Reject submissions from domains with p=reject (or reject only
        those where the list's changes break the DKIM signature on the
        message in question; noting that the signer determines what is
        signed and therefore a given message's DKIM signature may break
        for a given list, where others' wouldn't)

As with domain-owner use of p=reject on domains that aren't heavily 
spoofed, or even the potential use of DMARC filtering by a receiver 
without a mailing-list/forwarder database, the use or not of the 
practices above by list operators should be positioned as "here's a way 
to make this work if you wish to" not "you are irresponsible if you 
don't do this".

- Roland

---

From: Matt Simerson <[email-masked]>
Date: Mon, 16 Sep 2013 18:49:32 -0700

+1

> Why MLM have to break DKIM?

They don't. (Rhetorical question, I know.)

> It seems the lists at apache.org do not break DKIM on transit and do not suffer these problems.

Most everyone on this list knows, but I'll state once more for the archives:

Passing DKIM signed messages through mailing lists without invalidating the DKIM signature typically requires just two config changes to the mailing list: disable subject prefixes and cease adding list footers.

List footers typically have list info and sub/unsub instructions appended to every message. This is typical on EZMLM lists and less so on Mailman lists, which instead send a list reminder email to the participants once a month. 

Subject prefixes rewrite the Subject: line, inserting the list name:

  Subject: [list-name] Why do mailing lists break DKIM?

Matt

---

From: Roland Turner <[email-masked]>
Date: Tue, 17 Sep 2013 12:28:45 +0800

On 09/17/2013 08:04 AM, Franck Martin wrote:

>> From: "Scott Kitterman"<[email-masked]>
>> To:[email-masked]

+1

- Roland

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 17 Sep 2013 00:33:40 -0400

On Tuesday, September 17, 2013 10:50:32 Roland Turner wrote:
> >> The recent discussion about moving ADSP to historical brought up the
> >> issue of people being inadvertently unsubscribed from mailing lists due
> >> to rejecting mail that failed ADSP tests.
> 
> >>   - A user at a domain that signs DKIM and has an ADSP "discardable"
> >>   policy published sends a mail to a mailing list.
> >> 
> >>   - At the border MTA of the domain of a subscriber that checks ADSP, it
> >>   is determined that the message fails ADSP and bounces/rejects it.
> >> 
> > Because you can... You can't control all your users and it is hard to know
> > when an email address is the one of a mailing list... As for the argument
> > you should not put an ADSP on a domain with users, well, any domain from
> > a targeted entity becomes eventually a target that needs protection
> > too...
> +1

Sure.  I only mention that because some people's answer is that 
adsp=discardable or dmarc p=reject is only for domains without actual users 
(.e.g transactional mail).

> actions have no consequences.

Email authentication is only for domains that don't need mailing lists?  
Personally, I've got no problem with an SPF -all record.  I've had one since 
2004.  OTOH, p=reject would be very problematic.  I don't have a lot of 
personal correspondence in my local domains with people using services that 
are providing bulk feedback reports.  Something more than 99% of the traffic I 
see in my reports in mailing list traffic.

> mailing lists complicate the "let's authenticate everything" desire that

We're in the middle of the ADSP part of the argument here and it was written 
differently.  Personally, I find silent discards to be abhorrent.  They 
interfere with the reliability and consistency of the mail system, but that's 
perhaps just me.  I certainly won't argue for them.

> choice and some receivers may still do this.

Too much of this and they'll find their bounces get them blacklisted.

> > Because they are told to do so by the policy, but with DMARC they can
> > overwrite the result, while it is not possible with ADSP (see what is a
> > mailing list question)

No.  Here I'm still talking about ADSP.  It's similar to, but not identical to 
DMARC.

> this is more the driver for the adoption of DMARC than the argument for

I think the potential for harm is identical.  If it's concerning for ADSP, it 
should be concerning for DMARC.  DMARC does have a few more knobs to turn, but 
if you don't want mail that fails authentication sent to the receiving user, 
you have to use p=reject and that has the exact same problem with mailing list 
subscriptions that ADSP does.

> of the goals of either protocol, consequently the failure to do so is

Ah, so DMARC is only for domains without real users?

> concern because it doesn't impede DMARC's objective.

Workable for who?  Probably for large providers that can do it via data 
mining.  I don't even know all the mailing lists I'm subscribed to let alone 
everyone who uses my domains.

> >>    Most mailing
> > Why the mailing list software would consider such a bounce as a hard
> > bounce, while it is clearly not and identified as such with extended smtp
> > error codes. For instance, EZMLM handles this better than Mailman by
> > sending probes before unsubscribing members.
> > Why MLM have to break DKIM? It seems the lists at apache.org do not break
> > DKIM on transit and do not suffer these problems.

DKIM came out in 2007.  I'm subscribed to dozens of mailing lists and I can 
think of two that don't break DKIM signatures (and not even this one).  I 
think the idea that mailing lists are going to do anything more for DKIM than 
add their own signatures is wishful thinking, certainly not supported by my 
experience.

I don't have a good solution either, but I'm also not convinced with what 
looks to me like a lot of handwaving.  We KNOW it was a problem with ADSP and 
while I really like things about DMARC like the feedback mechanisms, I don't 
think it's meaningfully different from ADSP in this regard and it will somehow 
have to be addressed.

Scott K

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 18 Sep 2013 00:24:42 +0200

> On Tuesday, September 17, 2013 10:50:32 Roland Turner wrote:

[...]

> perhaps just me.

You're not alone on this one: silently discarding mail cannot be 
explained to the ordinary end-user of the e-mail eco-system. See [1] and 
various opinions in [2]. RFC5321 section 6.2 addresses these concerns as 
follows:

    As discussed inSection 7.8  <http://tools.ietf.org/html/rfc5321#section-7.8>  andSection 7.9  <http://tools.ietf.org/html/rfc5321#section-7.9>  below, dropping mail
    without notification of the sender is permitted in practice.
    However, it is extremely dangerous and violates a long tradition and
    community expectations that mail is either delivered or returned.  If
    silent message-dropping is misused, it could easily undermine
    confidence in the reliability of the Internet's mail systems.  So
    silent dropping of messages should be considered only in those cases
    where there is very high confidence that the messages are seriously
    fraudulent or otherwise inappropriate.

Apart from some corner cases (small organizations) neither sending mail 
eco-system nor receiving mail eco-system is able to adequately and 
reliably determine which messages are handled by a MLM and which are 
not. And even if one finds a way to determine this, it certainly will 
not be scalable to the entire Internet. With that in mind, the question 
is: is option 2 of par 15.4 of the DMARC base spec ('silent discard') 
contradicting the above quoted principle as stated in RFC5321, or not?

>    I certainly won't argue for them.
>

Correct.

> everyone who uses my domains.

+1.

> think it's meaningfully different from ADSP in this regard and it will somehow

As ADSP has been adopted by the IETF as standards track document, the 
question is: are there any new insights/ regarding this problem in 
relation to DMARC? If not, it makes little sense redoing the entire 
MLM/ADSP discussion for MLM/DMARC?

Don't get me wrong: in my opinion new standards have to interoperate 
with the current Internet, so the existence of MLM's and the way most of 
them operate at this moment, can't be ignored. Using special domains for 
'DMARC signed mail' to prevent damage may be a good advise, but 
companies may want to 'protect' their main (and most well-known) 
domains, with which they also send transactional and IPM as well.

Then the next question is: is it worth standardizing DMARC within the 
IETF? Obviously it already is a _de facto_ standard, why should we aim 
at making it a _de jure_ standard as well?

I for myself have not yet found the answer to this question.

/rolf

[1] 
http://www.macworld.com/article/2029570/silent-email-filtering-makes-icloud-an-unreliable-option.html
[2] http://www.webhostingtalk.com/showthread.php?t=1227028

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 17 Sep 2013 20:02:59 -0400

"Rolf E. Sonneveld" <[email-masked]> wrote:
>As discussed inSection 7.8 
><http://tools.ietf.org/html/rfc5321#section-7.8>  andSection 7.9 
><http://tools.ietf.org/html/rfc5321#section-7.9>  below, dropping mail
>>>>> right) is one of the arguments for moving ADSP to Historic (since
>it's
>>>>> not
>>>>> I got to thinking about this and asked myself how DMARC might be
>better
>>>>> in
>>>      domain owners as
>reason={forwarded|trusted_forwarder|mailing_list}.

I think DMARC is widely enough used that it's worth documenting.  Along with that, I think it is critical to give operators guidance about the risks associated with p=reject for different domain usage patterns. 

Scott K

---

From: Matt Simerson <[email-masked]>
Date: Tue, 17 Sep 2013 18:27:14 -0700

+1

Matt

---

From: Roland Turner <[email-masked]>
Date: Sun, 22 Sep 2013 22:02:23 +0800

> (.e.g transactional mail).

Understood, but note that talking about what DMARC (or ADSP) "is for" is 
ambiguous and leads to a lot of heat as people vigorously talk past each 
other. It can refer to at least:

  * What problem DMARC was designed to [and does] help solve.
  * What other situations DMARC can be used in.
  * What other situations DMARC can be used in without causing serious
    collateral damage.

Depending upon the context, these three meanings (and perhaps others) 
give rise to multiple distinct positions; overlooking the ambiguity in 
the term creates considerable confusion.

> Email authentication is only for domains that don't need mailing lists?

I didn't say anything like that.

> see in my reports in mailing list traffic.

Apologies, I don't follow how this bears on the discussion.

> No.  Here I'm still talking about ADSP.  It's similar to, but not identical to

On re-reading I see that, but note that it's still relevant for the next 
step in your argument ("asked myself how DMARC might be better in than 
ADSP in this situation, and as far as I can tell, it's not"): DMARC does 
not require silent discard.

> should be concerning for DMARC.

DMARC has similarities with ADSP, but as you acknowledge above, it's not 
the same. The differences are material.

> DMARC does have a few more knobs to turn, but

Noting that we're talking about a very narrow situation (and yes, now 
that I look at it, your choice of Subject: points this out) that both 
ADSP and DMARC authors accept is beyond their reach (both protocols are 
expected to reduce the problems that they address, not to magically 
solve them without side-effects), meaning that the broader argument is 
not being addressed:

  * DMARC provides domain owners with visibility of this situation ahead
    of a decision to switch on p=reject, ADSP does not. This materially
    changes the situation. It allows a domain owner to make informed
    choices, rather than guess, to plan appropriate trade-offs, to
    monitor the situation on an ongoing basis and to discover unexpected
    consequences as and when they arise.
  * DMARC makes concrete (through override reasons of forwarded,
    trusted_forwarder and mailing_list) reasons for receiver's
    discretion which ADSP did not. As a practical matter the exercise of
    discretion is required in either case, but DMARC raises it to a
    recognised element of the protocol rather than an invisible activity.

So, even for the narrow situation that you're asking about, DMARC does 
considerably better than ADSP.

> Ah, so DMARC is only for domains without real users?

As above, you're falling into the ambiguity around "is for" (the 
different meanings listed above lead to different answers to your question).

> everyone who uses my domains.

The "data mining" isn't all that difficult: mailing list servers stick 
out like a sore thumb (moderate to high sustained message volume, very 
low spam rates, very high authentication failure rates), are small in 
number and move rarely if at all. For receivers too small to perform 
even this level of analysis I'd suggest that the analytics required are 
simpler than are required to, for example, maintain an IP address 
blocklist, so there's an opportunity for reputation services to help 
small receivers sort this out.

I am interested to understand whether you're proposing a specific 
improvement; are you?

> add their own signatures is wishful thinking, certainly not supported by my

Agreed. As I said, "As receiver adoption proceeds, it may be the case". 
It would be wishful thinking to assume that this was going to happen, my 
point was simply that it need not be a concern.

> think it's meaningfully different from ADSP in this regard and it will somehow

The feedback mechanism materially changes the situation. It's analogous 
to the difference between sailing an ocean-going ship equipped only with 
a compass ("keep sailing west, we'll hit Canada eventually") and sailing 
one equipped with a GPS receiver (accurately following a series of 
waypoints that can't be directly perceived by human senses); they're 
both sailing, but the risks are drastically reduced when you have feedback.

The underlying "problem" (widespread, reasonable behaviour of mailing 
list operators) isn't going away any time soon. Until/unless mailing 
list operators see benefit in expending resource to help the process run 
more smoothly, it's unreasonable to expect them to do so; conseqiently 
my money is on receivers working out how to deal with this and, perhaps, 
reputation services helping smaller receivers to make better decisions.

- Roland

---

From: Roland Turner <[email-masked]>
Date: Sun, 22 Sep 2013 22:20:11 +0800

On 09/18/2013 06:24 AM, Rolf E. Sonneveld wrote:

> RFC5321 section 6.2 addresses these concerns as follows:
>
> Apart from some corner cases (small organizations) neither sending 
> mail eco-system nor receiving mail eco-system is able to adequately 
> and reliably determine which messages are handled by a MLM and which 
> are not. And even if one finds a way to determine this, it certainly 
> will not be scalable to the entire Internet. With that in mind, the 
> question is: is option 2 of par 15.4 of the DMARC base spec ('silent 
> discard') contradicting the above quoted principle as stated in 
> RFC5321, or not?

The DMARC spec does not stipulate how a receiver is to implement 
rejection. 15.4 does discuss the trade-off. It might be appropriate to 
insert references to the document sections that you point out.

> MLM/ADSP discussion for MLM/DMARC?

There is no reason to redo the discussion.

> with the current Internet, so the existence of MLM's and the way most 
> of them operate at this moment, can't be ignored. Using special 
> domains for 'DMARC signed mail' to prevent damage may be a good 
> advise, but companies may want to 'protect' their main (and most 
> well-known) domains, with which they also send transactional and IPM 
> as well.

This would be a desirable additional benefit of DMARC adoption. It would 
appear that it rests critically upon how receivers go about dealing with 
mailing lists, which for smaller receivers probably means whether viable 
reputation services appear.

> I for myself have not yet found the answer to this question.

People with a longer experience with IETF process may offer a better 
answer, but I'd suggest RFC 2026 
<https://www.rfc-editor.org/rfc/rfc2026.txt> 4.1.1 offers an approach:

> A Proposed Standard specification is generally stable, has resolved
> known design choices, is believed to be well-understood, has received
> significant community review, and appears to enjoy enough community
> interest to be considered valuable.  However, further experience
> might result in a change or even retraction of the specification
> before it advances.

It would appear that DMARC meets this with room to spare. Barry has 
already stated what additional input he's seeking, but the community 
interest test would appear to be the one relevant to your question and 
I'd suggest that it's been more than met.

- Roland

---

From: Roland Turner <[email-masked]>
Date: Sun, 22 Sep 2013 22:21:22 +0800

On 09/18/2013 08:02 AM, Scott Kitterman wrote:

> I think DMARC is widely enough used that it's worth documenting. Along 
> with that, I think it is critical to give operators guidance about the 
> risks associated with p=reject for different domain usage patterns.

+1

- Roland

---

From: Dave Crocker <[email-masked]>
Date: Sun, 22 Sep 2013 07:34:45 -0700

> Email authentication is only for domains that don't need mailing

The question jumps from the specifics of DMARC (or DKIM or SPF) into a 
much, much more general point.  The problem with any logic that might be 
trying to justify that generality here is that these bits of technology 
offer very specific /kinds/ of email authentication.  In fact as we keep 
seeing, the distinctive nature of their specific authentications is 
often missed by folk.

In other words, an assessment of any one (or even all 3) of these 
doesn't permit making the more general assessment about any and all 
forms of email authentication.  (Nor do I read Roland's text as having 
attempted that.)

> <https://www.rfc-editor.org/rfc/rfc2026.txt> 4.1.1 offers an approach:

(Just for clarity, the IETF does not produce "de jure" standards.  It 
has no enforcement authority, which is what is meant by the term.  Note 
the opening paragraph to RFC 2026, which cites "voluntary adherence". 
These days, it's perhaps classed as "formal", but that's quite different.)

/Why/ a group wants to pursue IETF standardization is a meta-question 
that, frankly, the IETF itself doesn't really doesn't answer, except 
perhaps indirectly.  Referring again to RFC 2026, the last paragraph in 
Section 1.1:

      "In general, an Internet Standard is a specification that is stable
    and well-understood, is technically competent, has multiple,
    independent, and interoperable implementations with substantial
    operational experience, enjoys significant public support, and is
    recognizably useful in some or all parts of the Internet."

So I'd say that a good motivation for seeking IETF standardization to 
obtain this formal assessment.  In other words, it further vets an 
existing specification, as well as essentially handing change control 
for the specification over to the IETF.  (This latter point doesn't 
actually require standardization, but it is a real side-effect.)

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 23 Sep 2013 23:14:31 +0200

On 09/22/2013 04:34 PM, Dave Crocker wrote:
> much, much more general point.  The problem with any logic that might 
> be trying to justify that generality here is that these bits of 
> technology offer very specific /kinds/ of email authentication.  In 
> fact as we keep seeing, the distinctive nature of their specific 
> authentications is often missed by folk.
>
> has no enforcement authority, which is what is meant by the term.

There seems to be quite some controversy about the terms "de jure" and 
"de facto", see for example:

http://electronicdesign.com/embedded/what-s-difference-between-de-jure-and-de-facto-standards

including the Discussion that follows the article. It was not my 
intention to start a discussion here on these words, so I apologize for 
having used this terminology.

>   Note the opening paragraph to RFC 2026, which cites "voluntary 
> adherence". These days, it's perhaps classed as "formal", but that's 
> quite different.)

Please note that more and more governments create lists of standards, 
which must be used by these government's agencies and organizations, 
when building new IT solutions, purchasing new software etc. [1]. Quite 
a number of these standards are IETF standards. See [2], [3] and [4]. 
With that in mind, the IETF standards become more and more 'mandatory' 
(to not use the word "de jure") to use for many organizations worldwide. 
I have been involved in submitting DKIM for the Dutch list 'Comply or 
Explain' and I can assure you that it definitely makes a difference when 
a standard is an IETF standard or not. This is due to the criteria that 
are used (open standardization process, decisions by consensus, publicly 
available etc.).

> perhaps indirectly.  Referring again to RFC 2026, the last paragraph 
> in Section 1.1:
>

Apart from stable and well-understood, all of these characteristics 
already apply to DMARC. In addition to that I doubt whether the 
individual submission with AD sponsorship will aid in improving the 
understanding of the protocol, or in gaining significant public support.

> actually require standardization, but it is a real side-effect.)

The good thing of standardization of DMARC within IETF, IMHO, is that in 
the long term it will improve stability of the standard, which is due to 
the fact that change control is handed over to the IETF. So basically 
I'm in favour of standardizing DMARC within the IETF, but I hope the 
chosen path will not minimize the influence that IETF can have on this 
standard, as there seems to be only one 'Last Call' between the 
DMARC-as-it-is-now and the IETF standard DMARC (or will there be more 
moments that consensus is sought?).

/rolf

[1] 
http://en.wikibooks.org/wiki/FOSS_Open_Standards/Government_National_Open_Standards_Policies_and_Initiatives
[2] http://dre.pt/pdf1sdip/2012/11/21600/0646006465.pdf (Portugese)
[3] 
http://www.computerweekly.com/blogs/public-sector/2011/10/open-standards-uk-dithers-whil.html
[4] 
https://lijsten.forumstandaardisatie.nl/lijsten/open-standaarden?lijst=Pas%20toe%20of%20leg%20uit&status[]=Opgenomen&pagetitle=pastoeof 
(Dutch)

---

From: Dave Crocker <[email-masked]>
Date: Mon, 23 Sep 2013 14:34:50 -0700

> http://electronicdesign.com/embedded/what-s-difference-between-de-jure-and-de-facto-standards

I don't think there is much 'controversy' at all, actually, although 
it's clear there is some confusion, with some folk.  The article itself 
seems in line with my own comment, as does the discussion comment after 
the article.

> Please note that more and more governments create lists of standards,

Indeed they do, but that doesn't automatically make the standard de 
jure.  A government can be a customer, like any other.  Customers have 
requirements.

Rather, as the article explores, de jure standards are required by 
actual law or regulation a government purchasing requirements list 
doesn't rise quite that high -- not just for use by the body making the 
requirement, such as the government for itself, but for use by others.

> (to not use the word "de jure") to use for many organizations worldwide.

A highly successful de facto standard gets that way incrementally, by 
many independent decisions.  After a while, yes, it takes on a degree -- 
possibly a very high degree -- of obligatory use, possibly even embodied 
in regulation.  At that point, one can refer to a de facto standard's 
having become de jure, I suppose.

The important point for work in the IETF is that there is /never/ any 
guaranteed success.  For each piece of work we do, we have to target 
success by incremental adoption, through many independent decisions. 
This is fundamentally different from knowing that a spec will get used 
because there is a legal regulation demanding it.

All work in the IETF is delivered with the goal of achieving de facto 
acceptance.  /Eventual/ de jure status is just icing on the success cake.

> already apply to DMARC.

Well, there's the fact of those condition, but there is a separate 
question of their perception.  Evaluation by the IETF can constitute a 
presumably rigorous and independent review for those characteristics.

> In addition to that I doubt whether the

Possibly they can and will.  Possibly they can and will improve the 
document writing.  Additional reviews often produce surprising results. 
  I'm not expecting anyone to come up with a surprising flaw in the 
protocol, but I don't have any trouble believing the document can be 
improved.  Most specs documents can benefit that way.

d/

---

From: SM <[email-masked]>
Date: Mon, 23 Sep 2013 15:10:37 -0700

Hi Rolf,
At 14:14 23-09-2013, Rolf E. Sonneveld wrote:
>Please note that more and more governments create lists of 
>standards, which must be used by these government's agencies and 
>organizations, when building new IT solutions, purchasing new 
>software etc. [1]. Quite a number of these standards are IETF 
>standards. See [2], [3] and [4]. With that in mind, the IETF 
>standards become more and more 'mandatory' (to not use the word "de 
>jure") to use for many organizations worldwide. I have been involved 
>in submitting DKIM for the Dutch list 'Comply or Explain' and I can 
>assure you that it definitely makes a difference when a standard is 
>an IETF standard or not. This is due to the criteria that are used 
>(open standardization process, decisions by consensus, publicly 
>available etc.).

Agreed.

The regulatory framework works differently in some jurisdictions.  It 
is easier to get a specification adopted when it is an IETF standard.

Regards,
-sm