Subject: Re: WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc)

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Jul 2014 10:31:23 -0700

On 7/14/2014 9:42 AM, The IESG wrote:
> A new IETF working group has been proposed in the Applications Area. The
> IESG has not made any determination yet. The following draft charter was
> submitted, and is provided for informational purposes only. Please send
> your comments to the IESG mailing list (iesg at ietf.org) by 2014-07-24.

The first paragraph of a charter is circulated independently of the
rest, such as when announcing the working group.

As such, it needs to serve as a kind of abstract.  This is why there is
a requirement, specified in RFC 2418 (WG Guidelines & Procedures),
"Description of working group:

     "The first
      paragraph must give a brief summary of the problem area, basis,
      goal(s) and approach(es) planned for the working group..

>  Charter:
> 
>    Domain-based Message Authentication, Reporting & Conformance (DMARC)
>    uses existing mail authentication technologies (SPF and DKIM) to
>    extend validation to the RFC5322.From field. DMARC uses DNS records
>    to add policy-related requests for receivers and defines a feedback
>    mechanism from receivers back to domain owners. This allows a domain
>    owner to advertise that mail can safely receive differential
>    handling, such as rejection, when the use of the domain name in the
>    From field is not authenticated. Existing deployment of DMARC has
>    demonstrated utility at internet scale, in dealing with significant
>    email abuse, and has permitted simplifying some mail handling
>    processes.
> 
>    The existing base specification is being submitted as an Independent
>    Submission to become an Informational RFC.
> 
>    However, DMARC is problematic for mail that does not flow from
>    operators having a relationship with the domain owner, directly to
>    receivers operating the destination mailbox. Examples of such
>    "indirect" flows are mailing lists, publish-to-friend functionality,
>    mailbox forwarding (".forward"), and third-party services that send
>    on behalf of clients. The working group will explore possible updates
>    and extensions to the specifications in order to address limitations
>    and/or add capabilities. It will also provide technical
>    implementation guidance and review possible enhancements elsewhere in
>    the mail handling sequence that could improve could DMARC
>    compatibility.

The DMARC draft charter's first paragraph does not state any goals.
This can be fixed by moving the last two sentences of the third
paragraph, to the end of the first.

That is, end the first descriptive paragraph with:

  "The working group will explore possible updates
  and extensions to the specifications in order to address limitations
  and/or add capabilities. It will also provide technical
  implementation guidance and review possible enhancements elsewhere in
  the mail handling sequence that could improve could DMARC
  compatibility.

and delete it from it's current position.

>    References
>    ----------
> 
>    DMARC - http://dmarc.org
>    SPF - RFC7208
>    DKIM - RFC6376
>    Internet Message Format - RFC5322
>    OAR / Original Authentication Results -
>       draft-kucherawy-original-authres
>    Using DMARC -  draft-crocker-dmarc-bcp-03

This is missing two citations that I thought were supposed to be
included, since they touch on indirect email flows:

   Delegating DKIM Signing Authority - draft-kucherawy-dkim-delegate-00
   DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 14 Jul 2014 16:47:19 -0400

>    DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03

If we're adding references, I think RFC 7001,  Message Header Field for 
Indicating Message Authentication Status, should be included as well.  It's, I 
think a matter for the WG to decide if RFC 7001 provides enough or if an 
extension like OAR is needed.

Scott K

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Jul 2014 00:15:49 +0000

> > >    the mail handling sequence that could improve could DMARC

This is a solved problem, the "Rfc822.Sender" field should have
from the outset trumped the "Rfc822.From" field when determining
message origin, and the DMARC policy should be that of the "Sender"
domain.  Some MUAs already expose "Sender != From" by displaying
"From <sender> on behalf of <author>".  This needs to become standard
MUA behaviour.

-- 
	Viktor.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 14 Jul 2014 18:20:35 -0700

> "From <sender> on behalf of <author>".  This needs to become standard

Viktor,

You are right, but this provides a domain not always seen by recipients.  Only the From header field is surely displayed.  

The TPA-Label scheme can permit exceptions for specific domains and require Sender header field/source-alignment as a means to avoid spoofing.  The burden of making exceptions is carried by the DMARC domain within a single, small, and cacheable DNS transaction.  While it is a minor change to include display of Sender header fields, its alignment is normally ignored.  Its display might invite confusion or spoofing when necessary source alignment is not confirmed.

Even if the DMARC could assert Sender header field alignment has priority over that of the From, recipients would still not know which to trust.  While such a scheme might be simpler to manage, the TPA-Label scheme offers an agile transitional strategy for both Sender header fields as well as new authentication schemes, such as those enabled by DANE. 

Regards,
Douglas Otis

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Jul 2014 01:33:08 +0000

On Mon, Jul 14, 2014 at 06:20:35PM -0700, Douglas Otis wrote:

> You are right, but this provides a domain not always seen by
> recipients.  Only the From header field is surely displayed.

That means that some corner cases will remain unsolved until MUAs
evolve to catch up.  Pretending there is no elephant in the room
is a poor long-term strategy.

Work to improve the deficient MUAs.

-- 
	Viktor.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 14 Jul 2014 22:11:58 -0400

> "From <sender> on behalf of <author>".  This needs to become standard

I am coming around to the point of view.

FWIW, the text is from the proposed charter, I didn't write any of it.

Scott K

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Jul 2014 03:33:47 +0000

> I am coming around to the point of view.

Thanks for the moral support.  Message origin is subtle business.
In addition to "Sender" which is used by mailing lists and other
proxy agents, there is also "Resent-From" and friends.  I am rather
partial to "forwarding" messages not in-line or as attachments,
but as "resent" messages.

MUAs should expose message origin when different from author.

> FWIW, the text is from the proposed charter, I didn't write any of it.

Yes, of course.

-- 
	Viktor.

---

From: t.p. <[email-masked]>
Date: Tue, 15 Jul 2014 09:06:55 +0100

----- Original Message -----
From: "Viktor Dukhovni" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 15, 2014 4:33 AM

Viktor,

A fine idea, but, as a pragmatic engineer, I know that changes to an MUA
will take five, may be ten, years to achieve widespread deployment,
whereas changes to MTA could happen in a matter of weeks, if needs must.

Tom Petch

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Jul 2014 11:20:23 +0000

> whereas changes to MTA could happen in a matter of weeks, if needs must.

We could have started 5 years ago.  Better late than never.  The
problem being tackled has no instant gratification solutions.
Pretending the problem is simpler than it is has a way of coming
back to bite you.  I've always held that no amount of sender origin
authentication will save the clueless from themselves, any real
protection is at the gateway, and the gateway sees all the headers.

In the mean-time "citibank.com.dukhovni.org" will look plausible
enough to the helpless and will not be foiled by DMARC.

The expedient approach has not worked, it should have been done right
long ago, and should still be done right in the present.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 15 Jul 2014 15:44:18 -0000

> Some MUAs already expose "Sender != From" by displaying

Perhaps not.  This is the "punt security policy to Grandma" model.  A
more extreme version is the proposal to show signed and unsigned parts
of messages in different colors.

It would have been nice if users and MUAs had done this all along and
there were widely understood conventions (as opposed to well
documented but not well understood) conventions for using Sender:
headers.  But there aren't.  The most popular MUA that shows the
sender is Outlook, and people I know just find it confusing.

You and I probably have the background to make useful decisions from
various combinations of sender and author.  But I don't see any reason
to believe that non-technical users (in my case, Grandma is my wife's
74 year old mother) do.

R's,
John

---

From: [email-masked]
Date: Tue, 15 Jul 2014 08:12:16 -0700 (PDT)

> long ago, and should still be done right in the present.

You know, I'm finding it difficult to argue with this.

I've long been a supporter of using From/Sender semantics, but I've also bought
into the assumption that current client behavior made use of these semantics
problematic.

But current client behavior also includes, in many cases, showing personal name
information and not addresses. Which renders the entire from domain
authorization check approach moot.

This has led people to suggest that we need to do something about validating
personal name information in From: header fields. This, along with all the
various schemes that are being proposed to work around the myraid issues with
third party message handling, increasingly looks to me like a tottering edifice
built of hack piled on hack piled on hack.

I think that at a minimum any change we propose needs to be compared against
the alternative of using the semantics defined for email 30+ years ago.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Tue, 15 Jul 2014 09:21:29 -0700

>>>> MUAs should expose message origin when different from author.
...
>>> whereas changes to MTA could happen in a matter of weeks, if needs must.
...
> You know, I'm finding it difficult to argue with this.

I'm not.

1. For one thing, I don't know what the reference to 'expedient
approach' means.  Mostly this thread seems to be making very generic,
simple assumptions and assertions about problems and remedies.  Without
specific details on what problem is to be solved, what use cases it will
satisfy, and why we should believe they will work, the thread is not
likely to be constructive.

2. References to changes in MUA appear to be pointing to assumptions
about efficacy of what is displayed to users.  Such assumptions are
empirically incorrect, and mostly serve to demonstrate why the IETF is
the wrong place for discussion about UI/UX/UCD and human usability
issues.  Really, the disconnect between that one assumption and what is
actually known about email user behavior is fundamental.

3.  Nonetheless, the language in the draft charter provides for the
possibility of making incompatible changes to DMARC.  However it
requires /very/ careful documentation of the basis.  See #1, above.

> into the assumption that current client behavior made use of these semantics

Cleaning up From:/Sender: semantics and usage is a worthy goal, as is
generally developing a much cleaner model of identifying and
authenticating the various actors involved with a message.

But it's not likely to have much to do with DMARC, anytime soon.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 15 Jul 2014 12:35:08 -0400

> to believe that non-technical users (in my case, Grandma is my wife's

That's possibly true, but given the goal of the working group, it may turn out 
to be the best we can do.  In my limited IETF experience, I've seen several 
variants of "we aren't U/I experts, so we should stay away from it".  That may 
be true, but we may not get out of this one without having to give some strong 
guidance.

For the large fraction of email users today that are doing it via webmail 
where the service provider controls the MUA experience directly, the timeline 
for improvement can be relatively short compared to traditional software 
deployment cycles.

Scott K

---

From: Christian Huitema <[email-masked]>
Date: Tue, 15 Jul 2014 18:00:14 +0000

> This has led people to suggest that we need to do something about validating personal 
> name information in From: header fields. This, along with all the various schemes that 
> are being proposed to work around the myriad issues with third party message handling, 
> increasingly looks to me like a tottering edifice built of hack piled on hack piled on hack.

Of course people will suggest that we validate the personal name information. Because at the end of the day, spoofing is trying to make me believe that the message comes from "my friend Viktor" when in fact it does not. We may have perfect SPF, DKIM, DMARC and what have you, and still get spoofed messages "From: Viktor Dukhovni <[email-masked]>." 

At that point, either people pay attention to domain names or they don't. If they do, presenting "from" and "sender" like Outlook does works fine. If they don't, as in the "punt security policy to Grandma" argument, then we need the system to validate information passed to the user. Maybe do some automated check against the address book, or maybe rely on PGP or S-MIME. But we definitely need to ask the question as "what's the best way to stop phishing attempts," not just "how to ensure that SMTP works as specified."

-- Christian Huitema

---

From: [email-masked]
Date: Tue, 15 Jul 2014 10:22:57 -0700 (PDT)

> likely to be constructive.

It should go without saying that the context here isn't what's been said on
this specific thread, but rather all of the past exchanges here and on any
number of other lists leading up to this point. Among other things this
includes the posting of several drafts offering concrete proposals.

Both the problem and solution space have been explored in some depth, albeit
rather haphazardly. And while it may be the case that a novel solution will
emerge that blows everything else away, since I've seen that happen exactly
twice in the past 25 years, I'm not betting the farm on it happening here.

> actually known about email user behavior is fundamental.

I've been letting this set of assertions float by unchallenged for a long time,
in part because the effort needed to change dogmatic beliefs is considerable,
and in part because like most dogma, there's a kernel of truth buried inside.

This seems like as good a time as any to stop doing that. So: This is little
more than pernicious nonsense.

First, this is essentially a strawman. We're not talking about dictating UI
design here. What we're talking about are the semantics and general handling
requirements for some of the most basic protocol elements in email.

Nobody is saying that we should start specifying what has to be diplayed to
users, let alone how. But saying something like, "From tells you who wrote the
message, sender tells you who sent it if that's someone different, and here are
the various problems that can occur if you fail to take that into account ..."
strikes me as entirely reasonable to say.

For heaven's sake, we have as a process _requirement_ that we provide
security considerations for the stuff we standardize. On what planet does
the failure to make the security semantics and consequences of mishandling
them make sense?

There's also running code in this area: RFC 2049 specifies user agent handling
requirements for MIME conformance. To the extent these have been followed - 
and I admit there's an issue with our ability to affect change in this regard -
I know of no deleterious effects this has had. Nor can I recall any serious
criticisms having been leveled at the document.

Indeed, in hindsight, we didn't go far enough in specifying what conformant
handling of MIME should be, and we've paid the price for that in a variety of
ways.

Finally, there's also a issue with the continued assertion - which AFAIK is
backed up with not one scintilla of evidence - of the total lack of IETF
expertise in UI design. But since that's not relevant here, I'll leave that for
another exchange.

> requires /very/ careful documentation of the basis.  See #1, above.

True, but beside the point. The point, at least from my perspective, is the one
I made before: At a minimum any scheme that's produced needs to be compared
against the prospect of a proposal built around embracing the full semantics of
the relevant fields.

> But it's not likely to have much to do with DMARC, anytime soon.

I've yet to see any evidence that anything being proposed will have any effect
on DMARC in the short term. I've heard a bunch of assertions that if the need
arose MTA changes can be rolled out quickly. I have 25+ years of experience
doing this stuff that says otherwise.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 15 Jul 2014 12:02:02 -0700

> for improvement can be relatively short compared to traditional software

Do we have any reason to believe that such advice would be read by anyone
in a position to bring about its implementation?  How much do MUAs apply,
as Ned cited, RFC2049?

Whatever each of us thinks of our collective UI expertise is unimportant if
MUA developers will end up disregarding our advice and following their own
anyway.

As I've said before, perhaps we should try to encourage major MUA
developers to participate.  That would allay all such concerns.  We might
even get Sender to matter again.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 15 Jul 2014 12:10:35 -0700

> Work to improve the deficient MUAs.

I'd love to hear suggestions about how the IETF can do that.

I think, questions of expertise aside, MUA developers simply don't engage
here [anymore] and follow different paths or time scales than we do most of
the time.  This obvoiusly limits our solution space to what operators can
do, because they're here.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 15 Jul 2014 19:49:05 -0000

>Of course people will suggest that we validate the personal name information. Because at the end of the
>day, spoofing is trying to make me believe that the message comes from "my friend Viktor" when in fact it
>does not. We may have perfect SPF, DKIM, DMARC and what have you, and still get spoofed messages "From:
>Viktor Dukhovni <[email-masked]>." 

You know, that's what S/MIME with signed certificates is supposed to
do.  It's widely supported in MUAs and, well, meh.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 15 Jul 2014 15:57:08 -0400

> even get Sender to matter again.

Different MUA vendors are, of course, different.  Many of the major DMARC 
participants are also MUA vendors, so I have hope.  

There are a number of useful features that seem to resist implementation.  My 
MUA of choice has an amazingly useful "reply to list" feature that uses the 
relevant header fields to detect a list and reply to it.  I can't imagine using 
an MUA that doesn't have it.

It would probably be helpful to have an up to date survey of the MUAs to see 
which display Sender and which don't.  I remember back when we were doing 
MARID, as an example, Outlook displayed it, but Outlook Express did not.  Such 
a survey would give us some idea about how big the problem space is.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Tue, 15 Jul 2014 13:44:56 -0700

> more than pernicious nonsense.

Incurring the considerable expense, in people and opportunity cost, by
pursuing a global standards effort that proves ineffective is a
particularly pernicious path, especially with respect to a
security-related topic like phishing.

So, when offering my dogma on this topic, I usually make a point of
tossing in some lingo as a touchstone to the expertise of the topic; I
usually also offer an example of a poor design assumption.  My usual
reference for the latter is that discussions here tend to be predicated
on the assumption that presenting users with more information is always
a good thing.

All of this is by way of indicating that it's not actually dogma.  On
the average, the point is missed, as seems to have been here. (See below.)

But since it's all just dogma, I should stop listening to the folks that
work in the HCI and Usability disciplines, like any conference on the
topic and discourses by folk such the Nielsen Norman Group, such as:

   User Education Is Not the Answer to Security Problems
   http://www.nngroup.com/articles/security-and-user-education/

(The 'Norman' is Don Norman.  I certainly hope than anyone claiming
knowledge in this space knows his name and how it is relevant to this
discussion.  Nielsen is no slouch either...)

or at CUPS:

   http://cups.cs.cmu.edu/

such as their discussion of:

   Teaching Usable Privacy and Security: A guide for instructors
   http://cups.cs.cmu.edu/course-guide/#cm-interaction

As for dogma, does this mean that:

   a) As a community, the IETF /does/ have solid technical competence in
user-related security design?  Given that the state of the art --
nevermind the state of the deployed industry -- is notably poor in
usable security, perhaps the IETF has been hiding insights in this
space?  Perhaps someone can provide the basis for a claim that the IETF,
as a community, does have the competence to specify details of end-user
experience?

   b) Relying on recipients to make informed security decisions based on
vetted From: fields really is the answer to stop phishing.

Typically, when a proposal is made to do something that will be useful,
the burden is on the proponent to substantiate a claim of efficacy.
Perhaps I missed it, but that affirmation seems to be missing here.

> requirements for some of the most basic protocol elements in email.

And here we have what is a pretty typical demonstration of missing the
point about the topic.  UI design is the details of the user interface
design; where things go on the screen, for example.

By contrast, UX is the broader flow of user/computer semantics for an
application or service.

Sorry, but every time someone makes a reference to presenting
information to users, they are dictating UX and relying on its efficacy
for security enforcement.

> users, let alone how.

The notes from Viktor and Scott (and most -- but not all -- people who
are DMARC advocates) is that users will make useful security decisions,
if the right information is presented to them.

Assertions of what should be presented to users is /exactly/ the
predicate to this sub-thread.  That's why I've pointedly advised that,
instead, the target should be the receiving abuse filtering engine.

d/

ps.  Perhaps folk can get back to offering comments on the draft DMARC
charter?

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 16 Jul 2014 00:20:16 +0000

> security-related topic like phishing.

Is there quantitative evidence that preventing spoofing of the
"From" address reduces the efficacy of phishing?  My guess is that
any such effect is rather marginal, and that phishers succeed or
fail based on the content of the pitch, rather than "metadata".

-- 
	Viktor.

---

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

> fail based on the content of the pitch, rather than "metadata".

Dear Viktor,

One of the major proponents for DMARC, in an industry closed meeting, made an impressive presentation showing their costs related to phishing.  The major component was customer attrition following each extensive phishing campaign.  DMARC started out as private agreements with large providers.  It was felt publishing these requests in DNS would provide better coverage and it has.

This was never about reducing losses due to fraud, it was about a pragmatic effort to protect their customer base.  People want to be able to trust the From header field, and would walk away from email related services when they couldn't.  The PRA algorithm promoted by Sender-ID never effectively mitigated phishing.  With DMARC and simply sorting messages based on trusted From header fields offered customers a tolerable solution.

DMARC is a good solution for domains only sending transactional messages by combining both SPF and DKIM into a scheme that offers reliable delivery while also ensuring rejection of invalid sources.  This scheme falls apart when applied against domains handling normal email.  Even so, some domains have seen their user accounts repeatedly compromised and were hoping to leverage DMARC's benefit of being relied upon to reject invalid sources. 

Unfortunately, such an effort must rely on feedback offered to DMARC domains otherwise its rejections become too disruptive to be relied on.  Only the DMARC domain is able to share this information with recipients.  In some cases, this involves third-party back-office services that offer source alignment with the Sender header field.  Even in this case, it is still the From header field the recipient will recognize and wish to trust.

The TPA-Label scheme is able to convey informally federated domains as determined by feedback given to the DMARC domain.   TPA-Label is also able to indicate alignment requirements for Sender and List-ID to give recipients trustworthy sorting options.

Regards,
Douglas Otis

---

From: "John Levine" <[email-masked]>
Date: 16 Jul 2014 03:39:49 -0000

>"From" address reduces the efficacy of phishing?

According to people I've talked to at large mail providers, apparently
so.  DMARC blocks a lot of mail that is clearly phish.

I would have thought that phishers would use any of the bazillion
obvious ways to circumvent DMARC, but they must be as lazy as anyone
else.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 15 Jul 2014 23:55:42 -0400

On Tuesday, July 15, 2014 13:44:56 Dave Crocker wrote:
> > I've been letting this set of assertions float by unchallenged for a long
> > time, in part because the effort needed to change dogmatic beliefs is
> > considerable, and in part because like most dogma, there's a kernel of
> > truth buried inside. This seems like as good a time as any to stop doing
> > that. So: This is little more than pernicious nonsense.
> 
> > design here. What we're talking about are the semantics and general
> > handling requirements for some of the most basic protocol elements in
> > email.

I think, despite all your assertion by distant authorities, it may be that 
something involving U/I requirements (not design, I agree that's out of scope) 
may be part of the least bad solution we have to the problems the WG is going 
to be chartered to solve.

I'm not saying it is certain to be in the solution scope, but it shouldn't 
require a recharter if it turns out to be the case.  I don't like any of the 
possible solutions so far (including adding U/I requirements).  I'm not 
prejudging anything, I just don't want to prematurely preclude options.

So this is still a discussion about the charter and what should be in scope.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Tue, 15 Jul 2014 21:55:00 -0700

> to be chartered to solve.

1. What sort of 'proximity' do you require, before you can be swayed by
authoritative information?

2. By 'least bad', it appears that you mean it is ok to standardize
something that is known not to work, to the extent that the end user is
expected to be part of the decision process.

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 16 Jul 2014 05:31:50 +0000

> so.  DMARC blocks a lot of mail that is clearly phish.

That's not the question I'm asking.  Spamhaus RBLs, also block lots
of mail that is phish.  The real question is whether the incidence
of successful phishing attacks is reduced.

> obvious ways to circumvent DMARC, but they must be as lazy as anyone

Which means that perhaps they don't need to bother, because they
are getting sufficient response rates?

-- 
	Viktor.

---

From: "Niels Dettenbach (Syndicat IT&Internet)" <[email-masked]>
Date: Wed, 16 Jul 2014 08:28:07 +0200

>> >"From" address reduces the efficacy of phishing?

At the time it is no good idea to hardly block mails with senders which seem "spoofed" (i.e. by SPF, DKIM, DNSSEC, MX and/or "similiar") because there is still to much ham in the world affected by that and as long as such solutions are not widely established spammers/hackers find enough alternatives.

And even if the address is "hardly bound" to a MTA by any solution -  we see still scenarios in practice working around that - i.e. by tricking / using the "true" mailserver i.e. by  web hijacking or client bots with access to them.

cheerioh,

Niels.
-- 
Niels Dettenbach
Syndicat IT&Internet
http://www.syndicat.com

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 16 Jul 2014 10:23:58 +0200

On Tue 15/Jul/2014 19:22:57 +0200 Ned+ietf wrote:
> I've yet to see any evidence that anything being proposed will have
> any effect on DMARC in the short term. I've heard a bunch of
> assertions that if the need arose MTA changes can be rolled out
> quickly. I have 25+ years of experience doing this stuff that says
> otherwise.

I fully agree.  However, it is the converse statement --evidence that
DMARC will have any effect on reclaiming semantics of the most basic
protocol elements in email-- which is intriguing.

If you pardon my oversimplifying, recipient semantics is well
established by SMTP.  Defining the meaning of the domain requires DNS
write access, while the local part's meaning is local.  DMARC can be
seen as an attempt to reestablish the same in From:, conditioning
deliverability to its enforcement like in the previous case.

Thus far, DMARC is a private agreement which works reliably only with
direct mailing, where it is backed up by SPF.  DKIM is afflicted by a
fierce crowd of breakage forms, which nobody seems to be interested in
as they occur sporadically in the current use case.  The challenge is
to see its much trumpeted bet on multi-hop tolerance.  IMHO, there
lies the worthiness of the proposed WG.

Ale

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 16 Jul 2014 07:49:57 -0400

>expected to be part of the decision process.
DMARC is already fielded and being standardized. Much of the work of this WG is about mitigating the side effects of this. So in this case, least bad solution still wins (which may be write a BCP and declare victory,  I don't know).

DMARC itself is already known not to work for common standard mail flows.  This is an effort that is devoid of solutions that don't have at least some significant downside. The working group is going to have to figure out which downside hurts the least. 

Scott K

---

From: t.p. <[email-masked]>
Date: Wed, 16 Jul 2014 15:31:55 +0100

----- Original Message -----
From: "Scott Kitterman" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, July 16, 2014 4:55 AM
Subject: Re: not really to do with Re: WG Review: Domain-based Message
Authentication, Reporting & Conformance (dmarc)

<snip>
> may be part of the least bad solution we have to the problems the WG
is going

I agree.  I think that the IETF is competent to specify what a user
should see, just not how to see it.  Thus we could require that the
user's attention is drawn to a difference between From: and Sender:, or
that a field has been authenticated to some level or has failed
authentication and so on.

As to how, I was watching the Tour de France transit Yorkshire and was
reminded that, to a Frenchman, a waved yellow flag means danger, whereas
the locals probably saw it as a friendly greeting; that is the sort of
UI, transferred, conceptually, to the screen of an MUA, that I do not
think the IETF has expertise in.

Tom Petch

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Jul 2014 12:21:23 -0700

(re-posted under my ietf-dmarc subscription address, rather than ietf
one.  content otherwise the same.  /d)

     "The first

d/

---

From: Hector Santos <[email-masked]>
Date: Wed, 16 Jul 2014 11:30:18 -0400

> On Jul 16, 2014, at 7:49 AM, Scott Kitterman <[email-masked]> wrote:
> 
>> expected to be part of the decision process.s

-1.  The simplest solution has always been the policy lookup with the language to support all the boundary conditions.  This is the most feasible protocol complete solution.  The policy themselves, which must be all honored for this to work, will vary in effectiveness, it's payoff.  The more relaxed, the greater the redundancy and waste you have in the process. The higher the strength, the higher the payoff, including the pains of restricting the resigner who wishes to continue to exist in the blind.  The problem is not in the concept, but that DMARC was never protocol complete. Its reporting offered the "confirmation" for the proof of concept, but it was done on the basis that "no one" will ever enforce this stuff.

The resistance seems to be a learning and "big data" problem among the fewer but larger ESP.  This should be a separate WG or DKIM data work.

This small group already seems to have lost the focus of what the problem always was and the 9 years of vested R&D.   Work thrown out by a very unpopular rough consensus was wrong in their mail operations presumptions.  At the very least, the charter should revisit the threat analysis RFC and the functional requirement RFC to see where it went wrong and corrections are made.  I maintained the 1st vs 3rd party corollary added in rfc5016, section 5.3 item 10, created the genesis of the conflict we have today.  This problem will not go away until we confront this conflict.

--
Hector Santos
http://www.santronics.com

---

From: Hector Santos <[email-masked]>
Date: Wed, 16 Jul 2014 12:51:44 -0400

>   DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03

Why not ATPS RFC6541 production?

http://tools.ietf.org/html/rfc6541

Consider ATPS the "lite version" of Doug's TPA. The same lookup hashing algorithm is used in both.  Further, there is real high quality commercial "running code" implementations supporting rfc6541.  All of our installations have DKIM+ADSP+ATPS out of the box with their primary domain used for automated first time setup plug and play readiness.

---

From: Pete Resnick <[email-masked]>
Date: Wed, 16 Jul 2014 12:42:31 -0500

Folks, can I ask that you please remove [email-masked] from the recipient 
list if you want to have discussion that doesn't pertain to the charter 
itself.

I'm hoping to recruit a prospective chair in the next few days to start 
moderating the discussion on the DMARC list itself while we're still 
dotting i's and crossing t's of the charter. I'm happy to have 
free-wielding discussion go on a bit, but please let's try and keep it 
to a dull roar while we're getting organized.

Thanks.

pr

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

---

From: S Moonesamy <[email-masked]>
Date: Wed, 16 Jul 2014 11:30:42 -0700

Hello,
>A new IETF working group has been proposed in the Applications Area. The

[snip]

>    email abuse, and has permitted simplifying some mail handling

There are some mail services who provide mailboxes with mailing lists 
impediments.

>    Submission to become an Informational RFC.

In a message dated April 22, I commented as follows:

   Section 16 describes IANA registry updates.  I suggest contacting the
   IETF Application Directors for information about the procedure to be
   followed for the registry updates.

My reading of the sentence about "Informational RFC" (quoted above) 
is that the IESG concluded that the base specification can be 
published without any changes (see Point 4 or 5 in BCP 92).

>    the mail handling sequence that could improve could DMARC

The above is well-written.

>    Specifications produced by the working group will ensure preservation
>    of DMARC utility for detecting unauthorized use of domain names,
>    while improving the identification of legitimate sources that do not
>    currently conform to DMARC requirements. Issues based on operational
>    experience and/or data aggregated from multiple sources will be given
>    priority.
>
>    The working group will seek to preserve interoperability with the
>    installed base of DMARC systems, and provide detailed justification
>    for any non-interoperability. As the working group develops solutions
>    to deal with indirect mail flows, it will seek to maintain the
>    end-to-end nature of existing identifier fields in mail, in
>    particular avoiding solutions that require rewriting of originator
>    fields.

The last paragraph above sets a high bar for changes.  As a note, 
some mailing lists have already implemented a "via" rewrite.

>    Working group activities will pursue three tracks:
>
>       1. Addressing the issues with indirect mail flows
>
>    The working group will specify mechanisms for reducing or eliminating
>    the DMARC's effects on indirect mail flows, including deployed
>    behaviors of many different intermediaries, such as mailing list
>    managers, automated mailbox forwarding services, and MTAs that
>    perform enhanced message handling that results in message
>    modification. Among the choices for addressing these issues are:
>
>       - A form of DKIM signature that is better able to survive transit
>         through intermediaries.
>
>       - Collaborative or passive transitive mechanisms that enable an
>         intermediary to participate in the trust sequence, propagating
>         authentication directly or reporting its results.

What is the meaning of "collaborative or passive transitive mechanisms"?

>       - Message modification by an intermediary, to avoid authentication
>         failures, such as by using specified conventions for changing
>         the aligned identity.
>
>    Consideration also will be given to survivable authentication through
>    sequences of multiple intermediaries.
>
>       2. Reviewing and improving the base DMARC specification

This is going to be a lot of (IETF) work and there will likely be 
vigorous discussions.

>    The working group will not develop additional mail authentication
>    technologies, but may document authentication requirements that are
>    desirable.
>
>    The base specification relies on the ability of an email receiver to
>    determine the organizational domain responsible for sending mail.  An
>    organizational domain is the 'base' name that is allocated from a
>    public registry; examples of registries include ".com" or ".co.uk".
>    While the common practice is to use a "public suffix" list to
>    determine organizational domain, it is widely recognized that this
>    solution will not scale, and that the current list often is
>    inaccurate. The task of defining a standard mechanism for identifying
>    organizational domain is out of scope for this working group. However
>    the working group can consider extending the base DMARC specification
>    to accommodate such a standard, should it be developed during the
>    life of this working group.

I'll defer to the DNS experts on the matter of the "public suffix".

>    Improvements in DMARC features (identifier alignment, reporting,
>    policy preferences) will be considered, such as:
>
>       - Enumeration of data elements required in "Failure" reports
>         (specifically to address privacy issues)
>       - Handling potential reporting abuse
>       - Aggregate reporting to support additional reporting scenarios
>       - Alternate reporting channels
>       - Utility of arbitrary identifier alignment
>       - Utility of a formalized policy exception mechanism
>
>
>       3.  DMARC Usage
>
>    The working group will document operational practices in terms of
>    configuration, installation, monitoring, diagnosis and reporting. It
>    will catalog currently prevailing guidelines as well as developing
>    advice on practices that are not yet well-established but which are
>    believed to be appropriate.
>
>    The group will consider separating configuration and other deployment
>    information that needs to be in the base spec, from information that
>    should be in a separate guide.
>
>    Among the topics anticipated to be included in the document are:
>
>       - Identifier alignment configuration options
>       - Implementation decisions regarding "pct"
>       - Determining effective RUA sending frequency
>       - Leveraging policy caching
>       - Various options for integrating within an existing flow
>       - Defining a useful, common set of options for the addresses to
>         which feedback reports are to be sent
>       - When and how to use local policy override options
>
>
>    Work Items
>    ----------
>
>    Phase I:
>
>       Draft description of interoperability issues for indirect mail
>       flows and plausible methods for reducing them.
>
>    Phase II:
>
>       Specification of DMARC improvements to support indirect mail flows
>
>       Draft Guide on DMARC Usage
>
>    Phase III:
>
>       Review and refinement of the DMARC specification
>
>       Completion of Guide on DMARC Usage

 From what I read "the working group charter MUST establish a 
timetable for specific work items".  The message does not mention any 
timetable.  In my opinion it will take many years to deliver all the 
work items.

The proposed working group will be working on a guide in Phases II 
and III.  My quick reaction would be to defer that work to after the 
specification has been done.

One question that I thought about is whether the work is doable.  In 
my opinion, what is being proposed is too much.  I am taking into 
consideration the administrative overhead which is not visible to the IETF.

Regards,
S. Moonesamy

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Jul 2014 16:01:23 -0700

> There are some mail services who provide mailboxes with mailing lists

Yes, but how does (or should) your comment affect the draft charter text?

> My reading of the sentence about "Informational RFC" (quoted above) is
> that the IESG concluded that the base specification can be published
> without any changes (see Point 4 or 5 in BCP 92).

The draft charter text only notes the fact of submission and says
nothing about the further processing that has, might or will take place.
 The IESG assessment is part of the 'will'.

> The last paragraph above sets a high bar for changes.  As a note, some
> mailing lists have already implemented a "via" rewrite.

Yes, it does set a high bar.

As for actions already taken by some operators, those certainly should
provide interesting input for consideration.  However the mere fact of
those choices having been made does not mean that they are preferred or
even useful.  That's what the working group will (I hope) consider.

> What is the meaning of "collaborative or passive transitive mechanisms"?

Yes, it's a challenge to figure out how to word that concisely and
helpfully, given that the charter has already been criticized for being
too long.

So, the intent of the phrase is to distinguish between mechanisms that
might provide author-to-recipient utility, either due to a
'collaborative' effort by both the author's operator and the
intermediary, or solely by the author's operator, with the intermediary
instead being 'passive'.

An example would be a mechanism that requires the intermediary to add
its own signature, versus one that might survive the intermediary, even
without the intermediary taking special action.

> I'll defer to the DNS experts on the matter of the "public suffix".

That's the intent of the charter, except to the extent that the dmarc wg
might develop some useful input to a separate public suffix effort.

d/

---

From: S Moonesamy <[email-masked]>
Date: Wed, 16 Jul 2014 17:20:04 -0700

Hi Dave,
>Yes, but how does (or should) your comment affect the draft charter text?

I did not suggest any change to that text.  I expressed an opinion.

>  The IESG assessment is part of the 'will'.

I'll quote from 
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13031.html

   "Existing deployment of DMARC has demonstrated utility at internet
    scale"

If I am not mistaken implementers are encouraged to request IETF 
protocol parameters assignments before deploying them at internet 
scale.  In my opinion an IESG assessment would be useful as the IESG 
is chartering a working group about DMARC.  I am taking a previous 
(IESG) conflict review into consideration 
(conflict-review-masotta-tftpexts-windowsize-opt).

>even useful.  That's what the working group will (I hope) consider.

Ok.

>without the intermediary taking special action.

Thanks for the above explanation.

>might develop some useful input to a separate public suffix effort.

I'll say okay to this one.

Regards,
S. Moonesamy

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Jul 2014 17:32:17 -0700

On 7/16/2014 5:20 PM, S Moonesamy wrote:
> scale.  In my opinion an IESG assessment would be useful as the IESG is
> chartering a working group about DMARC.  I am taking a previous (IESG)
> conflict review into consideration

SM,

Unfortunately I think I'm more confused now.

The existing draft has been submitted independently.  As such it is not
part of the working group chartering process.  Any IESG activity, with
regards to the independent submission, is independent of this wg draft
charter.  The independent submission is mentioned in the draft charter
only as some convenient background.

With respect to protocol parameter assignments, you appear to be
suggesting that something is or has been problematic, but I can't tell
what it is.  In any event, are there changes to the draft charter that
you are suggesting?

d/

---

From: [email-masked] (Martin Rex)
Date: Thu, 17 Jul 2014 03:15:28 +0200 (CEST)

>Dave Crocker wrote:

>    "Existing deployment of DMARC has demonstrated utility at internet

I would propose to adjust this statement to better match reality.

>    "Existing deployment of DMARC has demonstrated moderate success
>    for some providers and some parts of the internet, and at the
>    same time interferes fatally with mailing list usage of
>    DMARC-affected EMail user accounts and mail forwarding.
>
>    But the by far most serious problem is that processing of EMail
>    according to DMARC by a telecommunicatios service provider
>    is a real and serious criminal offense in countries with strong
>    protections of fundamental human rights, such as many member
>    countries of the European Union, and this precludes that
>    DMARC could ever scale to the entire internet.

-Martin

---

From: Dave Crocker <[email-masked]>
Date: Wed, 16 Jul 2014 18:41:22 -0700

> I would propose to adjust this statement to better match reality.

DMARC is estimated to cover at least 60% of the world's mailboxes.

A number of major operator claim the DMARC has been quite helpful for
them.  (Yes, I've asked them to post some numbers.)

To the extent that you believe the current wording does not match
reality, please explain.  Please also proffer wording you consider better.

d/

---

From: [email-masked] (Martin Rex)
Date: Thu, 17 Jul 2014 04:20:28 +0200 (CEST)

> DMARC is estimated to cover at least 60% of the world's mailboxes.

That's an interesting number, but how was it computed/counted,
and what does it mean in reality.

When the @yahoo.com reject policy had been set up, I checked whether
I could send fake @yahoo.com Email to my private German (F)reeMail
account and to my own company email account, and both Emails were
properly delivered to my Mailboxes.

So even mails "allegedly" From: mailboxes for which the domain
owner has published DMARC reject policy will be (properly, due to
legal requirement) dysfunctional in non-marginal areas of the internet.
The same applies to the DMARC report policy, for which processing
by telecommunication providers will also be illegal (a serious
criminal offense) in countries with strong protections of
fundamental human rights.

-Martin

---

From: Randy Bush <[email-masked]>
Date: Thu, 17 Jul 2014 11:28:29 +0900

>    "Existing deployment of DMARC has demonstrated utility at internet

indeed it has, except in a negative sort of way.

randy

---

From: "John Levine" <[email-masked]>
Date: 17 Jul 2014 02:46:45 -0000

>and what does it mean in reality.

It certainly means Gmail, Yahoo, Hotmail, AOL, and all their various
hosted services such as AT&T ISP mail in the US, as well as giant US
cable ISP Comcast.

>properly delivered to my Mailboxes.

It's more popular among large providers than small ones.

R's,
John

---

From: S Moonesamy <[email-masked]>
Date: Wed, 16 Jul 2014 22:56:50 -0700

Hi Dave,
>what it is.  In any event, are there changes to the draft charter that

In my opinion the existing specification cannot be published through 
the Independent Stream because of the IANA Considerations section, 
i.e. it has to be sent to the IESG.  The Application Area Directors 
will have to decide what to do about the "Email Authentication 
Parameters" assignments as conflict of interest can be raised as an issue.

The proposed charter states that DMARC has been deployed.  The 
(proposed) working group discussions will have to take that into 
account and also refer to a DMARC specification as it is not being 
asked to design a protocol to solve one or more problems.  The 
(proposed) working group reviews the DMARC specification and finds 
out that the assignments have not been done.  The easy path would be 
to fix the IANA stuff and move forward.  Given that this is an 
email-related working group there is bound to be strong 
disagreement.  Process issues could be raised; I am not inferring 
that it is bad.  This is where one looks into whether there has been 
any arbitrary decision.

"Protocol parameter assignments" is about IETF policy; it is not 
DMARC specific.  It is related to the discussion on an IAB mailing 
list.  It can impact on future IESG decisions.

To be clear, I am not suggesting any text changes to the draft 
charter.  I commented as it looks like a matter for the IESG to consider.

Regards,
S. Moonesamy

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 Jul 2014 10:16:53 -0400

Hi, SM...

> If I am not mistaken implementers are encouraged to request IETF protocol
> parameters assignments before deploying them at internet scale.  In my
> opinion an IESG assessment would be useful as the IESG is chartering a
> working group about DMARC.  I am taking a previous (IESG) conflict review
> into consideration (conflict-review-masotta-tftpexts-windowsize-opt).

I don't se how that conflict review has anything to do with this at
all.  That conflict review response was about congestion issues that
might be caused by the protocol itself, and had nothing to do with any
protocol parameter assignments.

> In my opinion the existing specification cannot be published through the
> Independent Stream because of the IANA Considerations section, i.e. it has
> to be sent to the IESG.  The Application Area Directors will have to decide
> what to do about the "Email Authentication Parameters" assignments as
> conflict of interest can be raised as an issue.

The IANA Considerations section requests assignments into two "Expert
Required" registries and one "Specification Required" registry.  Those
registration policies exist *specifically* to allow registrations from
non-IETF documents, and they've been used many times for that.  The
DMARC base document certainly doesn't have to be sent to the IESG for
*that* reason.

As to the conflict of interest with respect to the designated experts,
1. I already plan to ask a stand-in reviewer, who does not have a
conflict, to serve as an expert for this document,
2. the IESG has already discussed that point informally, and thinks
that's a fine thing for cases such as this, where all the DEs are
closely involved with the document that's requesting registration, and
3. I've put text into the 5226bis proposal (which should be going into
last call any time now) to deal with this situation.

See <https://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/>,
the penultimate paragraph of Section 5.2.

Do you really think we're not on top of a situation such as this?

> The (proposed) working group reviews the DMARC
> specification and finds out that the assignments have not been done.

Why would that happen?  If it does, that'd be due to a problem between
IANA and the ISE, and such a problem hasn't happened yet.

> Process issues could be raised; I am not inferring that it is bad.  This is
> where one looks into whether there has been any arbitrary decision.

What appears arbitrary to you?

> "Protocol parameter assignments" is about IETF policy; it is not DMARC
> specific.  It is related to the discussion on an IAB mailing list.  It can
> impact on future IESG decisions.

What, exactly has that impact?  And what does this have to do with the IAB?

Barry, Applications AD

---

From: John C Klensin <[email-masked]>
Date: Thu, 17 Jul 2014 10:30:30 -0400

--On Thursday, July 17, 2014 02:46 +0000 John Levine
<[email-masked]> wrote:

> It certainly means Gmail, Yahoo, Hotmail, AOL, and all their
> various hosted services such as AT&T ISP mail in the US, as
> well as giant US cable ISP Comcast.
> 
>> When the @yahoo.com reject policy had been set up, I checked
>> whether I could send fake @yahoo.com Email to my private
>> German (F)reeMail account and to my own company email
>> account, and both Emails were properly delivered to my
>> Mailboxes.
> 

And maybe that statement covers another part of the issue.
Counting deployment numbers is legitimate, but the IETF has, at
least IMO, tended to avoid protocols that favor large providers
but hurt small ones (whether the "hurt" is technical, driving
costs up, or something else).   That may be especially important
in the email case because "small provider" includes not only
small multicustomer ISPs and ESPs, but a large number of
organizational, institutional, and corporate mail systems.  

To me, that makes decisions about damage-mitigation work for a
non-essential protocol complicated because one way to eliminate
the damage is to not support the protocol at all, possibly
including stripping its headers whenever they are encountered.

I don't want to try to do the WG's work at charter discussion
time, but I'd like to be sure that the charter and leadership of
the WG aren't set up to preclude a result of "this protocol is
dangerous and problematic, it is Not Recommended, and the IETF
recommendation is to minimize damage by discarding (or otherwise
ignoring) DMARC headers whenever they are encountered".  I want
to stress that I'm not recommending that approach, although it
has some charm.  I just want to be sure it is at least treated
as a legitimate alternative and that, should someone complain on
IETF Last Call that it wasn't considered seriously and/or that
the reasons for not going in that direction are not adequately
documented, such complaints cannot be dismissed on the basis of
language in the charter.

    john

---

From: Dave Crocker <[email-masked]>
Date: Thu, 17 Jul 2014 07:39:39 -0700

On 7/17/2014 7:30 AM, John C Klensin wrote:
>     but the IETF has, at
> but hurt small ones 

While that certainly sounds appealing, I'm not aware of any IETF policy
or pattern of practice in that regard.

Please supply some documentation for it.

> including stripping its headers whenever they are encountered.

What 'headers' are you referring to?

...
> ignoring) DMARC headers whenever they are encountered".

DMARC does not (currently) have any 'headers'.

>    I just want to be sure it is at least treated

Please suggest charter text.

d/

---

From: S Moonesamy <[email-masked]>
Date: Thu, 17 Jul 2014 09:56:47 -0700

Hi Barry,

Ok.

>DMARC base document certainly doesn't have to be sent to the IESG for

The requests in Section 16.1 and Section 16.2 are for "Expert 
Required" assignments.  The request in Section 16.3 is for a 
"Specification Required" assignment.  Section 16.4 requests the 
creation of a registry where assignments require "IETF Review".

>Do you really think we're not on top of a situation such as this?

I did a quick verification before writing this and I found that the 
following domains advertise a DMARC policy:

   bankofamerica.com
   chase.com
   facebook.com
   gmail.com
   linkedin.com
   microsoft.com
   paypal.com
   yahoo.com

There was a DMARC BoF last year ( 
http://www.ietf.org/mail-archive/web/dmarc/current/msg00307.html 
).  There was a lot of discussion on [email-masked] in April ( 
http://www.ietf.org/mail-archive/web/ietf/current/msg87153.html ).  I 
wouldn't describe the situation with respect to DMARC as the IESG 
being proactive [1] given that there is probably significant 
deployment of the protocol.  Please note that I am not basing my 
opinion solely on the eight domains mentioned above.

>IANA and the ISE, and such a problem hasn't happened yet.

Please see Section 16.4 of the base specification.  As far as I am 
aware there hasn't been any problem between the IESG and the ISE 
regarding the registry assignments.  I don't think that the IESG 
would be okay with the creation of an IETF registry without IETF 
Review.  I don't know whether the IESG has discussed that point.  My 
suggestion (in April) was to discuss about all that with the 
Application Area Directors.

>What appears arbitrary to you?

That was a comment based on my experience [2] in a previous (IETF) 
working group.

>What, exactly has that impact?  And what does this have to do with the IAB?

In my opinion, if the IESG is okay with the creation of protocol 
parameter registries without IETF Review in this case it would impact 
on other such cases.  I wrote "IAB mailing list" as Dave Crocker and 
I have commented on that mailing list during the discussion about 
(IETF) protocol parameters.  If I had written "IAB" I would not be 
identifying the venue where the discussion [3] took place.

What is the way forward?  Seriously, I don't know.

Regards,
S. Moonesamy

1. (Of a person or action) creating or controlling a situation rather 
than just responding to it after it has happened.
2. http://www.ietf.org/mail-archive/web/yam/current/msg00655.html (I 
like the humour :-))
3. The thread starts at 
http://www.iab.org/mail-archive/web/internetgovtech/current/msg00447.html

---

From: John C Klensin <[email-masked]>
Date: Thu, 17 Jul 2014 14:06:28 -0400

--On Thursday, July 17, 2014 12:32 -0400 John R Levine
<[email-masked]> wrote:

>> non-essential protocol complicated because one way to
>> eliminate the damage is to not support the protocol at all,
>> possibly including stripping its headers whenever they are
>> encountered.
> 
> Having talked at length with people at the large providers
> that use DMARC, I am sure that there is no possibility that it
> will go away and it is likely that more rather than fewer
> providers will start publishing restrictive policies.

I do see a plausible scenario under which it goes away, but that
scenario is not the IETF's problem and I hope it stays not the
IETF's problem.  More to the point, my note did not posit any
change in their behavior.

> They understand that it causes problems, and I believe they
> are open to implementing changes to alleviate those problems.

Let me be clear, since my earlier note obviously either wasn't
or was too detailed.    I believe there are three possible
"fixes" that are under IETF control (what those providers will
or will not do is not, ARAIK, under IETF contorl):

(1) Changes are made to DMARC that reduce the pain level.

(2) Changes are recommended and made by the pain-recipients that
will make things less painful.  

(3) Changes that are made in systems not controlled by the DMARC
sponsors that make the protocol both less effective and less
painful, e.g., by removing DMARC headers in appropriate
circumstances (with "appropriate" to be something the WG
discusses).

I just want to be absolutely sure that the charter doesn't
constrain any of those options and that the WG is on notice that
it will be accountable for, and required to explain, the choices
it makes.  

 best,
     john

---

From: John C Klensin <[email-masked]>
Date: Thu, 17 Jul 2014 14:15:36 -0400

--On Thursday, July 17, 2014 07:39 -0700 Dave Crocker
<[email-masked]> wrote:

>> least IMO, tended to avoid protocols that favor large
>> providers but hurt small ones 
> 
> While that certainly sounds appealing, I'm not aware of any
> IETF policy or pattern of practice in that regard.
> 

I have been asked to not go there and am complying.

> What 'headers' are you referring to?

Perhaps it would have been more precise to say "delete all
DMARC-related headers", i.e., DKIM and/or SPF ones.  While that
would be pretty drastic in some respects, whether it is
justifiable depends on perceptions of the damage that DMARC can
cause.  I think that is a topic for WG discussion.

See my response to John Levine.

    john

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 Jul 2014 14:59:19 -0400

> Section 16.4 requests the creation of a registry where
> assignments require "IETF Review".
...
> I don't think that the IESG would be okay with the
> creation of an IETF registry without IETF Review.  I don't know whether the
> IESG has discussed that point.

It has, and there's no problem.  The IESG has objected to Independent
Stream documents creating registries with policies of Expert Review or
Specification required, because those commit the IESG to appointing a
Designated Expert, with all the management necessary for that.

But other registration policies don't commit anyone to anything, and
an Independent Stream document creating a registry that requires IETF
Stream RFCs in oder to register in it... is perfectly fine.  Yes, the
IESG has discussed this in relation to other Independent Stream
documents.

And, in fact, it's possible that a dmarcext working group that might
be chartered might be the first use of that registry.

> wouldn't describe the situation with respect to DMARC as the IESG being
> proactive [1] given that there is probably significant deployment of the
> protocol.  Please note that I am not basing my opinion solely on the eight
> domains mentioned above.

I still don't understand what you expect to have done here.  The IESG
is evaluating this charter.  If there's a change you want to see in
the charter text, please clearly state it.  If there's something you
want the IESG to consider as it evaluates the charter, please be clear
about exactly what that is, so the IESG can consider it.

Barry

---

From: "John R Levine" <[email-masked]>
Date: 17 Jul 2014 12:32:56 -0400

> including stripping its headers whenever they are encountered.

Having talked at length with people at the large providers that use DMARC, 
I am sure that there is no possibility that it will go away and it is 
likely that more rather than fewer providers will start publishing 
restrictive policies.

They understand that it causes problems, and I believe they are open to 
implementing changes to alleviate those problems.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: [email-masked] (Martin Rex)
Date: Thu, 17 Jul 2014 21:57:12 +0200 (CEST)

Douglas Otis wrote:
> 
> Viktor Dukhovni <[email-masked]> wrote:
>> 

Only the most clueless MUA programmers got this wrong in the first place.
>From a probability standpoint, now counting on those to (a) take the
blame and (b) get it right this time may be somewhat optimistic.

The main problem that I have is DMARC, is that the approach is
technically and morally wrong, and legally prohibited (=criminal)
in properly civilized countries.

A better approach would be for the final MTA to perform DMARC (DNS) lookups
and prepend the results as new, standardized header lines to the message,
and have the MUA process these new header lines and **suppress** displaying
of the "rfc5322-From:" for messages that are supposed to verify but don't.

And DMARC reporting needs to be killed.

> 
> You are right, but this provides a domain not always seen by recipients.
> Only the From header field is surely displayed.  

So you at least agree that it is the broken MUAs that cause the problem.

When the details about the OpenSSL heartbeat vulnerability was published,
would it have been better to force all ISPs to detect and tear down
TCP connections that "exploit" the weakness, or to fix the broken software?

-Martin

---

From: S Moonesamy <[email-masked]>
Date: Thu, 17 Jul 2014 12:58:19 -0700

Hi Barry,

I changed the subject line as this is not related to the proposed charter.

>IESG has discussed this in relation to other Independent Stream

Section 4 of RFC 5226 is about creating a registry.  My assumption 
would be that it would require some IETF action or IESG approval as 
it is committing the IETF to do some work in future.  My experience 
of an IETF Review is that it is a higher barrier than going through a 
review in the Independent Stream:

   (i)  I would have to find an Area Director to sponsor the draft; or

   (ii) Get a working group to adopt the draft, and go through the 
IETF process.

It does not seem fair to me to create and populate a registry and ask 
other people to put in much more effort than I would have to put in 
when requesting an assignment.

I'll respect the decision of the IESG.

Regards,
S. Moonesamy

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 Jul 2014 16:08:19 -0400

> Section 4 of RFC 5226 is about creating a registry.  My assumption would
> be that it would require some IETF action or IESG approval as it is
> committing the IETF to do some work in future.
>

I don't understand that: why does the creation of a registry commit the
IETF to do work in future?

Barry

---

From: Dave Crocker <[email-masked]>
Date: Thu, 17 Jul 2014 13:26:57 -0700

> DMARC-related headers", i.e., DKIM and/or SPF ones.  While that

SPF has no 'headers'.

At first blush, dictating deletion of a DKIM-Signature field sounds like
a layer violation.

At second blush it won't do anything useful.  (Really!)

At third blush, it starts to look as if the current details of the DMARC
specification need to be better understood before suggested remedies to
the collateral damage of its use are considered.

> justifiable depends on perceptions of the damage that DMARC can

It is not a matter of 'perception'.  It needs to be a matter of utility.

> cause.  I think that is a topic for WG discussion.

Unfortunately, I still can't tell what that discussion would be about or
would be intended to accomplish.

On 7/17/2014 11:06 AM, John C Klensin wrote:>
> it will be accountable for, and required to explain, the choices

1. You want to be 'absolutely sure' of the way an IETF charter will be
interpreted?  You realize, I hope, that uttering such a statement mostly
means we can all be absolutely sure you are not the John Klensin who has
participated in the IETF for such a long time.

2. If you want to strengthen the charter's language towards whatever
specific protections you have in mind, then please suggest language to
that end.

3. What you have expressed so far is sufficiently vague, I still have no
idea what particulars might be responsive to those concerns.

d/

---

From: Pete Resnick <[email-masked]>
Date: Thu, 17 Jul 2014 15:40:21 -0500

OK, that was an amusing (*ahem*) little diversion. Trimming down to 
(what I think is) the point:

On 7/17/14 1:06 PM, John C Klensin wrote:

> painful

I do not believe there is anything in the charter that would preclude 
the WG from doing any of those things (among other possible things). In 
fact, I think the current version has text that actually includes the 
above possibilities. So I do not see any change necessary for this concern.

pr

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Jul 2014 14:24:37 -0700

> Only the most clueless MUA programmers got this wrong in the first place.

Isn't that most of them?

> blame and (b) get it right this time may be somewhat optimistic.

I rather agree there.

> in properly civilized countries.

Could you elaborate on why to the two "wrong" assertions?

> of the "rfc5322-From:" for messages that are supposed to verify but don't.

The base draft supports the header lines suggestion.  We're arguing in
another thread about whether requiring specific MUA behavior in the face of
a negative evaluation is a useful thing to pursue in an IETF document.

> And DMARC reporting needs to be killed.

Could you elaborate on why?  I only ask because some operators think the
reporting is actually the more valuable thing DMARC has to offer, and you
seem to have different information.

-MSK

---

From: Pete Resnick <[email-masked]>
Date: Thu, 17 Jul 2014 16:37:07 -0500

On 7/17/14 4:24 PM, Murray S. Kucherawy wrote:
> On Thu, Jul 17, 2014 at 12:57 PM, Martin Rex <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     [...]
>
>
> [...]

To repeat, a bit more strongly: I'm not finding anything in this part of 
the thread pertaining to the charter. Please let's keep the discussion 
of the technology in a different thread, preferably on the dmarc list, 
preferably once we have a moderator/chair in place.

pr

---

From: S Moonesamy <[email-masked]>
Date: Thu, 17 Jul 2014 15:25:22 -0700

Hi Barry,
At 13:08 17-07-2014, Barry Leiba wrote:
>I don't understand that: why does the creation of a registry commit 
>the IETF to do work in future?

Let's assume that a registry is created.  There is a presumption that 
the registry will be used in future.  Otherwise, it does not make 
sense to spend time reviewing the IANA Considerations section in IETF 
drafts.  The assignment guidance is for people to contact the IETF to 
request an assignment in that registry.  From the IETF side they 
would be some commitment to review the request.  Otherwise, it would 
seem like the IETF is saying things that it would be unable to do.

It could be said that the IETF accepts the responsibility for all 
aspects of the registry, even though some aspects may rarely or never be seen.

Regards,
S. Moonesamy

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 Jul 2014 20:13:05 -0400

> assignment guidance is for people to contact the IETF to request an
> assignment in that registry.  From the IETF side they would be some
> commitment to review the request.

No.  IETF Review means that the request has to be made from an IETF
Stream document.  Such a document is being reviewed by the IETF
anyway, and the registry adds no extra work.

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 17 Jul 2014 17:34:51 -0700

> anyway, and the registry adds no extra work.

For the sake of comparison (and hopefully clarification), what's an example
of an IANA action that does create work for the IETF, such that the IESG
would object?

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Thu, 17 Jul 2014 20:40:04 -0400

> For the sake of comparison (and hopefully clarification), what's an
> example of an IANA action that does create work for the IETF, such that the
> IESG would object?
>

I think I gave one a couple of times: creating a registry that requires a
designated expert (Expert Review or Specification Required) is what we've
objected to.  It commits the IESG to appointing and manageing one or more
DEs, without approval that comes with IETF consensus.

Barry

---

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

> DEs, without approval that comes with IETF consensus.
Sorry, I'd lost track of the thread.  You did indeed.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Thu, 17 Jul 2014 22:52:22 -0700

Hi Barry,
>anyway, and the registry adds no extra work.

The person has to write an Internet-Draft to request the 
assignment.  He or she has to find IETF participants who are willing 
to review that Internet-Draft.  There is an IETF Last Call.  There is 
an IESG evaluation.

If I understood what is written above, the IETF has not taken any 
commitment to help with the (IETF) review and it does not consider 
all of this as extra (IETF) work as the Area Directors do not have to 
manage Designated Experts.

I'll copy this message to the IESG, excluding the General Area 
Director, as I am curious to hear the opinions of the Area Directors 
in other Areas (excluding Applications) about this topic.  I 
understand that it is unusual for an individual to send such a 
request by email instead of asking for the opinions of Area Directors 
during an IETF plenary.

Regards,
S. Moonesamy

---

From: [email-masked]
Date: Fri, 18 Jul 2014 07:12:05 -0700 (PDT)

> in a position to bring about its implementation?  How much do MUAs apply,

In my experience compliance to what's there has been quite good. I've seen some
issues with multipart/digest handling, and there has been a general reluctance
to make it easy to get at raw data for unrecognized types - quite
understandable given the security implications. And of course there have been
plenty of outright bugs and the usual range of responsiveness to getting them
fixed.

The pernicious problems have been with stuff we didn't think to write down. The
big one there would be the tension between media types and file extensions. It
didn't occur to us to write anything about that, and there have been ongoing
issues in that area. And the handling of more complex MIME structure has been
problematic in some cases - we should have said something concrete about that.

Another issue with RFC 2049 is that some of the conformance guidelines are
obsolete. The stuff about charsets is the obvious example: It's completely
dated. In fact looking at it now makes me wonder why we didn't think to update
it and talk about utf-8 at some point. Who knows? Maybe that would have helped.

> MUA developers will end up disregarding our advice and following their own

I really have to question the validity of this line of thinking. Let's suppose
for a moment that there had been major and ongoing conformance issues with RFC
2049. Would that really constitute grounds for not doing our job properly now?

> even get Sender to matter again.

That sounds like a fine idea. But I don't see it as any sort of requirement.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Fri, 18 Jul 2014 12:41:41 -0400

> On Jul 17, 2014, at 5:24 PM, "Murray S. Kucherawy" <[email-masked]> wrote:
> 
> Could you elaborate on why?  I only ask because some operators think the reporting is actually the more valuable thing DMARC has to offer, and you seem to have different information.

Beside it becoming a potential source for abuse, i.e. DoS, in general, once the proof of concepts are achieved, reporting becomes a wasteful, redundant high overhead part of the process.  This is why it I believe DMARC should be split into two; reporting and policy handling or reporting made an option for implementors who might only interested in the policy handling enforcement aspect and do not wish to be sending out reports -- we already know it works.

---

From: [email-masked] (Martin Rex)
Date: Fri, 18 Jul 2014 19:48:27 +0200 (CEST)

Murray S. Kucherawy wrote:
> Martin Rex <[email-masked]> wrote:
>> 

The issuer of a DMARC policy (who publishes the DNS records) is
a legal third party to the transfer of an EMail message from an SMTP sender
to an SMTP receiver.  Revealing information about communication between
two parties (including unsuccessful communication attempts) to an outside
third party (such as a "domain owner who issues DMARC policy records") is
unconditionally illegal for telecommunications service providers.

Looking at the communication contents will also close to always be illegal.
The telecommunication service provider is only entitled to process the
"traffic data", which in case of SMTP EMail is strictly limited to the
IP addresses and TCP ports of the communication peers _plus_ the SMTP
Envelope (aka MAIL FROM: and RCPT TO:), the rfc5322-From: is part of
the communication content and off-limits to the telecommunication service
provider.  Processing of the contents for any other purpose than what is
necessary for transfering the bits from sender to receiver will be
unconditionally illegal, collecting such data and reporting it to an
outside third party doubly so.

The issue is the complete incompatibility of DMARC with the core principle
of the fundamental Human Right on confidential communication.  This
fundamental right is spelled out in the German constitution (Art. 10 Abs. 1 GG)
and it is also part of the the European Convention on Human Rights
(Article 8 (1.)) as interpreted by the European Court of Human Rights
and confirmed in a recent decision of the European Court of Justice.

By being part of the constitution (Germany) or of a Constitution-Like
Fundamental Right (EU Convention of Human Rights after the Treaty of Lisbon),
the core principle of Communication Confidentiality is even sacrosanct from
national legislation or EU member states (something that the
constitution-less UK seems to currently struggle with and which
probably voids parts of their rushed UK DRIP bill).

Maybe a quick glance at the EU Directive 2002/58/EC from 10-Jul-2002 helps:

http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32002L0058&from=EN

from Article 5 "Confidentiality of the Communications" (page 7 of above PDF):

  1. Member States shall ensure the confidentiality of commu-
     nications and the related traffic data by means of a public
     communications network and publicly available electronic
     communications services, through national legislation. In parti-
     cular, they shall prohibit listening, tapping, storage or other
     kinds of interception or surveillance of communications and
     the related traffic data by persons other than users, without the
     consent of the users concerned, except when legally authorised
     to do so in accordance with Article 15(1).

This "Member States shall ensure ..." and "they shall prohibit..."
means that there ought to exist, by now, criminal statutes in every
EU member states for violation of communication confidentiality.
In German national law, its "a fine or prison term of up to 5 years"
for telecommunication service providers, and the definition of the
latter includes all employers and organizations running organzational
telecommunication systems/networks (phone, mail, chat, InternetAccess, etc.)

The key issue is the legal definitions of "user", "communication"
and "traffic data" and this is where the EU is aeons ahead of the US.

"traffic data" is what the USG derogatively calls "metadata" or
"business records".  In the EU, the "traffic data" is part of the
communication and subject to the same protections.  This includes
traffic data about unsuccessful communication attempts.

Article 2 "Definitions" of this EU directive (page 7 of above PDF)

  The following definitions shall also apply:
   (a) "user" means any natural person using a publicly available
       electronic communications service, for private or business
       purposes, without necessarily having subscribed to this
       service;
   (b) "traffic data" means any data processed for the purpose of
       the conveyance of a communication on an electronic
       communications network or for the billing thereof;
   (c) "location data" means any data processed in an electronic
       communications network, indicating the geographic posi-
       tion of the terminal equipment of a user of a publicly avail-
       able electronic communications service;
   (d) "communication" means any information exchanged or
       conveyed between a finite number of parties by means of a
       publicly available electronic communications service. This
       does not include any information conveyed as part of a
       broadcasting service to the public over an electronic
       communications network except to the extent that the
       information can be related to the identifiable subscriber or
       user receiving the information;
   (e) "call" means a connection established by means of a publicly
       available telephone service allowing two-way communica-
       tion in real time;
   (f) "consent" by a user or subscriber corresponds to the data
       subject's consent in Directive 95/46/EC;
   (g) "value added service" means any service which requires the
       processing of traffic data or location data other than traffic
       data beyond what is necessary for the transmission of a
       communication or the billing thereof;
   (h) "electronic mail" means any text, voice, sound or image
       message sent over a public communications network which
       can be stored in the network or in the recipient's terminal
       equipment until it is collected by the recipient.

-Martin

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 18 Jul 2014 12:32:23 -0700

>        purposes, without necessarily having subscribed to this

I am certainly no lawyer (are you?), but it seems to me that a corporate
domain owner that chooses to use DMARC to protect its brand might have
users within that domain -- employees, for instance.  I would claim that
such an employer's email servers do not comprise "a publicly available
electronic communications service", so I don't think employees using a
protected domain are "users" under this definition.  And even if that
doesn't wash, an employment contract (here, at least) typically grants the
Article 5 consent that makes this point moot, and is not typically a "Click
OK and forget" situation.

I imagine email service providers could secure the same sort of consent
through a privacy policy, though "I had no idea" might be a more successful
counter-argument there because nobody really reads those.

-MSK

---

From: Stuart Barkley <[email-masked]>
Date: Sat, 19 Jul 2014 03:57:14 -0400 (EDT)

On Thu, 17 Jul 2014 at 16:26 -0000, Dave Crocker wrote:

> At third blush, it starts to look as if the current details of the
> DMARC specification need to be better understood before suggested
> remedies to the collateral damage of its use are considered.

It is this "collateral damage" from the broken aspects of DMARC that
is disturbing.  The proponents of DMARC need to look at "the current
details of the DMARC specification" and better understand the damage
that they have imposed on the rest of the Internet.

Stuart Barkley
-- 
I've never been lost; I was once bewildered for three days, but never lost!
                                        --  Daniel Boone

---

From: Randy Bush <[email-masked]>
Date: Sat, 19 Jul 2014 04:32:25 -0400

> that they have imposed on the rest of the Internet.

they're big.  they think they do not have to.

randy

---

From: "John Levine" <[email-masked]>
Date: 19 Jul 2014 18:09:10 -0000

>that they have imposed on the rest of the Internet.

What leads you to imagine that they don't understand it?

The question is how much they care, and how much we can persuade them
to help mitigate it.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Sat, 19 Jul 2014 21:27:49 -0700

Dear Hector,

See comments inline:

On Jul 16, 2014, at 9:51 AM, Hector Santos <[email-masked]> wrote
> Consider ATPS the "lite version" of Doug's TPA. The same lookup hashing algorithm is used in both.  Further, there is real high quality commercial "running code" implementations supporting rfc6541.…

ATPS is not the "lite version" of TPA-Label.  This is explained in 
http://tools.ietf.org/id/draft-otis-tpa-label-04.html#rfc.appendix.C

ATPS requires DKIM signatures used by Third-Party Services to somehow determine different label encoding methods permitted by ATPS.  ATPS also lacks any discovery or exchange method for this. In contrast, TPA-Label makes NO demands on third-Party services.  None.  Since there is only one encoding method, there is NO guesswork discovering the listing encoding method. 

The extra processing is only done when DMARC indicates non-complaince where the DMARC domain can then indicate whether they have informally federated the domain in question and what if any additional information must be included in the message.  In comparison, processing a new DKIM-ike signature involves greater overhead than that needed to obtain a TPA-Label resource which happens only after the domain in question has been validated.  It seems TPA-Label represents far easier deployment and far less overhead since the Third-Party makes no change to their process and only a single, small, cacheable TPA-Label resource is provided by the DMARC domain.

While the DMARC domain can delegate the domain offering the TPA-Labels, a single server is more than able to handle what would be needed to satisfy the largest email provider, although two should be deployed for redundancy.  If a domain is being abusive, a TPA-Label can even offer a cacheable negative federation response.  TPA-Label is also able to selectively enable specific uses of Sender header fields or specific use of List-IDs.  When there is a problem with a third-party domain that ignores DMARC, the TPA-Label can also require use of OAR headers.  Unlike ATPS, TPA-Label is far easier and is capable of enabling all valid email without causing disruption.

Regards,
Douglas Otis

---

From: S Moonesamy <[email-masked]>
Date: Sun, 20 Jul 2014 00:49:34 -0700

Hi Martin,
>outside third party doubly so.

The proposed charter mentions "privacy issues".  I guess that the 
above issues would be considered as privacy issues.  The side topic 
would be the surveillance stuff.  The existing IETF RFCs about email 
basically say that content is transparent to whomever wants to read 
the communication between the ends.  The proposed charter does not 
set that topic as out of scope.  My interpretation of the proposed 
charter is that these are the sort of issues which the proposed 
working group will be working on.

Regards,
S. Moonesamy

---

From: Michael Richardson <[email-masked]>
Date: Sun, 20 Jul 2014 09:26:45 -0400

Regardless of how/if/why/when we process DMARC as a specification, we need to
decide how ietf.org MTA is going to deal with things.

1) someone has to fund changes to mailman, and perform testing, installation,
   and community education for the IETF mailing lists.  That implies that
   we have to decide *for ourselves* where and how we will "break" the
   DMARC/DKIM connection,  and if we will reject email from p=reject senders
   before we attempt to relay.

2) there are a number of things which are not mailman lists, but aliases,
   which get *no* reprocessing of any headers at all.  This includes, I
   think,    "iesg", "iab", "iaoc", *AND* why I suddenly care again: "nomcom14-coord"

   yes, at least one member of nomcom has an ISP that processes DMARC,
   and I think two members of nomcom send email from p=reject addresses.

   The experience is that some senders get rejected by some recipients, but
   other senders do not.  It felt at first, like some bizarre kind of
   censorship.  The confusion is confounded because I think some DMARC
   processors (gmail.com?) may have already whitelisted ietf.org MTAs,
   while others have not.

   (3 - I'm still looking for confirmation that we a suffering on
   nomcom14-coord from DMARC)

So, again, I'm not interested in what we might specify as an SDO.
I'm interested in what we are going to *do* as an entity.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Jul 2014 02:03:45 +1200

>    before we attempt to relay.

I thought the preferred solution was to rewrite the From for those users only.

>    think,    "iesg", "iab", "iaoc", *AND* why I suddenly care again: "nomcom14-coord"

I doubt if this is soluble in any obvious way.

   Brian

---

From: Barry Leiba <[email-masked]>
Date: Sun, 20 Jul 2014 11:10:16 -0400

> The person has to write an Internet-Draft to request the assignment.  He or
> she has to find IETF participants who are willing to review that
> Internet-Draft.  There is an IETF Last Call.  There is an IESG evaluation.
>
> If I understood what is written above, the IETF has not taken any commitment
> to help with the (IETF) review and it does not consider all of this as extra
> (IETF) work as the Area Directors do not have to manage Designated Experts.

My point is that anyone can propose an IETF stream document at any
time, about anything.  The creation of the registry has nothing to do
with that -- the creation of the registry doesn't cause extra work.

People who submit documents to working groups or for AD sponsorship
do, of course, create extra work.  It's up to the working groups and
ADs to decide whether that extra work should be taken on.

Barry

---

From: John C Klensin <[email-masked]>
Date: Sun, 20 Jul 2014 12:12:37 -0400

--On Monday, 21 July, 2014 02:03 +1200 Brian E Carpenter
<[email-masked]> wrote:

>> Regardless of how/if/why/when we process DMARC as a
>> specification, we need to decide how ietf.org MTA is going to
>> deal with things.
>> 
>> 1) someone has to fund changes to mailman, and perform
>> testing, installation, and community education for the IETF
>>    mailing lists.  That implies that we have to decide *for
>>    ourselves* where and how we will "break" the DMARC/DKIM
>>    connection,  and if we will reject email from p=reject
>>    senders before we attempt to relay.
> 

Brian,

I think that remains controversial.  At least some of us would
prefer that we scan IETF lists for addresses that might be
affected, notify those people that they will no longer be able
to send to IETF lists from those addresses, and then, while we
would continue to deliver traffic to them to the degree
feasible, any traffic originating from them would simply be
rejected or bounced by mailman.  That requires changes and some
tool work too, but puts the pain where it belongs -- on the
DMARC-using systems and those who choose to have addresses on
then.

I have mixed feelings about recommending that strategy for the
more general community and am happy to let the proposed WG do
its job, but, as far as the IETF community is concerned, we are
all presumably capable of understanding the issues and finding
other addresses if needed.

   john

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Jul 2014 04:24:01 +1200

On 21/07/2014 04:12, John C Klensin wrote:
> to send to IETF lists from those addresses, 

Yes, of course, and I've done that for the IETF lists I administer,
as far as possible. As a practical matter, though, I would selectively
rewrite rather than throw people off. I'd like to have that choice.

> and then, while we

I would hope so, but changing one's address is a significant
nuisance. So I'd like a choice of pragmatic solutions while
we wait.

   Brian

---

From: Hector Santos <[email-masked]>
Date: Sun, 20 Jul 2014 12:45:00 -0400

> I thought the preferred solution was to rewrite the From for those users only.

-1.

Its not the preferred solution. Not one iota. Please don't endorse 
this radical "email game changing" behavior.  Since you are among the 
"top IETF key cogs," if its preferred among the IETF key cogs, as you 
are making it sound, then this is not good at all. It would be a 
serious "game changer."  It goes to show how much the IETF really 
cares about the concerns for the wider and entire mail networking 
community which is obviously becoming less and less. It will set a 
terrible precedence and obvious security loophole if you crack open 
this door.  The "From" could never be trusted again and the new 
algorithms necessary to separate and categorized the good from the 
bad, will be overwhelming and complex at all levels.

Plus, if you ask and explore the risk and liability issues with your 
chief council, you could be playing with fire here. I wouldn't do it. 
  Bad idea.

I don't recommend any change to the ietf.org list mail process 
regarding DMARC until there is a 3rd party authorization framework in 
place.  The lack of one currently should not suggest breaking security 
as the "path of least resistance" should be endorsed by the IETF.

-- 
HLS

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 20 Jul 2014 13:09:17 -0400

>     before we attempt to relay.

Leaving aside the question of whether or not IETF should use a 
workaround, I thought there was a mailman patch to deal with re-writing 
from addresses for DMARC p=reject.

Note that this is from reading mailops and such, not person experience - 
as we use Sympa in our shop, for which there is a patch (actually it's 
in the most recent release).

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

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

---

From: Eric Burger <[email-masked]>
Date: Sun, 20 Jul 2014 14:23:36 -0400

I will not comment on the 85 messages in the thread.  However, I would like to point out that STIR is working on a similar problem with similar goals but in a more constrained environment.  I would offer coordination between WG’s, should DMARC be chartered, would be “a good thing.”

On Jul 14, 2014, at 12:42 PM, The IESG <[email-masked]> wrote:

> Domain-based Message Authentication, Reporting & Conformance (dmarc)
> ------------------------------------------------
> Current Status: Proposed WG
> 
> Assigned Area Director:
>  Pete Resnick <[email-masked]>
> 
> Mailing list
>  Address: [email-masked]
>  To Subscribe: https://www.ietf.org/mailman/listinfo/dmarc
>  Archive: http://www.ietf.org/mail-archive/web/dmarc/
> 
> Charter:
> 
> Milestones:
> TBD

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 Jul 2014 06:39:08 +1200

On 21/07/2014 05:09, Miles Fidelman wrote:
...
> from addresses for DMARC p=reject.

No, it isn't selective for addresses from a domain with a p=reject policy.
It's clearly unacceptable to rewrite addresses that don't need to be
rewritten.

In answer to Hector: I fully agree that rewriting From is a bad idea.
I also agree that breaking mailing lists is a bad idea. The dilemma
is choosing the least bad path until a good solution is defined.

   Brian

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 20 Jul 2014 14:53:20 -0400

> It's clearly unacceptable to rewrite addresses that don't need to be

Seems to be now.  From the Mailman site:

Implemented now for release in 2.1.18 are the following:

  * The from_is_list feature from 2.1.16 is always available.
  * There are new settings in Privacy options - Sender filters:
      o dmarc_moderaction_action is a five valued setting with values
          + Accept - accept the post without rewriting From: or wrapping
            the message
          + Munge From - rewrite the From: and Reply-To: as in from_is_list
          + Wrap Message - wrap the message as in from_is_list
          + Reject - reject the post
          + Discard - Discard the post
      o dmarc_moderaction_notice is a custom reject message to replace
        the default Reject message.
  * The above options other than Accept override thefrom_is_list setting
    for messages whose original From: domain publishes a DMARC policy of
    p=reject or p=quarantine. A per-list option is available to limit
    this to just p=reject or to apply it to either p=reject or
    p=quarantine. If the option is Accept, the from_is_list setting applies.
  * There is a site option to set the default for
    dmarc_moderaction_action and list admins may not set the action to a
    setting which is above the site default in the above list. E.g., if
    the site default is Reject, list admins can only set Reject or
    Discard; if the site default is Munge From, list admins can select
    anything but Accept.

Miles

---

From: Pete Resnick <[email-masked]>
Date: Sun, 20 Jul 2014 14:54:13 -0400

> I'm interested in what we are going to *do* as an entity.

I have delusions that those two should not differ significantly and that 
the WG can produce at least enough of an outline of what ought to be 
done in short finite time that the IETF's MTA folks will be able to make 
changes. That is, after all, the way our process is *supposed* to work. 
I understand the vastness of my delusions, but I am motivated to get 
phase 1 of the charter completed quickly.

pr

---

From: Dave Crocker <[email-masked]>
Date: Sun, 20 Jul 2014 15:02:35 -0400

> phase 1 of the charter completed quickly.

In the late 80s, which was the beginning of the Internet's commercial
market, my group produced Internet protocol stacks.

Europe was 25% of our revenues, in spite of being the hotbed of OSI --
"OSI created the market; the Internet satisfied it." (sm)

One of my larger customers was the manager of the IT department at ISO...

I asked whether he got hassled about that and with no accompanying smile
he said that he had a job to do and they didn't get to tell him how to
do it.

The IETF ops folks have an immediate requirement.  They should not be
forced to wait on a yet-unformed working group and unknown delays after
it is formed, before dealing with that problem.

Michael described immediate and consequential problems.

They need immediate and useful actions.

d/

---

From: Hector Santos <[email-masked]>
Date: Sun, 20 Jul 2014 16:01:27 -0400

I would like to see a better integrated, cross-area engineering effort.  There is much to do in the integrated area of new domain authorization "permission-based" policy concepts.   We have a tendency of repeating the similar concepts across proposed multiple protocols.  In an evolved, modern SMTP receiver, it could perform 3-6 or more DNS redundant lookups for each transaction, and they are not flexible enough to be lumped together.

> On Jul 20, 2014, at 2:23 PM, Eric Burger <[email-masked]> wrote:
> 
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: [email-masked] (Martin Rex)
Date: Sun, 20 Jul 2014 23:18:44 +0200 (CEST)

Murray S. Kucherawy wrote:
>                                                      I would claim that
> protected domain are "users" under this definition.

An employee only has to meet the "a natural person" criteria to fall
under the under the "user" defintion of the EU directive.

The term "publicly available electronic communications service" in the
directive sounds vague and appears to provide wiggle room for national
legislators.  But even if some EU member states would try to "exploit"
this, chances are that the European Court of Justice (ECJ), who is
the authority on the interpretation of EU directives and has a duty to
make laws of EU member state converge, may not allow loopholes and
argue based on the stated pupose of the directive and the necessity
of the protection.  Exceptions are limited to those listed in Article 15
and must be narrowly defined within statue law.

In german national law (TKG) the wording is better and clearer.
There, it covers any "electronic communication service" that is connected
to public communication services, i.e. when it allows sending to or
receiving from public communication service.

>
> And even if that doesn't wash, an employment contract (here, at least)
> typically grants the Article 5 consent that makes this point moot,
> and is not typically a "Click OK and forget" situation.

The Article 5 consent wasn't about "american style consent",

> counter-argument there because nobody really reads those.

Your expression "secure consent" gives a hint where your misunderstanding
might come from.

For many centuries, lots of contries had the notion that a certificate
of marriage would "secure consent" to sex between the couple, and
marital/spousal rape wasn't called rape and tolerated.
Over the last two or three decades a number of countries cleaned up
this part of their medieval heritage and started to protect
"the fundamental right to sexual self-determination" in their legislation.

In Germany, we fixed the laws in a similar fashion about the
fundamental right to informational self-determination, and this
concept was adopted by the EU data protection directive 95/46/EC,
which is refered to in the definition of "consent" quoted above.

"Terms of use" or contract clauses that try to "secure consent",
rather than making consent a seperate, purely voluntary opt-in,
will regularly be illegal and legally void in EU member states.
They definitely are legally void in Germany (that is even spelled
out in the German TKG).

-Martin

---

From: [email-masked] (Martin Rex)
Date: Sun, 20 Jul 2014 23:41:44 +0200 (CEST)

>>> Regardless of how/if/why/when we process DMARC as a specification,
>>> we need to decide how ietf.org MTA is going to deal with things.
>>

Sound like a reasonable approach to me.

> chief council, you could be playing with fire here. I wouldn't do it. 

I don't have the slightest idea what you're talking about.

Mailing lists @ietf.org are proper recipients of EMail, and ietf.org
has discretion to modify what it receives before it distributes
postings in new and seperate SMTP transactions to mailiing list recipients.

Knowing that some recipients (or more appropriately the relays that
take mail for these recipients) will choke on rfc5322-from with
mailboxes for which DMARC policies have been published, the ietf.org
mail exploder could decide to either reject postings, or to remove
or modify the information that is known to cause that choking.

Removing/replacing or rewriting offending mailboxes in rfc5322-from
would all be perfectly acceptable solutions to the problem that
minimize the impact on users (not require them to get a new mail
account from a more interoperable mail provider).
The fact that From: has traditionally been carried through was
to provide convenience to the mailing list subscribers and to
facilitate recognizing the (alleged) authorship of the contents. 

-Martin

---

From: "John Levine" <[email-masked]>
Date: 21 Jul 2014 02:51:32 -0000

>I think that remains controversial. ...

There is no consensus at all on how mailing lists should deal with
DMARC problems.  Some DMARC advocates claim there is for what appear
to me to be political reasons, but they are mistaken.  The latest
version of Mailman has several of them, and the developers tell me
that the forthcoming 3.0 version will add even more.

I have attempted to collect all of the known approaches on the ASRG
wiki here:

http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail

(The ASRG is dead, but the wiki lives on.)

If anyone notices that I've missed something, write to me and I'll
give you a password so you can fix it.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Hector Santos <[email-masked]>
Date: Mon, 21 Jul 2014 15:09:57 -0400

On 7/20/2014 10:51 PM, John Levine wrote:
> DMARC problems.

Not quite John.

The specific DMARC protocol aside, with any author domain policies in 
general, whether it was SSP, ADSP or any DKIM author domain signing 
authorization
protocol (DSAP),  there was a consensus RFC built document that 
provided the basic guideline for mailing list operations in dealing 
with restrictive DKIM signing policies. It used ADSP as the "DSAP" of 
the day. But replace ADSP with DMARC and the design recommendations apply:

    RFC6377  DomainKeys Identified Mail (DKIM) and Mailing Lists
    http://tools.ietf.org/html/rfc6377

And overall, the basic guideline was to support the framework, not 
ignore it as it never existed and instead pushed for breaking the 
security protocol.

As a LIST developer and implementor of the "DSAP" protocol, it was simple:

  1) Deny Restrictive Domains from Subscribing
  2) Deny Restrictive Domains from List Submission
  3) Pottery Principle "You break it, you own it" - Resign mail

That is all at the top level that needed to be done and all the above 
really has nothing to do with a mailing list but the mail receiver 
verifier and the outbound mail server.

This is about not wanting to do a basic author domain signature 
authorization lookup for any kind of mail service.

-- 
HLS

---

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

John is correct. There is no consensus on how mailing lists should deal with DMARC problems, notwithstanding what rfc6377 says about DKIM. ADSP never gained enough real world implementation for there to be a meaningful consensus. One need only look at the discussion threads on the IETF (and other) list(s) following the publication of DMARC p=reject by several large mailbox providers to see the diverse range of views.

While I disagree with John on some things, in this case he is 100% dead on. To pretend otherwise is to do a disservice to the mailing list community and the mail community at large.

Mike

> -----Original Message-----
> From: ietf [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Monday, July 21, 2014 3:10 PM
> To: [email-masked]
> Subject: Re: DMARC and ietf.org
> 
> 
> authorization protocol (DSAP),  there was a consensus RFC built document
> that provided the basic guideline for mailing list operations in dealing with
> restrictive DKIM signing policies. It used ADSP as the "DSAP" of the day. But
> replace ADSP with DMARC and the design recommendations apply:
> 
> And overall, the basic guideline was to support the framework, not ignore it
> as it never existed and instead pushed for breaking the security protocol.
> 
> That is all at the top level that needed to be done and all the above really has
> nothing to do with a mailing list but the mail receiver verifier and the
> outbound mail server.
> 
> This is about not wanting to do a basic author domain signature authorization
> lookup for any kind of mail service.
> 
> --
> HLS
>

---

From: Hector Santos <[email-masked]>
Date: Mon, 21 Jul 2014 16:23:47 -0400

Mike,

There is no "pretending" here. We actually IMPLEMENTED and DEPLOYED 
the consensus built MAILING LIST recommendations and it works.

So I disagree 100% with the erroneous suggestion there has been "no 
consensus at all."  To suggest there is no guidelines whatsoever has 
been the real disservice being promoted.  Its not true.

It doesn't matter if its DMARC or ADSP. It the same design guidelines 
and if you actually implemented it as list developer, you might see 
that its really that simple.

The old argument that List developers are too old to change doesn't wash
anymore and in reality, once you roll up your sleeves and implement 
the consensus built suggestions, you will see it really has nothing to 
do with list services. It has to do with the VERIFIER.

So in short, I take slight offense to your suggestion that I have no 
understanding of the total issues involved as a product developer, its 
product offerings and also addressing the support needs of its 
customers which represents a wide horizontal spectrum of applied list 
needs.  There are solutions and I speak as a developer of a commercial 
integrated mail list server product line:

     http://www.santronics.com/products/winserver/ListServe.php

Note. This has nothing to do we have a "big data" problem (how to 
scale signer authorization).  Its a serious problem. But the consensus 
built guidelines provided are solid and necessary for any solution 
development.  You still need to honor the policies at the mail entry 
level.

-- 
HLS

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 21 Jul 2014 20:40:21 +0000

Comments in-line.

> Sent: Monday, July 21, 2014 4:24 PM
> To: [email-masked]
> There is no "pretending" here. We actually IMPLEMENTED and DEPLOYED the
> consensus built MAILING LIST recommendations and it works.
> 

The fact that you implemented and deployed does not mean that there is a general consensus in the IETF sense.

> consensus at all."  To suggest there is no guidelines whatsoever has been the
> real disservice being promoted.  Its not true.
> 

Guidleines != consensus.

> It doesn't matter if its DMARC or ADSP. It the same design guidelines and if
> you actually implemented it as list developer, you might see that its really
> that simple.
> 

The devil is always in the details. ADSP!=DMARC.

> anymore and in reality, once you roll up your sleeves and implement the
> consensus built suggestions, you will see it really has nothing to do with list
> services. It has to do with the VERIFIER.
> 

Even John isn't arguing that list developers are too old to change. He is questioning whether there is a consensus as to what changes or sets of changes are appropriate.  The Verifier is the driver of the changes but even representatives of (some) large mailbox providers have indicated that as Verifiers they are interested in how problems in this space might be addressed. As a 3rd party mailer, I got my organization to make changes in 2007 that accommodate issues in this space. While I think the changes we made are the optimal long term solution (including for MLMs), I recognize that there IS NOT A CONSENSUS and that others have a preference for other approaches. It may be that the community settles on a single "best" approach or that it recognizes several alternative approaches.

> understanding of the total issues involved as a product developer, its product
> offerings and also addressing the support needs of its customers which
> represents a wide horizontal spectrum of applied list needs.  There are
> solutions and I speak as a developer of a commercial integrated mail list
> server product line:
>

I never said that you don't have an understanding of the issues involved. I did say that you are incorrect when you claim that there is a community consensus on how mailing lists should address problems in the context of DMARC assertions by domains. I do not see a rush of others posting to support your assertion and I do see evidence (previous discussions on this very list within the last 4 months) that contradict your assertion.

> Note. This has nothing to do we have a "big data" problem (how to scale
> signer authorization).  Its a serious problem. But the consensus built
> guidelines provided are solid and necessary for any solution development.
> You still need to honor the policies at the mail entry level.
> 
> --
> HLS
> 
> > John is correct. There is no consensus on how mailing lists should deal with
> DMARC problems, notwithstanding what rfc6377 says about DKIM. ADSP
> never gained enough real world implementation for there to be a meaningful
> consensus. One need only look at the discussion threads on the IETF (and
> other) list(s) following the publication of DMARC p=reject by several large
> mailbox providers to see the diverse range of views.
> >
> > While I disagree with John on some things, in this case he is 100% dead on.
> To pretend otherwise is to do a disservice to the mailing list community and
> the mail community at large.
> >
> > Mike
> >

---

From: Hector Santos <[email-masked]>
Date: Tue, 22 Jul 2014 08:44:39 -0400

> The fact that you implemented and deployed does not mean that there is a general consensus in the IETF sense.

In the IETF sense, there was many IETF consensus built document. Thats 
exactly my point. You are referring to adoption. The claim was there 
was no "consensus at all" in dealing with the problem is not true. 
Guidelines were produced. The reasons for not lacking multiple vendor 
support is a different issue best to lay rest as long as the IETF 
mistakes are recognized and finally finish this "job."

>> real disservice being promoted.  Its not true.

Consensus does not necessarily translate to support and adoption. Agree.
But consensus does leads to production of (RFC, STD) guidelines in the 
IETF.

> The devil is always in the details. ADSP!=DMARC.

Of course, but the entire policy framework with I-D and RFCs (SSP, 
DSAP, ADSP, ASL, ATPS, TPA, DMARC) from an software engineering 
standpoint are all sender/author domain signing policy protocols. 
They all fall in the same plug and play "black box" principle for the 
verifier "Checking Signing Practices" (CSP) module. This was all 
outlined and extracted from the IETF consensus-built documents:

    RFC4686  Analysis of Threats Motivating DKIM
    RFC5016  Requirements for a DKIM Signing Practices Protocol
    RFC5585  DKIM Service Overview

In particular,  see the RFC5685 architectural illustration with the 
CSP module in the middle of all this. See the RFC4686 illustration 
with the SSP and SIGNER EVALUATION modules.

My main point, love them or not, these and other DKIM-related 
documents were all consensus IETF built RFC guidelines for an 
integrated mail framework and list servers are part of the framework.

There were many integrated areas that were not consistent.  What 
created the core conflict we have today was predicted with the last 
minute provision added in RFC5016 section 5.3 item 10:

    10. SSP 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.

IMO, it disallowed us from finishing the job. Its hard to do software 
with this logic. I believe the intent was this:

    if two or more signatures exist and one is a 3rd party, ignore the
    1st party.

It allowed the list operation to disregard all new security protection 
mechanisms and passed the buck to the receivers when all they have to 
do is three basic things:

I agree, there was limited adoption.

-- 
HLS

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 22 Jul 2014 13:30:56 +0000

> decide how ietf.org MTA is going to deal with things.

For what it is worth the postfix-users and postfix-devel mailing lists
don't have any DMARC issues.  Long before DMARC, when DKIM was still
an IETF draft, these lists were changed to not modify the message body
or subject line in any way (no footers and no subject tags).

Rather, the lists only append "List-foo" headers, add a "Sender:"
header and otherwise forward the original message unmodified with
a new envelope.  The result is that the author DKIM signature
remains valid if present.

-- 
	Viktor.

---

From: Hector Santos <[email-masked]>
Date: Tue, 22 Jul 2014 13:28:00 -0400

> On Jul 22, 2014, at 9:30 AM, Viktor Dukhovni <[email-masked]> wrote:
> 

But this is a list service option.  I can't enforce one way or another for list operators to set their list up.  The default is to add a footer from a default template.  Can I change the default for future updates?   Sure, but that will violate a long term "no surprise" support principle for justifying automated updates (and the maintenance fees) and this would fall under a big surprise category.  

There are many list that desire the system level footer information, i.e. the note well for the IETF lists.   And I believe, needs to be double checked, there are some jurisdictions where is it legally required, i.e. CAN-SPAM.   The DMA I believe also expects it of it's member for community friendly spamming.  Overall, this is not something that can be universally applied.

> remains valid if present.

In my assessment, this is a migration issue, restrictive domains need to be cleaned up from list databases.   More importantly, I think it is a mistake to try to kludge around a DMARC specification that is protocol-incomplete.  DMARC needs to get fixed first to support 3rd resigners and then we can better evaluate how a list system fits.  Right now, there are no options which has created a "chaotic hysteria" to rewrite authorship domains.  But even when fixed, at end of the day, there will always be restrictive domains with an ADMD mandate for exclusive mail domain operations and regardless of the amount,  their policies must be honored.

---

From: "John Levine" <[email-masked]>
Date: 22 Jul 2014 21:15:12 -0000

>or subject line in any way (no footers and no subject tags).

That's one of the workarounds discussed in the wiki here:

Any change to existing practice will have some bad effects.  If a list
has been adding subject tags, and it stops adding them, people who
sort on subject tags will lose.  If it rewrites the From: line to put
in the list address, people who pick messages to read based on who
wrote them will lose, and it breaks S/MIME signatures.  And so forth.
See wiki for details.

Short of some DKIM-bis that allows for trusted forwarders to sign
messages in a way that DMARC recipients will accept (which we're
working on but don't hold your breath) there's no good solution to
this, only less bad solutions.

R's,
John