Subject: Suggestion: can we test DEMARC deployment with a mailing list?

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 2 May 2014 18:05:37 +0000

We have been having a fairly extended discussion, much of which seems hypothetical - “I don’t like DEMARC because I am worried that ... with mailing lists”. I wonder if we could take a moment to try it and see what happens?

As an example of the case that comes to mind, see attached. It is a message sent to [email-masked] yesterday. The sender signed it using DKIM, the IETF changed the message (added some trailing text) before forwarding it, the receiver (e.g., Cisco IT) attempted to validate the DKIM signature - and failed.

It seems to me that we should not approve a procedure that has that effect, at least without some guidance for mail relay administrators. I could imagine two forms of guidance: “obey the end-to-end principle; don’t change the message the originator sent”, or “if you change a signed message, first validate the message you received and discard if that fails, change it, and then sign it yourself, so that a receiver can see who changed it and validate the outcome”.

Could we actually try such guidance in a sandbox, and document appropriate procedures for mailing lists?

Subject: Re: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01
From: Owen DeLong <[email-masked]>
To: joel jaeggli <[email-masked]>
Cc: Lorenzo Colitti <[email-masked]>, "Fred Baker (fred)" <[email-masked]>, V6 Ops List <[email-masked]>, "Byrne, Cameron" <[email-masked]>
Date: Thu, 1 May 2014 20:57:57 -0700

> fec0::/10 was reserved way back in rfc 1884
> 
> 3879 and 4193 are contemporaneous activities. meany people on this list
> were present for them.
> 
> The fact that we did a bad job at something 20 years ago doesn't mean
> the problem that we were attempting to address went away.

I agree… People wanting to do NAT rather than learn how to do things better without it is an education problem which continues to persist to this day.

Owen

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 2 May 2014 14:22:24 -0400

> As an example of the case that comes to mind, see attached. It is a message sent to [email-masked] yesterday. The sender signed it using DKIM, the IETF changed the message (added some trailing text…

dkim != dmarc (but maybe that wasn't your point)

> Could we actually try such guidance in a sandbox, and document appropriate procedures for mailing lists?

which mailing list software? or did you mean test a general solution
and document the general solution?

---

From: Douglas Otis <[email-masked]>
Date: Fri, 2 May 2014 11:48:56 -0700

> and document the general solution?

Dear Chris and Fred,

There is a TPA (third-party authorization using hash labels) draft being revised aimed specifically at solving this problem without introducing new demands on mailing-list and other third-party services, or requiring per destination signatures.  The goal is to mitigate disruptions caused by strict policy requests as possible with DMARC while still allowing trusted domains (author domains) a means to effectively delist any authorized source when abuse is detected.  Delisting should only occur after third-party administrators have been allowed to correct the issue.

This approach allows author domains fine grain control over third-party conveyance of initial messages, even over multiple services as can occur with mailing-lists.  It will not increase message size.  It can scale to massive levels having little overhead.  Much less overhead than that required to support SPF or DKIM, the basis of DMARC.

Regards,
Douglas Otis

---

From: "John Levine" <[email-masked]>
Date: 2 May 2014 21:13:17 -0000

>We have been having a fairly extended discussion, much of which seems hypothetical -
>“I don’t like DEMARC because I am worried that ... with mailing lists”. I wonder if we
>could take a moment to try it and see what happens?

We've been running that experiment for at least a year.  Surprise!

Until a month ago, nobody noticed because there was, as far as I can
tell, only one person (at Linkedin) posting from a domain with a DMARC
policy.

Then the during April, both Yahoo and AOL published DMARC reject
policies, to try and mitigate their own problems after their
respective security breaches, with the bad effects we've seen.  Every
time someone posts to a list from an AOL or Yahoo address, we're
running that experiment whether we like it or not.

R's,
John

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 2 May 2014 21:28:11 +0000

> We've been running that experiment for at least a year.  Surprise!

Good to hear. Obviously not the area I’m looking at hardest.

If we’re having the level of problems that seem to be being reported in this thread, it would appear that we haven’t learned much from the experiment. I take it that the draft Doug Otis mentions is part of the mitigation discussion.

---

From: "John R Levine" <[email-masked]>
Date: 2 May 2014 18:52:05 -0400

> If we’re having the level of problems that seem to be being reported in 
> this thread, it would appear that we haven’t learned much from the 
> experiment. I take it that the draft Doug Otis mentions is part of the 
> mitigation discussion.

The problems are occuring at the end points, not at the IETF.  For 
example, [email-masked] posts to a list, where one of the subscribers is 
[email-masked].  The list adds a subject tag and footer, as our lists 
have done since forever, and remails it to Charlie.  Comcast's DMARC 
software observes that this message has an aol.com addresss in the From: 
line, but didn't come from an AOL IP host (SPF) or has it a valid aol.com 
DKIM signature, so Comcast bounces it.  This isn't hypothetical; I've seen 
exactly this in my logs.

Before anyone says "why don't we just ...", we've been arguing about this 
for a year, and any technical change to mailing lists won't avoid the 
DMARC problem, or will change the way that lists work, requiring that 
users retrain themselves and their local mail filters.  We didn't create 
this problem, and I don't think it's reasonable to ask us to bear the 
costs of fixing it.

What would work is for the systems that implement DMARC to whitelist 
senders who send legitimate mail that DMARC can't describe.  (Not total 
whitelist, just skip the DMARC bit.)  That could work, if they're willing 
to spend their own money to do it.

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

---

From: Theodore Ts'o <[email-masked]>
Date: Fri, 2 May 2014 19:35:27 -0400

On Fri, May 02, 2014 at 06:52:05PM -0400, John R Levine wrote:
> The problems are occuring at the end points, not at the IETF.  For example,
> [email-masked] posts to a list, where one of the subscribers is

If you think about the inventives of the entities in question, it's
really not that surprising.  Yahoo and AOL will want to force people
to use their web-based forums, so they have no incentive to make life
easier for mailing lists.  And Comcast has an opportunity to steal
mail users from Yahoo and AOL by telling the world the solution is to
use their comcast.net address, since they promise not to enable
p=reject (even as they enforce it with a vengeance):

	http://postmaster.comcast.net/dmarcupdate.html

						- Ted

---

From: Douglas Otis <[email-masked]>
Date: Fri, 2 May 2014 17:03:08 -0700

> If we’re having the level of problems that seem to be being reported in this thread, it would appear that we haven’t learned much from the experiment. I take it that the draft Doug Otis mentions is…

Dear Fred,

The original TPA draft is more than 2 years old.  Murray wanted a DKIM specific version and I approved of him making modifications while explaining important elements.  It seemed reasonable to assume the idea would be carried forward in his capable hands, but modifications to Murray's version made a chain-of-trust approach impossible to deploy.  After expressing dismay, Murray indicated detrimental changes were to satisfy IESG requirements imposed before publication. 

I have spent years running similar DNS schemes at much higher scale updated against millions of world-wide inputs every few minutes.  Systems we run provide the opposite of an authorization, where the greatest problem is enduring deliberate DDoS attack.  The system works well having very low overhead even with rather short TTLs.  IESG concerns are ironic, since they expressed none regarding SPF macros.  Fortunately, this SPF feature is moribund for the most part, although RFC makes it appear to be a fully supported feature.

To revive the original TPA idea to give it a second chance, a few of us will make an effort to structure TPA more generically and perhaps assuage initial IESG concerns by having TPA signaled in DMARC records, provided the DMARC group is willing.  Most spoofing affects financial transactions.  No third-party should really interfere with Author domain policy requests aimed at protecting their recipients from harm. 

Pete Resnick has taken a quick look at this issue and is convinced it can be solved using a cryptographically secured authorization token able to survive normal mailing-list flattening.  While conceptually, such a mechanism is possible, it would involve specialized handling of messages whose structure would depend on destination in addition to author domains used by DMARC whose authentication has been obfuscated by message flattening.

Bad actors are fairly proficient at quickly modulating their attack.  Momentarily valid "override" tokens envisioned by Pete requires other features to prevent massive replay of "pseudo-authenticated" messages likely requiring extensive change to tens of thousands of affected third-party services.  Users are quick to abandon systems that permit spoofing. 

In Asia, there is a high number of compromised user systems dwarfing problems seen by Yahoo.  IMHO, TPA in conjunction with DMARC feedback should enable user friendly "compromised" notification feedback having a low level of noise, and offer satisfactory protection without any modification to third-party services.  Of course, Author domains will need to offer recipients the necessary input to permit the following of a chain-of-trust.

Regards,
Douglas Otis

---

From: "John R Levine" <[email-masked]>
Date: 2 May 2014 20:33:15 -0400

> to use their web-based forums, ...

In this case, I find ineptness as least as plausible as malice:

http://jl.ly/Email/aoldmarc.html

Regards,

---

From: Hector Santos <[email-masked]>
Date: Fri, 02 May 2014 20:35:45 -0400

Hi Fred,

We have already did all this. Over the last 9 years, we have produced 
all these DKIM related documents:

    RFC4686  Analysis of Threats Motivating DKIM
    RFC4870  DomainKeys
    RFC4871  DKIM (RFC5672.TXT,  RFC6376.TXT)
    RFC5016  Requirements for a DKIM Signing Practices Protocol
    RFC5451  Message Header Field for Indicating Message 
Authentication Status
    RFC5518  Vouch By Reference
    RFC5585  DKIM Service Overview
    RFC5617  DKIM Author Domain Signing Practices (ADSP)
    RFC5863  DKIM Development, Deployment, and Operations
    RFC5965  An Extensible Format for Email Feedback Reports
    RFC6376  DomainKeys Identified Mail (DKIM) Signatures
    RFC6377  DomainKeys Identified Mail (DKIM) and Mailing Lists
    RFC6541  DomainKeys Identified Mail (DKIM) Authorized Third-Party 
Signatures

and that all doesn't include all the draft I-D produced by myself, 
Doug Otis and others.

We are well pass the hypothetical, theory, proof of concepts, etc. 
Mailing list Software with DKIM+POLICY support exists, at least ours does.

This is an issue of getting IETF endorsement to support the DKIM 
POLICY framework. The IETF just made ADSP RFC5617 historic earlier 
this year.  DMARC snuck in with large domains enabling the strong 
handing mode of operations.  That surprised the IETF and left the 
network not ready to handle this long known 9 year old DKIM+POLICY 
design/change requirement situation.  Other MLS software/operators 
need to adjust and so far, the IETF is not willing to accept a 
DKIM+POLICY framework the industry wishes to go with.

Overall, the two key changes are:

1) MLS checks/deny/notify new subscribers using restrictive policy 
domains.

2) MLS checks/deny/notify new submissions from restrictive policy 
domains list members.

Those two basic changes are needed in principle to honor the security 
policy first.

The hard part was how to scale author domain authorized 3rd party 
signers for author domain policies that allow resigning and this was 
pretty much where it was all left at, with 3rd party authorization 
proposals that piggy backed off the ADSP record with ATPS (RFC6541), 
my ASL (Authorized Signer List) proposal and Doug's TPA proposal. 
This is also where Levine's Whitelist suggestion can play a role, but 
it still needs to be author domain authorized.

I don't see us going anywhere unless a fundamental IETF acceptance for 
DKIM+POLICY occurs and that means honoring the security policy first, 
not ignore it and continuing to forward unauthorized resigned mail.

Unless the ADSP status can be reversed, and DMARC is here to stay, the 
IETF needs to update the DMARC document for 3rd party support.

Finally point, the example email attachment you had from 
[email-masked], keep in mind it does not have a DMARC policy, but it 
does a ADSP "dkim=all" which says that only the first party signer was 
expected in all mail.   But there is o reject/discard handling 
semantics as it would be for a "dkim=discardable" ADSP policy.

-- 
HLS

On 5/2/2014 2:05 PM, Fred Baker (fred) wrote:
> We have been having a fairly extended discussion, much of which seems hypothetical - �I don�t like DEMARC because I am worried that ... with mailing lists�. I wonder if we could take a moment to try it and see what happens?
>
> It seems to me that we should not approve a procedure that has that effect, at least without some guidance for mail relay administrators. I could imagine two forms of guidance: �obey the end-to-end principle; don�t change the message the originator sent�, or �if you change a signed message, first validate the message you received and discard if that fails, change it, and then sign it yourself, so that a receiver can see who changed it and validate the outcome�.
>

---

From: Theodore Ts'o <[email-masked]>
Date: Fri, 2 May 2014 22:08:41 -0400

> http://jl.ly/Email/aoldmarc.html

Perhaps, but given the economic incentives, once their ineptness are
pointed out, I don't hold out much chance that they will change their
behavior.

					- Ted

---

From: Dave Crocker <[email-masked]>
Date: Sat, 03 May 2014 09:23:10 -0700

On 5/2/2014 1:05 PM, Fred Baker (fred) wrote:
> As an example of the case that comes to mind, see attached. It is a
> message sent to [email-masked] yesterday. The sender signed it
> using DKIM, the IETF changed the message (added some trailing text)
> before forwarding it, the receiver (e.g., Cisco IT) attempted to
> validate the DKIM signature - and failed.
> 
> It seems to me that we should not approve a procedure that has that
> effect, at least without some guidance for mail relay
> administrators. I could imagine two forms of guidance: “obey the
> end-to-end principle; don’t change the message the originator
> sent”, or “if you change a signed message, first validate the
> message you received and discard if that fails, change it, and then
> sign it yourself, so that a receiver can see who changed it and
> validate the outcome”.

Fred,

Your comments are consonant with the recurring comments of others, so
it's worth repeating several fundamental points about them:

     1.  The so-called "end to end principle" was actually labeled end
to end /arguments/.  It is a guidance about a design approach that
then needs to be tailored to the specifics of the situation.  For
example, the definition of 'end' varies according to the scenario.
With direct, person-to-person email the mailbox is an end point. For
EDI over email, it isn't, since there is a further processing sequence
after email delivery.  So we need to be rather careful when asserting
the 'principle'.  In the IETF, we've grown fond of tossing out the
label as if its mere statement is useful.  However it's actual utility
only happens as part of a tailored design discussion.  Like a
protocol, its utility requires being set into motion.

     2.  In terms of basic email architecture, a mailing list is an
end-point.  The author specifies the mailing list explicitly.  The
mail gets /delivered/ to it.  A mailing list is not an MTA that is
relaying mail; it is an end-user application that /re-/posts it.  So a
mailing list is really a value-add mechanism that sits above the basic
email service.  In architectural terms, this is identical to your
choosing to forward this note to someone you think should see it.
DKIM is meant for transit protection, starting somewhere near the
(original) author and ending somewhere near the mailbox of the
specified (initial) recipient.  In the case of a mailing list, that
mailbox belongs to the mailing list.  Should a DKIM signature survive
your manual forwarding of a message?  While it's certainly acceptable
for it to survive, it's not reasonable to expect it.  Then why should
we expect the re-posting by a mailing list to preserve a DKIM
signature? Depending upon the policies of a specific mailing list,
there are many very good reasons for the changes that are made to the
original message.  Some of those happen to break a DKIM signature.

     3.  The limitations of DMARC have been well understood, including
by both Yahoo and AOL.  There is never any way for the IETF community
to protect against an organization's choosing to apply a protocol in a
way that is known to have damaging effects.

     4.  There is, in fact, a draft BCP about DMARC use that was
posted and awaits pursuit, preferably in the IETF.[1]  Working on it
got stalled by the gyrations of trying to decide how to process the
DMARC base specification.  Perhaps we should focus our energies into
firing up an IETF engine to develop and progress the BCP?

d/

[1] Using DMARC, https://datatracker.ietf.org/doc/draft-crocker-dmarc-bcp/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Hector Santos <[email-masked]>
Date: Sat, 03 May 2014 14:08:51 -0400

> way that is known to have damaging effects.

I find this philosophy quite concerning since the protocol is by 
design, offering strong deterministic policies, options and features 
to select from to both publish and honor -- its part of the protocol 
logic.  Its not there just to "look good" or for show. Its there to be 
used.

Even if only a "small use" case was the purpose, the receivers still 
had to be ready for it.   The problem here is not applying the same 
protocol principles equally and across all would-be compliant domains.

Let me ask, what if a fedex.com employee use this email domain for 
subscribing to the IETF list?  Fedex.com exposes their DKIM signing 
practice very clearly with both an ADSP "dkim=discardable" and a DMARC 
"p=reject" policy.  They wanted to cover a wider net of either 
ADSP/DMARC receivers.   So why would you treat yahoo.com or 
facebook.com "p=reject" policy any different than Fedex.com? 
Facebook.com assigns facebook.com email address now for your account. 
  So its technically possible to use it on a list.

At what point do you adjust to a new DKIM+POLICY layered world?

> firing up an IETF engine to develop and progress the BCP?

Repeating, highlighting, emphasizing in a BCP not to publish 
restrictive DMARC policies isn't going to solve the problem.

-- 
HLS

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 05 May 2014 20:21:36 -0400

> We have been having a fairly extended discussion, much of which seems hypothetical - “I don’t like DEMARC because I am worried that ... with mailing lists”. I wonder if we could take a moment to tr…
Ummm..... yahoo changed their dmarc policy to p=reject, lots of mailing 
lists broke.  What experiment is it that you think we need to run?

Miles Fidelman

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

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 6 May 2014 00:23:26 +0000

On May 5, 2014, at 5:21 PM, Miles Fidelman <[email-masked]> wrote:

> Ummm..... yahoo changed their dmarc policy to p=reject, lots of mailing lists broke.  What experiment is it that you think we need to run?

I guess we’re running it. I was hoping to avoid the “everything around broke” part.

---

From: Miles Fidelman <[email-masked]>
Date: Mon, 05 May 2014 20:26:51 -0400

> I guess we’re running it. I was hoping to avoid the “everything around broke” part.

Well.. I can certainly tell you that, as someone who supports a couple 
of dozen email lists, an awful lot broke - both for my users (who shared 
their pain with me) and for me, as an administrator. Lots of things 
stopped working, for lots of people, overnight - to me that fits the 
definition of "broke."

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 6 May 2014 00:37:59 +0000

On May 5, 2014, at 5:26 PM, Miles Fidelman <[email-masked]> wrote:

> Well.. I can certainly tell you that, as someone who supports a couple of dozen email lists, an awful lot broke - both for my users (who shared their pain with me) and for me, as an administrator. Lots of things stopped working, for lots of people, overnight - to me that fits the definition of "broke.”

And what comes quickly to mind is the comment, earlier in this thread, that “we have been running it for nine years.”

Running it, perhaps, but not learning from it. Kind of “Really Not The Point”.

Other comments withheld for an opportunity in the presence of adult beverages. Lots of them.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 06 May 2014 08:59:46 -0700

On 5/5/2014 5:37 PM, Fred Baker (fred) wrote:
>> Well.. I can certainly tell you that, as someone who supports a
>> couple of dozen email lists, an awful lot broke
...
> And what comes quickly to mind is the comment, earlier in this
> thread, that “we have been running it for nine years.”
> 

I might be a bit confused about the 'it' being referenced, so it's worth
ensuring some clarity:

     1.  DKIM and SPF have been fielded for perhaps 12 years.  DKIM in
its original-but-similar form, DomainKeys, and then its initial
'consortium' form, preceded the 2006 published DKIM RFC by several
years.  SPF appeared around that time too.  So the reference to 6 years
of operational experience is really on the very low side.

     2.  Use of DKIM and SPF is reasonably well understood and does not
cause interesting email operations problems.  I'm starting to hear some
unfortunate stories about DKIM signature breakage in scenarios that I'd
have hope would not have it, but the breakage of the signature is not
breaking legitimate email scenarios.

     3.  DMARC's functions and limitations have been reasonably well
understood since it's inception.  It works comfortably in specific
scenarios and causes problems in others.  Again, there are no surprises
about these now.  They've been clearly understood by those working on
the spec.

     4.  SPF actually has the potential for causing similar operational
problems.  It has a strict mode that will cause receiver-side rejections
if honored, and they will occur for any multi-hop sequence.  In the case
of SPF, multi-hop means /any/ sequence that produces a new client smtp
IP address, presented to the evaluating receiver.  In the case of DMARC,
given the use of DKIM, the problem is multi-hop for scenarios that break
DKIM signatures.

     5.  The reason SPF's strict mode hasn't been problematic is that
virtually no one uses it.

So what's different now is not technical, its operations policy.  A
couple of large providers chose to apply DMARC to scenarios known to
cause problems for some of their users and groups their users work with.

d/

---

From: Hector Santos <[email-masked]>
Date: Tue, 06 May 2014 13:03:28 -0400

On 5/5/2014 8:37 PM, Fred Baker (fred) wrote:
>
> I guess we�re running it. I was hoping to avoid the �everything around broke� part.
>
> ...
>
> And what comes quickly to mind is the comment, earlier in this thread, that �we have been running it for nine years.�
>
> Running it, perhaps, but not learning from it. Kind of �Really Not The Point�.

   At the end of the day, this is all about the IETF desiring a 
"Freedom to DKIM Sign/Resign Mail" at any middleware, host, router. 
hop, forwarder, mailer, list service, etc, node along the transport 
part in the mail network without author domain restrictions.

Either you believe in an author domain DKIM regulated mail system or 
not.  The resigners do not believe no one uses "strict" policies 
anyway, and if Mom&Pop biz does, WHO CARES!!  The IETF has certainly 
shown it doesn't.

That pretty much sums it up.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Tue, 06 May 2014 14:25:32 -0400

> of operational experience is really on the very low side.

9+ years was the reference, not 6.  Yes, the original DKIM+POLICY model
was conceived from DomainKeys with its built-in strict policy "o=-" 
option. DKIM's policy features was called SSP which included support 
for allowing resigners.  The problem was how to large scale authorized 
resigners.

> breaking legitimate email scenarios.

SPF is a domain policy protocol.  DKIM lacks one. DKIM is totally 
useless and unsecured without a policy layer. The DKIM Threat Analysis 
RFC4686 touches base with this. https://tools.ietf.org/html/rfc4686

> about these now.  They've been clearly understood by those working on

But the problem is that the DKIM resigners didn't support it nor its 
predecessor ADSP for any use case, large or small.

> virtually no one uses it.

No, it wasn't a problem because the "YAHOOs" didn't do a -ALL policy 
or those domains that did not have a handle on their network of mail 
senders.  Those that did use -ALL and there are thousands of domains 
who are, including ietf.org with its string -ALL SPF policy, had very 
little problems with them.

   v=spf1 ip4:12.22.58.0/24 ip6:2001:1890:123a::/56
          ip4:64.170.98.0/24 ip6:2001:1890:126c::/56
          ip4:4.31.198.32/27 ip6:2001:1900:3001:0011::0/64
          ip4:209.208.19.192/27 ip6:2607:f170:8000:1500::0/64
          ip4:72.167.123.204
          -all

But in principle, whether it was YAHOO or another domain, the SPF 
network of SPF receivers did support the -ALL rejection semantics. 
That wasn't the case with ADSP Discardable and DMARC p=reject until 
now with the switch turned on.

> cause problems for some of their users and groups their users work with.

Dave, its a technical problem because the DKIM-WG intentionally 
deemphasized an author domain policy lookup layer seeking to replace 
it with a 3rd party signer domain trust/reputation lookup service 
model.  The latter hasn't materialized so DKIM was left unprotected 
without the author domain policy layer.  The removal of policy has 
caused interop problems.

The goal now is to give DMARC 3rd party semantics and support within 
the DKIM framework where the resigners can coexist cooperatively.

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Tue, 6 May 2014 11:39:04 -0700

On May 6, 2014, at 10:03 AM, Hector Santos <[email-masked]> wrote:

>  At the end of the day, this is all about the IETF desiring a "Freedom to DKIM Sign/Resign Mail" at any middleware, host, router. hop, forwarder, mailer, list service, etc, node along the transport part in the mail network without author domain restrictions.
> 
> Either you believe in an author domain DKIM regulated mail system or not.  The resigners do not believe no one uses "strict" policies anyway, and if Mom&Pop biz does, WHO CARES!!  The IETF has certainly shown it doesn't.
> 

Hector,

Perhaps a different perspective could be useful.  Rigidly constraining From header fields or Return Paths disrupts legitimate communication since this does not identify actual email sources.  Source assessment is a far more effective mitigation control over content filtering as demonstrated by evolving RTF, Flash, Java, and Office vulnerabilities.  SMTP lacks a federation feature found in XMPP.  Not having a means to federate control makes it difficult to exclude a malicious source.

TPA approximates a federation scheme, whether from authentication invoked by a From header field policy request or any other domain authentication method used.  TPA allows a sender (as an anchor) a means to authorize domains employed by their users within a single DNS transaction.  This allows a means to establish an email-chain-of-trust making use of various authentication methods.  DMARC attempts to improve reliability by combining either aligned DKIM signed content or SPF authorization.  TPA attempts to overcome impediments these methods impose in describing the actual system federation. 

In developing regions, the percentage of compromised systems is high.  A federated system should greatly assist in identifying where malicious content is being introduced and reduce the level of false detections, notifications, and blocking actions. 

Regards,
Douglas Otis

---

From: [email-masked]
Date: Tue, 06 May 2014 22:01:14 -0700 (PDT)

> of operational experience is really on the very low side.

The relationship of time to operational experience is far from obvious, even
for specifications we view as successfully deployed.

> breaking legitimate email scenarios.

That's incorrect. The obvious counterexample is MIME downgrading, which was a
core MIME capability from the start.

I note in passing that DKIM could have been engineered to accomodate
this by canonicalizing to binary and removed CTEs, but wasn't.

> about these now.  They've been clearly understood by those working on

I can't speak to what was in the minds of the developers, but I view the fact
that the specification is noticeably lacking in describing these limitations 
as problematic.

I haven't had time to do a careful review of the DMARC specification, but I do
note one obvious omission: Wouldn't it have been helpful to define an enhanced
status code for a p=reject failure which mailing lists could detect and take
appropriate action, i.e. counting this as a failure of the sender, not the
recipient?

> IP address, presented to the evaluating receiver.

All very true, but SRS and similar schemes provide a reasonable way to address
SPF issues.

> In the case of DMARC,

And AFAIK no mitigation strategy comparable to SRS is possible with DMARC as it
is presently constituted.

> virtually no one uses it.

The customers we have who have been forced to deploy SRS are just a figment of
my imagination then.

I'll also note that strict mode is sufficient but not necessary to cause
problems to forwarders. A lot of places factor SPF failures into spam scores.
An increase in those scores may result in an overall higher failure rates.

> So what's different now is not technical, its operations policy.

Operations policies aren't technical in nature? They sure seem technical to me.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Wed, 07 May 2014 07:48:16 -0400

> appropriate action, i.e. counting this as a failure of the sender, not the

That was part of the discussions. But for backward compatibility, a 
ACCEPT and DISCARD could be a deployment optional alternative to a 
reject action.

But YAHOO and others could of had a more graceful migration to 
p=reject.   It could of quarantined and/or just prepared a special 
notification to the recipient:

    Dear Yahoo user,

    It appears you are subscribed to a mailing list {LIST-ID} which is
    signing the message with the domain {LIST-ID.DOMAIN}.

YAHOO can decide on path #1

    You will need to switch to a different to a different account.
    Within one month, this mail from the list to you will be rejected.

YAHOO can decide on path #2

    Please click the following link if you wish to WHITELIST this list:

    {URL}?list-id={LIST-ID}?hash={SOME-UNIQUE-USER-ACTION-HASH}

But you know, it is probably just easier to reject and not worry about 
it. Just like our system when we reject for SPF. Its not prepared to 
do something like the above. Honestly, the DMARC whining has died down 
on our end just like it happen for SPF back in the early days of 
rejection.  DKIM+POLICY using DMARC is doing what it suppose to do 
when followed.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Wed, 07 May 2014 08:10:01 -0400

On 5/7/2014 7:48 AM, Hector Santos wrote:

>> I haven't had time to do a careful review of the DMARC specification,
>> but I do note one obvious omission: Wouldn't it have been helpful to define
>> an enhanced status code for a p=reject failure which mailing lists
>> could detect and take appropriate action, i.e. counting this as a failure
>> of the sender,  not the recipient?
>

Sorry, it wasn't part of the DMARC discussion but it was discussed 
with with SSP and ADSP. See RFC6377 "DKIM and Mailing Lists".

With ADSP "dkim=discardable" policy, the deployed SMTP server could 
process it at DATA and reject it as a 550 rather than do ACCEPT and 
DISCARD. A reject mode would cause a list sender problem.

With DMARC "p=reject" policy, it would the opposite semantics to offer 
the reject as a accept/discard.

-- 
HLS

---

From: "John Levine" <[email-masked]>
Date: 7 May 2014 12:30:34 -0000

>core MIME capability from the start.

I'm not Dave, but I think he meant that the DKIM design didn't depend on
signatures surviving through list managers.  The list signs the mail and
recipients can use that.

We considered other ways to canonicalize but decided there was no way to
catch every plausible mutation (consider a list that flattens HTML to
plain text and then adds a footer), so we kept it simple.

R's,
John