Subject: [dmarc-ietf] DKIM through mailing lists

From: Brandon Long <[email-masked]>
Date: Wed, 28 May 2014 15:33:57 -0700

We could attempt to define a dkim canonicalization that would pass through
a mailing list.

It should include the subject, but have rules for stripping "standard"
subject prefixes.  It should obviously include other headers, but not
List-* headers (since the RFC for those says the mailing list should strip
the existing ones).

The body is challenging.  We could have it specify a length... that does
allow for some weirdness with html positioning.  We could require no-html
part.

We could optionally require footers to be added as separate parts, and have
the canonicalization be for "first text part".

Of course, footers are 99% unnecessary.   Take this list, the
name/address/archive are already in the List-* headers.  We have other
issues, ie recent anti-spam legislation may require an unsubscribe link in
the footer, depending on interpretation, especially if anyone on the list
was subscribed "directly" and not double opt-in.

Is the above possible?  Probably.  Are the holes too big?

I do prefer this over many of the alternatives, as long as we can figure
out something that the majority of lists won't break.  That puts the onus
on the providers who are honoring dmarc to sign their mail with the new
canonicalization and support it when checking signatures.

Brandon

On Wed, May 28, 2014 at 2:54 PM, Dave Crocker <[email-masked]> wrote:

> On 5/28/2014 2:52 PM, Scott Kitterman wrote:
> > How do we define the scope of work for this list?
>
>
> Merely as an example, one line of effort could be towards methods of
> DKIM signature survival through mailing lists.
>
> It's not a new topic and it's not an easy one, and it doesn't even have
> the string D-M-A-R-C in it, but any real progress for this could be
> quite helpful in mitigating collateral damage with especially aggressive
> DMARC use.
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Barry Leiba <[email-masked]>
Date: Wed, 28 May 2014 18:46:41 -0400

> We could attempt to define a dkim canonicalization that would pass through a
> mailing list.

This was beaten pretty severely during the DKIM work, and we couldn't
come up with anything that was workable.

> subject prefixes.  It should obviously include other headers, but not List-*
> headers (since the RFC for those says the mailing list should strip the
> existing ones).
>

Anything that requires mailing list software to change won't work.  If
mailing list software is changed, the right answer is for the mailing
list to re-sign the message.  That doesn't help the DMARC situation
now, but DMARC could be given other options once that happens.

We discussed using l= at (um...) length, and no one liked that
approach.  There were too many holes, yes: allowing arbitrary amounts
of data to be added to the message text, having it fail anyway if text
isn't added at the end (such as for multipart messages), and so on.

Heuristics involved in tweaking the subject are problematic.

Some of this could perhaps work if we had a canonicalization that was
*specific* to mailing list posts... but then how would the signing
domain know that the message it was signing was going to a mailing
list?

I really think this isn't a useful approach, but perhaps someone might
come up with the necessary "aha" to make it work.

Barry

---

From: Brandon Long <[email-masked]>
Date: Wed, 28 May 2014 16:05:04 -0700

On Wed, May 28, 2014 at 3:46 PM, Barry Leiba <[email-masked]>
wrote:

> List-*

If the mailing list signs and verifies, that's OAR... and then the
challenge becomes knowing when to trust the OAR.

Also, it seems to me that mailing lists without changes and DMARC are
basically incompatible, so I'm unclear of any solution that will allow them
to work unchanged.

> domain know that the message it was signing was going to a mailing

Theoretically, a client could easily know its a mailing list in most cases,
but yes, where the signing often occurs, its unlikely to know.  The easiest
thing to do would be to sign it both ways, and then the receiver might only
trust the mailing list canonicalization if it went through a mailing
list... and of course that can be forged as well.

> come up with the necessary "aha" to make it work.

I think it depends on what the goal is.  If the goal is "unforgeable
messages through a mailing list to pass DMARC", then yes, this is probably
not going to work.  The only solution there is for the mailing lists to
actually not munge messages.

I might argue that "if the mailing list is going to munge the message, then
it needs to munge From as well"... but there seems to be a fairly high
resistance to that.

I suspect that many parties that implement DMARC are "cheating" by allowing
things that look like mailing list or forwarded mail through even if they
fail auth and the domain is p=REJECT.  Providing a higher bar for when to
"cheat" may be useful, then.

Now, my anti-spam colleagues will say that any hole will eventually be
exploited... but given that I don't see how we can make this work with no
holes, and if we can't change mailing lists... and any sort of whitelisting
is adding a hole... I feel like I'm in a circular argument.

Brandon

---

From: Douglas Otis <[email-masked]>
Date: Wed, 28 May 2014 17:21:38 -0700

On May 28, 2014, at 4:05 PM, Brandon Long <[email-masked]> wrote:

> 
> 
> 
> On Wed, May 28, 2014 at 3:46 PM, Barry Leiba <[email-masked]> wrote:
> If the mailing list signs and verifies, that's OAR... and then the challenge becomes knowing when to trust the OAR.

Exactly. TPA-Label provides this answer.

> Also, it seems to me that mailing lists without changes and DMARC are basically incompatible, so I'm unclear of any solution that will allow them to work unchanged.

Again, TPA-Label provides this answer.
By the way, the TPA-Label draft has been updated to include Original-Authentication-Results draft reference which also states this concern as well. 

> Theoretically, a client could easily know its a mailing list in most cases, but yes, where the signing often occurs, its unlikely to know.  The easiest thing to do would be to sign it both ways, and then the receiver might only trust the mailing list canonicalization if it went through a mailing list... and of course that can be forged as well.

That is what spam-traps and DMARC feedback provides.  When a problem is detected and reported to the DMARC domain, the response can be to withdraw authorization and report problems to third-party service providers.  Fast and easy.  Depending on the urgency, it would be nicer to report problems to the service provider and give then an opportunity to fix issues before causing an unnecessary disruption. The point is to ensure everyone has an incentive to cooperate.

There are many cases that are never originally signed by the DMARC domain.  Such as an accounting package that sends out invoices on behalf of some company that wants their email address in the From header since this is what their customers will recognize. 

> I think it depends on what the goal is.  If the goal is "unforgeable messages through a mailing list to pass DMARC", then yes, this is probably not going to work.  The only solution there is for the mailing lists to actually not munge messages.
> 
> I might argue that "if the mailing list is going to munge the message, then it needs to munge From as well"... but there seems to be a fairly high resistance to that.

This would be an understatement which also ignores other valid uses.  People might remember someone said something profound without recalling related details. Not being able to search through their message stream would be fairly frustrating. Not all mailing lists offer usable reference header fields for such use (perhaps to ensure user privacy).  References: <CABa8R6v6tk7ZdgtTkBQGT6F7A17VP=[email-masked]> might not be something that can be used by most MUAs to review what someone said in the past, for example

> I suspect that many parties that implement DMARC are "cheating" by allowing things that look like mailing list or forwarded mail through even if they fail auth and the domain is p=REJECT.  Providing a higher bar for when to "cheat" may be useful, then.
> 
> Now, my anti-spam colleagues will say that any hole will eventually be exploited... but given that I don't see how we can make this work with no holes, and if we can't change mailing lists... and any sort of whitelisting is adding a hole... I feel like I'm in a circular argument.

The hurdle that seems to be in everyone's mind is how to go about facilitating feedback that is not a lot of work.

Some have used specialize DNS servers to cut corners.  http://www.corpit.ru/mjt/rbldnsd.html is an example related to dealing with email abuse.  There are off-the-shelf DNS servers able to return 30K resource records without an issue.  Add a few scripts and voila. 

A specialized server however may assist in the administration of providing DMARC related authorizations for third-party domains.  This could be mailing-lists, office and facility services using a separate Sender header, "acquaintance" initiated message services, etc.  It seems the same specialized server could be tasked with processing DMARC feedback looking for confirmation in outbound logs.  The server itself might even look for which log domains match hashed labels.  This could provide a heads-up something is outside the federation.  Once the initial corpus has been accommodated, keeping the system maintained should become progressively easier.

Or of course we could say it is too hard which places this problem back into making guesses.  When that happens, vast amounts of abuse will suddenly appear.  Malefactors quickly learn where the gray areas exist.  The goal is to ensure there is as little guesswork as possible while keeping the DMARC domain in control.

It seems unlikely there will be many outside service providers willing to make decisions about which DMARC related messages are legitimate or not.  Only the DMARC domain can realistically be expected to make those decisions.  This then means the real task is to then communicate these decisions to all of the DMARC domain's potential receivers.

Regards,
Douglas Otis

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 28 May 2014 20:47:12 -0500

> now, but DMARC could be given other options once that happens.

That's right.  But maybe there could be a multipart/dkim type that lets 
several signatures exist in a message - all of which could potentially 
verify with different d=.  Then the list only needs to sign what it adds 
to the end somehow and it leaves the rest of the message alone.  Seems 
like we went over this way back years ago but I'm old now :)

Arvel

Disclaimer:  This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information.  Any use of this information by anyone other than the intended recipient is prohibited.  If you have received this transmission in error, please immediately reply to the sender and delete this information from your system.  Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 28 May 2014 18:54:03 -0700

On 5/28/2014 6:47 PM, Arvel Hathcock wrote:
> verify with different d=.

Hi Arvel.  Great to see you re-entering the fray...

Picking a nit:  It's not a MIME level issue.  It's in the main header.

More substantive:  Multiple signatures are ok now.  And are sometimes
done now.

So the real challenge is who should sign what and how should it/they get
used?

d/

---

From: Hector Santos <[email-masked]>
Date: Wed, 28 May 2014 22:18:53 -0400

On 5/28/2014 9:47 PM, Arvel Hathcock wrote:
> That's right.  But maybe there could be a multipart/dkim type that
> lets several signatures exist in a message - all of which could
> potentially verify with different d=.  Then the list only needs to
> sign what it adds to the end somehow and it leaves the rest of the
> message alone.  Seems like we went over this way back years ago but
> I'm old now :)
>

Yup, and the solution was policy.  The problem is this group wants to 
skip doing any kind of policy lookup.

We are also list developers.  We don't have a free reign on resigning 
mail without permission, if any. Its irresponsible. It has to follow a 
policy framework.  All software has to follow it.  List systems are 
not the exception. No resigner is an exception and trying to get 
around this has not worked.

Keep it simple -- lookup policy.

But DMARC lacks 3rd party semantics, so you need extensions and that 
was done with ATPS for ADSP. See the wizard that supports it for ADSP 
and now a new beta using DMARC:

http://www.winserver.com/public/wcADSP
http://www.winserver.com/public/wcDMARC

You can easily add ATPS support to your DKIM C/C++ library.

-- 
HLS

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 29 May 2014 23:07:38 +0900

Douglas Otis writes:

 > There are many cases that are never originally signed by the DMARC
 > domain.  Such as an accounting package that sends out invoices on
 > behalf of some company that wants their email address in the From
 > header since this is what their customers will recognize.

I don't understand this example.  This use case seems quite compatible
with DMARC as it is.

That is, company and accountant should have a substantial and
expensive to maintain trust relationship already.  I would think that
the company could (a) provide an alias (subdomain) in its own domain
for the accountant's host, and advertise the accountant's policy via
_dmarc.invoices.example.com, or (b) maintain an authenticated channel
(ie, special purpose VPN) direct to a special host under its own
control in its own domain for the accountant to relay through, and the
company signs there.  Sure, there'd be some additional cost, but not
prohibitive.  Note that in either case the client can fire the
accountant in an instant by changing the DNS or shutting down the
authenticated channel.

 > > I suspect that many parties that implement DMARC are "cheating"
 > > by allowing things that look like mailing list or forwarded mail
 > > through even if they fail auth and the domain is p=REJECT.
 > > Providing a higher bar for when to "cheat" may be useful, then.

 > The hurdle that seems to be in everyone's mind is how to go about
 > facilitating feedback that is not a lot of work.

Again, I seem to require an additional clue.  DMARC feedback is
working fine AFAICS.  It may be costly, and we want to reduce those
costs, of course.  But "p=reject" OTOH is a more or less legitimate
denial of service, a completely different issue.  Are you talking
about a different kind of feedback?

Steve

---

From: Douglas Otis <[email-masked]>
Date: Thu, 29 May 2014 12:01:32 -0700

> accountant in an instant by changing the DNS or shutting down the

Dear Stephen,

https://community.intuit.com/questions/899989-please-make-quickbooks-pass-the-dmarc-evaluation-please-do-this-quickly

I know of many small operations with similar services and previously working strategies.  With a low profit margin, no one wants to then be dealing with DNS or VPN configurations or deciding who is allowed to have access to their networks or their DKIM private keys.

Think of the heating and air conditioning outfit given VPN access for the purpose of submitting invoices. That error in judgement cost hundreds of millions for a well known retailing outfit.  There are also similar types of risks when anyone opens any MS Office document given to them by a spoofed party.

http://krebsonsecurity.com/2014/05/the-target-breach-by-the-numbers/

The intent behind TPA-Label is to permit a secure scheme without ever asking anyone to share credentials.  Not ever!   Instead, everyone uses what they already have, perhaps even stronger schemes than what is offered by DKIM or SPF.  Large ESPs that have had a major security breach should set aside a budget related to restoring order.  A TPA-Label setup could be part of that effort.

Two DNS servers (for redundancy) and some DMARC and MTA log processing scripts should offer a comprehensive and fairly complete starting point. Yes, even for a large ESP. Of course there will be ongoing support issues, but this should also pale in comparison to unsolvable email complaints of affected legitimate email use.  For this, there should be web-based forms to supplement DMARC feedback.

By setting up a TPA-Label extension, it would also allow their users to know when they have themselves been compromised, while also preventing unauthorized use by rogue servers.  This added feature seems like a nice way of saying "Sorry, but we are now doing more to improve security."

>> facilitating feedback that is not a lot of work.

Again, TPA-Label also permits a way to squelch DMARC feedback already evaluated. Perhaps a flag could even be added that basically says.  "Yes we know about this domain, and we think it cannot be trusted."  This would be a change to the current draft.

> about a different kind of feedback?

Rather than having a channel only between receiver-to-sender, there should also be a channel between sender-to-receiver.  The channel can represent a single DNS resource record. Such a single resource record would offer low latency, low cost, and cacheable near the receiver for even lower latency.

I know that John and Tim would have little trouble setting up such a service.  The real challenge is to have an ESP do this that really needs such a solution.  Once in place, this opens up a range of services others could easily offer on behalf of those who simply desire greater email security.

Regards,
Douglas Otis

---

From: Tony Hansen <[email-masked]>
Date: Thu, 29 May 2014 23:11:28 -0400

On 5/28/14, 6:46 PM, Barry Leiba wrote:
> Anything that requires mailing list software to change won't work. 

I'm going to push back on this statement. I think we keep getting stuck 
on the mantra that "the mailing list software won't change". However, 
the majority of the mailing list software packages that are out there 
now DO generate proper List-* headers. It took some time, and it may not 
be 100% coverage, but by gosh and by golly, most of them do so and do it 
correctly.

Why? There were a few things: 1) a well defined spec about what change 
was desired, AND 2a) there was perceived benefit to adding those 
headers, or 2b) there was perceived harm in not adding those headers.

> If mailing list software is changed, the right answer is for the mailing
> list to re-sign the message.

I think this is exactly the correct solution for mailing lists to 
pursue. This is an excellent start of a spec for what mailing lists 
should be doing in a world where systems are using DKIM and SPF, and 
more systems are expecting such mail to pass validation. (A post-DMARC 
world, if you will.)

There may be alternative solutions that are less optimal that will also 
get mailing list messages delivered more reliably. (For example, delete 
all DKIM signatures and force the From: header to use the originator's 
name in the comment but with the mailing list address instead of the 
originator's address. It works, but isn't pretty.) It might be worth 
doing some investigation of those alternatives, and showing their 
advantages and disadvantages.

Mailing lists have an expectation of being able to get their mail 
delivered. That is no longer the case. The benefit of them making 
changes is that their messages will get delivered more reliably. The 
harm in not making changes is that their service will continue to be 
unreliable.

But clear specs detailing what they CAN do and SHOULD do is the starting 
point.

> That doesn't help the DMARC situation

I agree completely that a change to DMARC is needed in conjunction with 
having clear ML specs.

When HeartBleed came out recently, it was discovered that openssl had 
rather poor support, even though everyone and their neighbor seems to 
use it in some fashion or another. A consortium was then formed to 
provide some needed support and to improve the quality control for openssl.

I've heard it said that the majority of the mailing lists out there are 
managed by only a handful of ML management systems. I maintain that 
these ML packages are in the same boat as openssl. It sure would be nice 
if we could get some of that consortium money thrown at that handful of 
ML management systems. That's a political solution for this current 
technical problem.

However, before it can happen: we NEED clear specs as to what should be 
done by ML systems, at least in the face of DKIM and SPF (and DMARC)

     Tony Hansen

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 29 May 2014 23:44:14 -0400

> done by ML systems, at least in the face of DKIM and SPF (and DMARC)

The reason there is no IETF working group is that the people behind DMARC were 
unwilling to entertain participation in a working group that had a charter 
that allowed for any chance of a change to the DMARC protocol.  

DMARC change is even more off the table than MLM software change (which does, 
as you suggest, evolve over time).

Yahoo's view, based on their public statements clearly seems to me to be that 
using DMARC p=reject is beneficial to them and they are big enough that 3rd 
parties will adapt rather than suffer the consequences of not adapting.

I believe they are right on both counts.  Mailing lists and other related 
systems that are affected by this are adapting.  It's painful and the solutions  
inevitably involve regressions in functionality, but they are one of the few 
800 pound gorillas and they can get away with it.

I am entirely sympathetic to people that are unhappy about this state of 
affairs (I'm unhappy about it too), but it is what it is.

I wrote the other day asking what IETF work is there around DMARC and didn't 
get much of an answer.  I think that's instructive.  I'm increasingly 
convinced that there isn't any.  At this point, while there's value in a 
central point for operators and developers to exchange information about how 
to mitigate the damage caused by what is in my opinion irresponsible use of 
DMARC, I don't think there is anything to standardize.  Eventually, there's 
probably a BCP in this, but it's premature.

If the IETF tries to go off and write a BCP on DMARC work arounds now, we'll 
end up looking silly by the time the metaphorical ink is dry.  We've all got 
lots of ideas on practices that would be a good idea, but many of them are new 
enough they can only barely be described as current and knowing what among 
them is best is premature.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Thu, 29 May 2014 23:19:17 -0700

Dear Tony,

See comments inline:
On May 29, 2014, at 8:11 PM, Tony Hansen <[email-masked]> wrote:

> I'm going to push back on this statement. I think we keep getting stuck on the mantra that "the mailing list software won't change". However, the majority of the mailing list software packages that are out there now DO generate proper List-* headers. It took some time, and it may not be 100% coverage, but by gosh and by golly, most of them do so and do it correctly.

I agree with Barry.  It is not just getting tens of thousands of mailing-lists updated into something that offers what is surely going to be a substandard user interface. This also means ensuring the added list headers allow selecting a particular participant in a straight forward manner. And that this selection also operates in conjunction with MUAs.  There is a sizable variation in this regard, many of which will not facilitate this ability.  

The next question that needs to be considered is the timeframe for such migration.  How many years is reasonable?

Secondly, what can be done to help facilitate various informal services to permit them to be effective at acting on behalf of their clients while still ensuring the From header field contains an identity the eventual recipient will recognize?  It seems that in order to be able to do this, a way to make exceptions for Sender header fields is needed as well. If making exceptions for Sender header fields can be accommodated, then simply make this exception for List-ID headers too.

Any effort at arranging domain alignments will be shuffling around where people must look to understand who substantially originated the content.  Keeping these changes to a minimum would be ideal.  After all, these changes will create a fair amount of confusion for recipients, where they then become vulnerable to a whole new range of deceptions.  As it is now, most have already begun to ignore DMARC assertions placed against user accounts which then degrades even modest protections this may have initially offered.

Perhaps you might also consider: 
https://community.intuit.com/questions/899989-please-make-quickbooks-pass-the-dmarc-evaluation-please-do-this-quickly

I know of several other professional services sending email on behalf of their clients.  It seems these situations also run afoul of this rather simplistic DMARC approach. 

> Why? There were a few things: 1) a well defined spec about what change was desired, AND 2a) there was perceived benefit to adding those headers, or 2b) there was perceived harm in not adding those headers.

Hmmm. Perhaps we could call this new header "Sender". ;^)

> I think this is exactly the correct solution for mailing lists to pursue. This is an excellent start of a spec for what mailing lists should be doing in a world where systems are using DKIM and SPF, and more systems are expecting such mail to pass validation. (A post-DMARC world, if you will.)

How many people have problems with mailing-lists?  After all, problematic lists fade away rather quickly. 

The real issue was caused by millions of users accounts being compromised.  The providers that even played a small role in that problem should contribute to what should also be an expedient solution. 

The described changes to lists and many many other services will never offer an expedient solution for several very difficult and important reasons.  Mailing-lists have not caused this problem, and yet the same ESPs are expecting mailing-lists and the like to handle a major portion of the change. This change is to permit From header field alignment with the source or a replay-able signed message fragment. This rather dramatic change moves email a large distance into becoming a far less versatile peer-to-peer protocol.  Perhaps it would be simpler to move SMTP to historic and adopt use of XMPP instead?  After all, that service already offers the concept of federated services and does not offer any mailing list feature at this time.  After all, it is hard to get ad impressions shipping around signed messages.  ;^P

> There may be alternative solutions that are less optimal that will also get mailing list messages delivered more reliably. (For example, delete all DKIM signatures and force the From: header to use the originator's name in the comment but with the mailing list address instead of the originator's address. It works, but isn't pretty.) It might be worth doing some investigation of those alternatives, and showing their advantages and disadvantages.

I have setup and run systems that tracked email from several very large ISPs of all used IPv4 addresses.  Taking in the entire inbound traffic and comparing it to what was hitting various spam-traps was done on a moderate server producing updates for the entire dataset in less than 15 minutes (often in less than 5). While this was all done using mostly C code, it was rather small and extremely efficient.  Even so, this could have been done much more efficiently for domains using Judy techniques, instead of IP addresses, especially IPv6 addresses.  In addition, today's servers have become much faster.  A good guess would be corrective information can be produced using two DNS servers in conjunction with two log aggregation servers.  The use of two is for redundancy.  DNS offers low latency and very good edge caching.

Doing this by domain makes the problem much easier.  Even then, the actual domain alignment problems only comprise a very small sub-portion of the email stream. The systems needed to manage this would also be fairly small, nor would this require operators to learn a new language. :^)

The sender information necessary to overcome difficulties would be deployed by the same entities demanding that email be handled differently.  This only seems fair.

There are some very real benefits by handling the problem in this manner.  This requires senders to actually monitor their DMARC and user web portal feedback. Gasp. At least their support staff would have fewer angry complaints.  After doing this, they'll discover two important pieces of information that receivers are unable to divine.  Which sources represent rogue servers, and which appear to be legitimately handling their users messages.  What is left and is still hitting their spam traps are likely compromised customers.  This would offer their customers better protection from spoofing permitted by loss of account credentials and exposed messages and contact lists.  Don't think for one minute authorizing responsible domains means this will permit a torrent of abuse.  The effected domain is still able to just their authorization and shut done a source in minutes. 

> Mailing lists have an expectation of being able to get their mail delivered. That is no longer the case. The benefit of them making changes is that their messages will get delivered more reliably. The harm in not making changes is that their service will continue to be unreliable.
> 
> But clear specs detailing what they CAN do and SHOULD do is the starting point.
> 
> I agree completely that a change to DMARC is needed in conjunction with having clear ML specs.

May I recommend:
http://tools.ietf.org/html/draft-otis-tpa-label

Saying that it would be too hard is simply being lazy.  It can also be implemented fairly quickly, as this impacts those actually wanting this change.

Regards,
Douglas Otis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 30 May 2014 00:37:28 -0700

> that allowed for any chance of a change to the DMARC protocol.

I think that's a bit hyperbolic.  There was perhaps too much emphasis on
protecting the deployed base, but had they been confronted with actual data
about something that wouldn't work (rather than the typical theory-only
assertions on which working groups like to rathole), there would have been
ample justification for a change.

> as you suggest, evolve over time).

Are there changes people want to make?  So far all I've seen is "something
needs to change", but nothing concrete, or at least nothing that has
garnered consensus of some sort.

> get much of an answer.  I think that's instructive.

I think that conclusion is premature.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 30 May 2014 09:35:35 -0400

On May 30, 2014 3:37:28 AM EDT, "Murray S. Kucherawy" <[email-masked]> wrote:
>> The reason there is no IETF working group is that the people behind
>DMARC
>> were
>> DMARC change is even more off the table than MLM software change
>(which
>> does,

At this point, I could probably craft a reasonable problem statement. I don't know what the solution is, but the solution space is certainly different if DMARC changes to deal with the current mess are on the table. 

Currently such changes aren't up for consideration, so no one is expending much mental energy in that direction.  It's not even an IETF specification.

Change the potential solution space and you'll change the discussion. 

Scott K

---

From: Elizabeth Zwicky <[email-masked]>
Date: Fri, 30 May 2014 17:07:30 +0000

>as you suggest, evolve over time).

DMARC changes are not off the table for Yahoo. Right now, the option that
best serves the majority of our customers is one that also has unpleasant
consequences for a significant number of people (our customers and
others). We would vastly, vastly prefer a world where that was not true,
or even where it was less true.
So changes that maintain effective protection for users who are being
targeted by attackers with addressbook information, with less disruption
to email that people want, are of great interest to us.

	Elizabeth Zwicky
	[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 30 May 2014 13:20:32 -0400

> to email that people want, are of great interest to us.

Great.  Then instead of submitting DMARC as is via a non-IETF process, let's 
have a working group chartered to do that work.

I'm glad to hear it.

Scott K

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 31 May 2014 03:28:05 +0900

Murray S. Kucherawy writes:

 > > (which does, as you suggest, evolve over time).
 > 
 > Are there changes people want to make?

I am of the opinion that the technical DMARC protocols (including
"p=reject") are fine.  I have not heard of any complaint about use by
banks (Bank of America joined the ranks of "p=reject" banks some time
in the last 10 days AFAICT).  Have there been any?  I'm sure that the
probability of technical bugs in the protocols remaining is not zero,
but I imagine they'll be fixed as discovered.

I believe that is also the opinion of the Mailman developers
(specifically, they've seen a document where I expressed a similar
opinion and generally expressed approval of the document as a whole).

The issue is use of "p=reject" by ESPs whose users think they can send
mail to anywhere they want.  I would like the logical consequences of
unilateral publication of "p=reject" without prior arrangement with
*all* possible relays spelled out.  Something like:

    Publishing a DMARC policy including "p=reject" has the following
    consequences.  Users who attempt to

    1. post to a mailing list
    2. use QuickBooks
    3. send content to a friend from the Wall Street Journal
    etc, etc

    may find their message bounces or is silently discarded.  This is
    expected according to the DMARC specification when faithfully
    implemented, even when all services in all domains are functioning
    normally and in conformance to all relevant Internet standards.

    ESPs SHOULD notify their users of these consequences at the time
    of publishing a policy including "p=reject".

N.B. I haven't discussed this with the Mailman community, but I
suspect they would approve.  As a technical specification of what the
ESP refuses to fully support by publishing "p=reject", I think the
list Franck Martin posted is a pretty good start.

To ESPs who object, "But that's not what we meant!" I reply, "I know.
But Code is Law, everything else is cheap talk.  Those are the results
*your* protocol and *your* policy say *your* users should expect.  Why
don't you want to tell them about it?  After all, you're doing it for
them.  Your users will undoubtedly be overjoyed to discover how hard
you are fighting spam on their behalf, right?"

---

From: Steven M Jones <[email-masked]>
Date: Fri, 30 May 2014 15:23:00 -0700

On 05/30/2014 11:28 AM, Stephen J. Turnbull wrote:
> in the last 10 days AFAICT).  Have there been any?

Disclosure: Technically I could be considered on BofA payroll through
tomorrow. In essence I stopped being their employee earlier this year.

While BofA does have some domains with "p=reject" they had not, so far
as I know, published such a policy on a domain that sent email as part
of a product or service. There were at least two product teams that were
working to do so, and one of them had a "p=quarantine" published but
hadn't solidified plans of when they would start sending email. The fact
that this hadn't happened by nearly two years after the first release of
the DMARC spec was not because I wasn't pushing for it...

If you really want to know, I would look for anecdotes around JPMChase,
who managed to publish "p=reject" for many if not all of their most
visible production domains over a year ago, if I have the timeframe right.

But I'm not aware of any complaints about DMARC when used in the manner
you're referring to.

--Steve.

---

From: Steven M Jones <[email-masked]>
Date: Fri, 30 May 2014 18:41:25 -0700

On 05/30/2014 11:28 AM, Stephen J. Turnbull wrote:
> "p=reject") are fine.  ... I'm sure that the

Yes, technical bug probability aside, it works well and at scale, and
has for more than two years.

Speaking strictly for myself, I expected DMARC and/or other specs and
practices to evolve such that together they would support more use cases
overall. The need to address those areas was well understood and was
commented on publicly for quite a while, even if it wasn't adequately
documented in the spec.

Unfortunately previous activity to establish an IETF working group -
where I had thought that evolution would happen - failed. The upshot was
that the expected development didn't happen, and DMARC has been
effectively static. In the meantime the large scale abuse of email
continued to morph, to the point where DMARC was seen as the least
harmful option to address a pernicious trend.

I would like to see an IETF working group formed, so that we maintain
the use cases where DMARC is currently effective and support additional
use cases where it currently isn't.

> I would like the logical consequences of
> *all* possible relays spelled out.

I agree that a solid list of known consequences would be good. And I'm
sure it will grow beyond what any of us expect...

--Steve.

---

From: Steven M Jones <[email-masked]>
Date: Fri, 30 May 2014 18:46:45 -0700

On 05/30/2014 10:20 AM, Scott Kitterman wrote:
>> DMARC changes are not off the table for Yahoo. ...

The Independent Submissions stream is an IETF process. However it does
not involve a working group.

Whether due to too much concern over potentially incompatible changes,
or too much alarm at the language used to try to avoid it, past attempts
to form a working group failed. More than one attempt was made. The
Independent Submission stream was not the first choice.

I have wanted to see DMARC - and any other necessary protocols - become
the subject of a working group for two years. I hope we can find a way
to make that happen.

--S.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 30 May 2014 20:10:25 -0700

> the subject of a working group for two years. I hope we can find a way

Dear Steven,

I agree with this view.  I am confident a fairly effective protocol can allow a DMARC domain to communicate whether another domain forwards their messages. This could be seen as a type of federation similar to how single-sign-on works.  Once such abilities have been instantiated between the domain asserting DMARC and the domain enforcing DMARC, nothing else really needs to change. There would be less concern about the negative impact DMARC could have on other email uses.

Since this communication would serve a very small faction of overall email traffic from a DNS perspective, DNS should be fine. Results could be cached for 300 seconds or more to improve scaling and at the same time reduce latency.  Even then, DMARC feedback would be a minor fraction of email related DNS traffic.   

Not offering feedback would be analogous to a parent denying the existence of their own children then having them fend for themselves.  This attitude burdens receivers lacking knowledge about which exceptions are valid.

No other domain should offer these answers.  With that said, DNAME would also allow several DMARC domains to select a common feedback zone.  It seems this would be close to what John Levine described, except each DMARC domain would be their own trust anchor for all their related email traffic.

Regards,
Douglas Otis

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 31 May 2014 23:37:58 +0900

Elizabeth Zwicky writes:

 > So changes that maintain effective protection for users who are
 > being targeted by attackers with addressbook information, with less
 > disruption to email that people want, are of great interest to us.

How about trying "p=quarantine" with a real short TTL just in case?
After a while you crank it back up to the current level (which is only
1800 in any case).

The argument is that, seriously, since the attackers have addressbook
information, you're done for anyway.  They're already hard at work on
Plan B, using "I'm writing this from my friend's account" with self in
Sender: (should work well on Outlook users despite having on-behalf-of
point the wrong direction), and ...  Heck, I've already thought of a
dozen of these dodges and my name isn't even Laurence Canter.

I think it's worth a check to see if the miscreants will bother to
come back at you with the previous style of spam shot even though they
should expect that the vast majority of their spam will get rejected
anyway (messages apparently from a "p=quarantine" domain should be
given a rough time as encouraged by the DMARC protocol), and the rest
will end up in spam folders.  I would think trying to avoid DMARC
entirely would now be the best use of their resources, so maintaining
quarantine should be enough.  There may be some directly relevant
recent evidence on this, since GMail is evidently promoting mailing
list traffic from "p=reject" domains to "quarantine".  If the spammers
know this, they could continue targeting GMail customers in their
stolen addressbook database.  Dunno if GMail will tell Yahoo!, but you
could ask.

BTW I hope you guys are basing "p=reject" (vs. "p=quarantine") on real
data on how often fraudulent mail that ends up in spam folders
actually succeeds in harming the targeted victim.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 31 May 2014 12:34:54 -0400

On Friday, May 30, 2014 18:46:45 Steven M Jones wrote:
> > Great.  Then instead of submitting DMARC as is via a non-IETF process,
> > let's have a working group chartered to do that work.
> 

No.  It's not.  That's why it's independent.  There's no IETF consensus for 
Independent Submissions, only a very (by design) limited role for the IESG to 
do conflict reviews.

This may seem like nit picking, but for doing work @ietf.org, it's a quite 
important one, IMO.

Scott K

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 01 Jun 2014 02:51:26 +0900

Tony Hansen writes:

 >> That doesn't help the DMARC situation now, but DMARC could be
 >> given other options once that happens.
 > 

A change to the protocol?  What?  I don't see it.  The protocol
actually in use by many domains seems to actually do what it's
designed for quite well.  "p=reject" makes a lot of sense for banks,
for example.  I don't think it can be removed from the spec, and its
proper use doesn't cause widespread problems for mailing lists.

It's use outside the design space that causes problems.  Those uses
are by desperate organizations, and they'll ignore any change that
attempts to prohibit them because they are desperate.

 > I've heard it said that the majority of the mailing lists out there
 > are managed by only a handful of ML management systems. I maintain
 > that these ML packages are in the same boat as openssl. It sure
 > would be nice if we could get some of that consortium money thrown
 > at that handful of ML management systems.

I'm sorry, but that's nonsense for the volunteer-maintained MLMs like
GNU Mailman.  We already have implemented multiple mitigations, and it
doesn't take much code.  We just hate them all and leave it up to
mailing list operators to choose the one they dislike least.  If other
MLMs haven't done so already, I doubt it involves all that much effort
for them.

 > That's a political solution for this current technical problem.

Mailing lists don't have a *technical* problem.  If DMARC were used as
designed, we'd never have noticed.  The problem is political: we have
a wounded 800-lb gorilla on the loose (not to forget a wounded 500-lb
gorilla joining the fun).

 > However, before it can happen: we NEED clear specs as to what
 > should be done by ML systems, at least in the face of DKIM and SPF
 > (and DMARC)

SPF and DKIM are now ancient history, at least as far as Mailman
development goes.  We've already done what's technically possible.
We'll see what more our users want us to do about DMARC, if anything.
There just isn't anything technical to be done AFAICS.

I can't speak for other MLMs, but I think that if there's going to be
real progress, the answer is with the MUAs.

1. If identity alignment fails, *all* links, scripts, and forms in the
   message should be deactivated, even if it's already in the spam
   folder.

2. If there's a type=password field in the message, *all* links and
   forms in the message should be deactivated, even if it's already in
   the spam folder.

3. Ditto misaligned MIME type and file name.

4. Ditto active or unknown attachments.

5. On activation of the message, all href and src URIs should be
   displayed clearly, along with an intrusive warning that ID theft is
   very common, so the user should check everything carefully
   (preferably call the author on the phone) before doing anything
   suggested by the message, even if it's already in the spam folder.

I'm sure there are other things they could do, but those are off the
top of my head.

Finally, Tim Draegen is right, it's not just about mailing lists.
Let's not forget all the other use cases that are stomped on by the
inappropriate use of "p=reject".

Steve

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 01 Jun 2014 00:49:28 +0900

> https://community.intuit.com/questions/899989-please-make-quickbooks-pass-the-dmarc-evaluation-please-do-this-quickly

Grr.  Doesn't describe the problem!  Is it that a QuickBooks client
using a mailbox at a "p=reject" domain is having QuickBooks send
invoices on their behalf?

If that's it, I have a great deal for them.  Register a domain and get
their company name, instead of Yahoo!'s, in From:.

Or (cheaper), Quickbooks just checks for "p=<not none>", and if so
overrides any company-specific config, and puts QuickBooks in From:
(with a working "p=reject" policy, even!), "Your <month> invoice from
<company>" in subject, and the company address in Reply-To.

Even supposing the company doesn't like either of those options, it's
not clear to me that the "p=reject" domain is going to necessarily be
happy trusting QuickBooks, even once TPA-Labels gets implemented.

 > I know of many small operations with similar services and
 > previously working strategies.

Much less so the effort required to vette a million small operations
(who could actually be the Yahoo! customer requesting a TPA-label for
a vendor they use -- how does TPA-label deal with collusion between
authors and relays?)

So, yeah, I sympathize with the Mom & Pop shops whose kids go hungry
this month because the bills didn't go out, and with the small
operations tearing their hair out because they've got a thousand
paying customers at Yahoo! whose content isn't arriving at
destination, but I really don't see TPA-Labels as a solution to this
problem yet.

 > Rather than having a channel only between receiver-to-sender, there
 > should also be a channel between sender-to-receiver.

We already have such a channel (the _dmarc subdomain).  What is this
new channel for?

---

From: Douglas Otis <[email-masked]>
Date: Sat, 31 May 2014 14:43:22 -0700

> happy trusting QuickBooks, even once TPA-Labels gets implemented.

Placing the original From and Subject in the message body would be cleaner, but people will wonder what to believe with few tools to help them sort through the confusion. 

After having large numbers change providers, spoofing their prior recipients from anywhere can now accompany very believable reasons, such as "DMARC caused me to change to this provider...".

Once TPA-Label is implemented by both sender and receivers applying requested DMARC policy, nothing in between would need to change.  No one would be confused, and malefactors can be reliably blocked.

> a vendor they use -- how does TPA-label deal with collusion between

The number of Sender use cases would likely be in the thousands.  There would be no free lunch which is why our company has a large and trained abuse staff.  :^)  Cases reported by DMARC feedback should be reviewed in the same manner as any possible abuse would.  In this case, the source domain will have been validated.  If there is any evidence of abuse, they don't get authorized. I should have added scopes to indicate a decision has been made to squelch further processing.  'x' for See Abuse Desk.  After that, blocked domains would need to contact the abuse desk.  I'll add that feature. 

> destination, but I really don't see TPA-Labels as a solution to this

In the case of Intuit, likely one TPA-Label would have solved the problem once DMARC evaluation confirms with the _smtp._tpa zone.  With TPA-Label, kids won't go to sleep hungry.  :^)

> We already have such a channel (the _dmarc subdomain).  What is this

A single TXT record is hardly a reverse channel since it is unable to communicate the necessary range of exceptions DMARC really needs.  In the case of PayPal and others, most initially made the mistake of posting to various mailing lists. They should have responded to these early signs a better scheme was needed to encompass actual use even when devised for only transactional email.  That was not always the case then, and it clearly is not the case now.  The TPA-Label, unlike SPF does not chain together a sequence of TXT resource records.  All information is contained in a single small resource record at a single unique label which would represent a negligible overhead in comparison.  Use of http would be much slower by adding a connection setup delay without any caching.

We need to find an expedient and quick to implement solution where most of the burden is handled by the sender requesting the DMARC policy. That is only fair.

Regards,
Douglas Otis

---

From: Tony Hansen <[email-masked]>
Date: Sat, 31 May 2014 20:42:21 -0400

Thanks for your comments Stephen.

> attempts to prohibit them because they are desperate.

See further below.

> GNU Mailman.

That's okay -- it was just a thought. However, note that not all MLMs 
are in as good a shape as GNU Mailman is, volunteer-wise. For *them*, it 
might be useful.

> We already have implemented multiple mitigations, and it

I would love to see that list of multiple mitigations shared with the 
broader community. That would be useful information for people in the 
IETF, as well as other MLM teams not involved wherever those discussions 
occurred.

Perhaps there is one or more of those solutions that we SHOULD be 
recommending. Perhaps a broader discussion might come up with some 
additional better solutions.

And perhaps broader discussions will provide an AHA moment where we see 
a way to solve BOTH MLM's problems AND DMARC's problems with MLMs in the 
face of a p=reject policies.

Are the current p=reject semantics totally correct? As has been pointed 
out by others, even with mail sent out from banks, there are legitimate 
uses of mailing lists or things like mailing lists where you want copies 
to be received by multiple people.

There might be an alternative to p=reject that we can come up with that

     *) WOULD work with mailing lists
     *) if mailing lists also were to take certain steps, and
     *) these organizations might be willing to switch to.

Or alternatively, perhaps p=reject needs to be redefined slightly to 
take advantage of specific recommended practices for mailing lists.

> development goes.  We've already done what's technically possible.

Since I'm not privy yet to what all GNU Mailman has chosen to do in the 
face of SPF and DKIM, so I don't know how to evaluate that statement. Sorry.

If you're saying that you've thrown out all use of DKIM, I consider that 
a sorry state of affairs.

> inappropriate use of "p=reject".

I agree with all of the MUA comments.

     Tony Hansen

---

From: "John Levine" <[email-masked]>
Date: 1 Jun 2014 04:26:01 -0000

>are in as good a shape as GNU Mailman is, volunteer-wise. For *them*, it 

I wouldn't count on it.  I did .invalid patches for majordomo2, which
is largely abandonware but still used a fair number of places.  People
were surprisingly uninterested, one site said they had few enough AOL
and Yahoo users that they just kicked them all off.

---

From: "John Levine" <[email-masked]>
Date: 1 Jun 2014 04:34:00 -0000

>IETF, as well as other MLM teams not involved wherever those discussions 

Your wish is our command:

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

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

I'm sure I've missed some.  Tell me what to add, or ask me for a
password and you can edit it yourself.  If you already have a password
for the ASRG wiki, it should still work.

R's,
John