Subject: Re: gmail users read on... [bozo subtopic]

From: Hector Santos <[email-masked]>
Date: Fri, 5 Sep 2014 11:39:19 -0400

One solution to all this is for the IETF to offer their own [email-masked] "registration" account to participants.  

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

> On Aug 29, 2014, at 4:10 PM, Brian E Carpenter <[email-masked]> wrote:
> 
>> On 30/08/2014 03:00, Mary Barnes wrote:
>> On Fri, Aug 29, 2014 at 9:48 AM, Ross Finlayson <[email-masked]>
>> wrote:
>> 
>>>> Gmail, like Yahoo and Hotmail and AOL, is sporadically useful for casual
>>>> purposes where mail transmission and receipt isn't terribly important.
>>>> But it's much too poorly operated to be acceptable for professional use.
>>> Plus the fact that "@yahoo.com" and "@gmail.com" (etc.) serve as good
>>> first-level 'Bozo Filters'.  DMARC serves as yet another reminder that
>>> serious professionals should not be using such email addresses.
>> [MB] I guess I am a terribly unserious professional. You might consider
>> that some of us switched to gmail because corporate filters are often
>> TERRIBLE about periodically blocking email from IETF mailing lists. And,
>> trying to convince some of those 'Bozos' not to do so is a exercise in
>> futility.  If you're lucky, they'll provide you with a daily list of some
>> of the messages they've quarantined and you can then go and retrieve those.
>>  So, I've had a much better experience since I switched from using
>> corporate email for professional use to gmail for 'unserious' professional
>> use.
>> [/MB]
> 
> Exactly. Since I switched to gmail for IETF traffic, I have changed
> employers, retired, un-retired and moved countries three times, with
> a stable email environment and no need to fight any corporate or ISP
> policies. The threat of DMARC hassle is the first real problem I've had.
> 
>   Brian
> 
>

---

From: Antonio Prado <[email-masked]>
Date: Fri, 05 Sep 2014 17:47:42 +0200

> One solution to all this is for the IETF to offer their own [email-masked] "registration" account to participants.

that's not a solution, it's a bug :)
--
antonio

---

From: Joe Abley <[email-masked]>
Date: Fri, 5 Sep 2014 14:37:36 -0400

> One solution to all this is for the IETF to offer their own [email-masked] "registration" account to participants.  

I use gmail. I don't send e-mail from an address ending in a google-managed domain, though. I am in control of what policy I publish in the DNS for my own domains.

The distinction is important.

Joe

---

From: Doug Barton <[email-masked]>
Date: Wed, 10 Sep 2014 09:04:09 -0700

On 8/29/14 2:48 PM, Andrew G. Malis wrote:
>  From what I've read elsewhere, Mailman 2.1.18 mitigates the DMARC
> problem. The IETF is currently using 2.1.15, so once the powers-that-be
> upgrade us to 2.1.18, the problem may be solved.

Is there an update on this? Aside from the operational importance of 
having the IETF mailing lists working well for all users, knowledge of 
how well the latest mailman fixes work will be very helpful for this 
community to have.

... and FWIW, I enabled a "report only" DMARC record for my personal 
domains, including the one for the addresses that I regularly use to 
post to mailing lists. I have seen a lot of reports coming back, not 
just from the big players, but also from a lot of others. So this issue 
is only growing in importance.

Doug

---

From: "John Levine" <[email-masked]>
Date: 11 Sep 2014 01:25:24 -0000

>how well the latest mailman fixes work will be very helpful for this 

There's a bunch of different workarounds in the latest version of
Mailman.

The one that's most widely used rewrites the From: line to put the
list's address in place of the author's.  It "works" in the sense that
it avoids DMARC rejections, but at the cost of screwing up the mailing
lists so you can't tell who wrote what from the usual MUA display, and
in many cases, you can't tell who wrote a message at all unless you
put the author's address as the Reply-To, which has its own well known
set of problems.

I've collected all of the DMARC workarounds I know on the ASRG wiki:

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

On my lists, I rewrite the domain in the From: line to create
forwarding addresses for the real authors.  It's a crock, but one I
find preserves the mailing list functionality better.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Sep 2014 12:54:31 -0400

--On Thursday, September 11, 2014 01:25 +0000 John Levine
<[email-masked]> wrote:

>...
> The one that's most widely used rewrites the From: line to put
> the list's address in place of the author's.  It "works" in
> the sense that it avoids DMARC rejections, but at the cost of
> screwing up the mailing lists so you can't tell who wrote what
> from the usual MUA display, and in many cases, you can't tell
> who wrote a message at all unless you put the author's address
> as the Reply-To, which has its own well known set of problems.

FWIW (and with the understanding that you don't need
convincing), I find that approach really objectionable.   In
addition to the pragmatic reasons you cite (and some others such
as the ability to prioritize mail based on origin), we've been
careful, almost since the dawn of network mail, to associate
what now appears as "From:" with the actual originator of the
message.  We've invented "Sender" and "Resent-" header fields to
preserve that distinction and make it clear.  For a mail
exploder to violate that principle, especially to make an
ill-designed protocol work better, seems problematic to me.
For the IETF, it is bad news when we cannot or will not adopt.
use, and conform to one of our own established standards-track
protocols.  But, if we have a system that does conform and we
switch it to not conform in order to accommodate an unfortunate
practice or design, that would be far worse, putting us in must
the same position we put ITU in when we pointed out that they
considered X.400 so stable, useful, and well-implemented that
they were using SMTP.

    john

---

From: Doug Barton <[email-masked]>
Date: Thu, 11 Sep 2014 10:30:31 -0700

> considered X.400 so stable, useful, and well-implemented that

John Klensin,

If you don't like that solution, what solution do you propose to deal 
with the large (by volume) installed base of DMARC domains relative to 
mailing list traffic? It's fine and good to talk about theory, more 
power to ya. :)  But as Brian pointed out the volume of list traffic 
that is being shunted to spam folders, or outright rejected, is only 
increasing. Continuing to complain about DMARC, or the way it's being 
used, is wasted electrons.

I proposed creating a draft for a standardized way of encoding the 
original from address to the left of the @ sign so that the mailing list 
sender could create a valid DKIM record, but clients could be taught to 
decode the original From:.  You and others pooh-pooh'ed that suggestion, 
but I haven't seen a better one yet.

John Levine,

Perhaps you could share what you're doing with the secretariat? I agree 
with John Klensin that it would be awesome for the IETF to become 
thought leaders in creating a solution for mailing lists in the p=reject 
era.

In any case, clearly "do nothing" is not the right answer here.

Doug

---

From: "John Levine" <[email-masked]>
Date: 11 Sep 2014 20:20:58 -0000

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Thu, 11 Sep 2014 16:33:23 -0400

--On Thursday, September 11, 2014 10:30 -0700 Doug Barton
<[email-masked]> wrote:

> John Klensin,
> 
> If you don't like that solution, what solution do you propose
> to deal with the large (by volume) installed base of DMARC
> domains relative to mailing list traffic? It's fine and good
> to talk about theory, more power to ya. :)  But as Brian
> pointed out the volume of list traffic that is being shunted
> to spam folders, or outright rejected, is only increasing.
> Continuing to complain about DMARC, or the way it's being
> I proposed creating a draft for a standardized way of encoding
> the original from address to the left of the @ sign so that
> the mailing list sender could create a valid DKIM record, but
> clients could be taught to decode the original From:.  You and
> others pooh-pooh'ed that suggestion, but I haven't seen a
> better one yet.

I don't recall "pooh-pooh"-ing anything, but as many people here
are aware, I've got a deep aversion, based on extensive
experience, to tampering with headers in transit.  From that
point of view, a fancy encoding of the local part is not
significantly different from the "rewrite to point to the mail
exploder" technique John Levine mentioned.

As to a solution, I believe that a key reason the Internet has
gotten this far -- both technically and in terms of convincing
regulators and the like to let us rely on "multistakeholder"
solutions rather than extensive formal regulation -- depends on
organizations with market power (by volume) exercising good
judgment and moderation when it is discovered that their actions
hurt others or force others to incur significant expense.  I
sincerely hope that the newly-created WG will move expeditiously
to modify DMARC so that it stops causing these problems and that
the major (by volume) organizations who have deployed DMARC will
then rapidly make adopt those changes.   From that perspective,
"we deployed this neat thing, if it hurts you and your perfectly
standards-conforming application, suck it up" just doesn't work
for me regardless of what the parties with those other
applications might apply as remedies.  

I hope I'm not getting too hysterical about this but, if DMARC
"works" in the sense that the organizations who created it can
effectively force everyone else to adapt or find themselves at a
severe disadvantage, what is to prevent the same actors from
collaborating on new core email protocols (replacing SMTP and
the header specs).   We probably all agree that those specs are
showing their age and that we would do things differently if we
started over today and didn't need to worry about the installed
base.  We probably don't agree on what changes should be made
and the IETF has traditionally been quite careful about that
installed base.  But suppose some consortium of large actors
came along and said "we have designed a new set of mail
protocols that will provide our users a better experience" (or,
to be cynical, provide us with better advertising opportunities)
"and good luck to you in designing gateways".  Would we accept
that in the same way that you and others seem to be urging ways
to accommodate to DMARC?  I fear for the notion of an open
Internet if the answer is "yes", but probably see less
difference between that case and the DMARC one than you and
others may.

Maybe things just look better from my applications perspective
looking down the stack, but my impression is that most of the
major corporate actors in, e.g., routing, the network layer, and
operations are still behaving more or less consistently with
that historical cooperative model.  But some of the active
forces in the applications layer, seemingly especially where
email is concerned, seem to have lost sight of it or concluded
that is is not in their interest to do so.  I find that pretty
troubling.  

Now, perhaps my view is outdated and naive and our present
reality is that any convenient 300 pound gorilla (or a
consortium of them) can (and will) do whatever they like and
expect others to conform.  If that is so, I question the
long-term future of the IETF and voluntary,
individual-participation, standardization efforts, both because
market power becomes a more economical and effective substitute
for open standards and because this is exactly the sort of thing
that causes other actors to decide that external adult
supervision is needed (with them picking the "adults").

  best,
    john

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Sep 2014 15:35:37 -0500

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

Perhaps mailman should offer subscribers some of these (and other?)
options.  Let the subscriber pick their poison.  I realize it's more
work for the list manager, but not that much more work, and easily
automated work anyways.

With my MUAs the lack of WG name in the subject is not fatal.  Though
nonetheless I appreciate that being there.

The footer should just not be added.  It doesn't help anyone, full
stop.  Instead the list should make a simple attempt to detect
"unsubscribe me" messages (and spank the user).

Finally, a subscriber with no delivery option (using the archives
and/or the hopefully-soon-to-arrive IETF IMAP service) would be nice.

Nico
--

---

From: Doug Barton <[email-masked]>
Date: Thu, 11 Sep 2014 13:41:26 -0700

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

Two responses to that, in no particular order of importance:

1. So you said, and yet the mere existence of that page out on the 
intertubez has (oddly enough) not yet spurred the secretariat into action.

2. In a previous message you also indicated that you had some sort of 
forwarding solution that you're using which has been successful for you. 
IME approaching someone with a statement to the effect of, "Here is a 
solution which I have used successfully and would be willing to help you 
implement" generally has a much better response rate than "Here is a URL 
with a list of possible solutions." YMMV of course.

At the end of the day the question remains, do we want to solve this 
problem, or do we want to continue complaining about it?

Doug

---

From: Christian Huitema <[email-masked]>
Date: Fri, 12 Sep 2014 05:34:06 +0000

> intertubez has (oddly enough) not yet spurred the secretariat into action.

The big change with DMARC is a deprecation of the Sender/From differentiation, effectively requiring that these two will be the same. It seems that big systems have voted that the differentiation causes more harm (spam, phish) than good (remailers). 

Of the responses listed, the one that clearly works is to ask forwarders to forward messages, what the wiki calls "message wrapping." It works in the sense that the mail system sees consistent headers that pass all verifications, and represent the actual action of the remailer while not relying on Sender/From differences.

At that point, the issue is mostly with the UI. If my reader did recognize the "simple forwarding" case from "authorized remailers," then the message wrapping solution would be just fine. The good thing is that it is very much under my control.

-- Christian Huitema

---

From: George Michaelson <[email-masked]>
Date: Fri, 12 Sep 2014 16:09:01 +1000

Like many others here, I act as de-facto sysadmin to my partner. She wished
to have a "nice" mail via @pobox.com forwarded to here gmail account, *and*
to keep her actual gmail ID less visible.

For a limited time, this seemed to work. perhaps 6months. But inevitably,
the real underlying gmail address "leaks"

And, with the variance of policies, it is now unclear if the 'faked' @
pobox.com or @gmail.com "actual" address is the one seen. This is also a
function of Sender/From differentiation, and Envelope/Header
differentiation.

I feel sad I can't guarantee to her a specific behaviour. This feels wrong.
It feels like we've taken something out of the 822 Ecology by allowing
Sender, From, Envelope to get mashed together.

-George

On Fri, Sep 12, 2014 at 3:34 PM, Christian Huitema <[email-masked]>
wrote:

> The big change with DMARC is a deprecation of the Sender/From
> differentiation, effectively requiring that these two will be the same. It
> seems that big systems have voted that the differentiation causes more harm
> (spam, phish) than good (remailers).
>
> Of the responses listed, the one that clearly works is to ask forwarders
> to forward messages, what the wiki calls "message wrapping." It works in
> the sense that the mail system sees consistent headers that pass all
> verifications, and represent the actual action of the remailer while not
> relying on Sender/From differences.
>
> At that point, the issue is mostly with the UI. If my reader did recognize
> the "simple forwarding" case from "authorized remailers," then the message
> wrapping solution would be just fine. The good thing is that it is very
> much under my control.
>
> -- Christian Huitema
>
>
>

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 12 Sep 2014 07:21:40 -0400

George Michaelson wrote:
> Like many others here, I act as de-facto sysadmin to my partner. She 
> wished to have a "nice" mail via @pobox.com <http://pobox.com> 
> forwarded to here gmail account, *and* to keep her actual gmail ID 
> less visible.
>
> For a limited time, this seemed to work. perhaps 6months. But 
> inevitably, the real underlying gmail address "leaks"
>
> And, with the variance of policies, it is now unclear if the 'faked' 
> @pobox.com <http://pobox.com> or @gmail.com <http://gmail.com> 
> "actual" address is the one seen. This is also a function of 
> Sender/From differentiation, and Envelope/Header differentiation.
>
> I feel sad I can't guarantee to her a specific behaviour. This feels 
> wrong. It feels like we've taken something out of the 822 Ecology by 
> allowing Sender, From, Envelope to get mashed together.

Maybe it feels wrong because we HAVE taken something useful and 
important out of the 822 ecology by allowing Sender, From, Envelope to 
get mashed together.

Miles Fidelman

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

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Sep 2014 05:18:37 -0700

On 9/11/2014 10:34 PM, Christian Huitema wrote:
> Of the responses listed, the one that clearly works is to ask
> forwarders to forward messages, what the wiki calls "message
> wrapping." It works in the sense that the mail system sees consistent
> headers that pass all verifications, and represent the actual action
> of the remailer while not relying on Sender/From differences.

According to the criteria you list, sure.  According to what a recipient
sees, it works badly.  In terms of human communication, author
information is buried.

> At that point, the issue is mostly with the UI. If my reader did
> recognize the "simple forwarding" case from "authorized remailers,"
> then the message wrapping solution would be just fine. The good thing
> is that it is very much under my control.

This suggests defining a wrapping convention that is sufficiently
distinction so that receiving software can know it is this specific type
of wrapping and can choose to unwrap the message, without doing
unwrapping for other kinds of encapsulated mail.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Theodore Ts'o <[email-masked]>
Date: Fri, 12 Sep 2014 09:27:42 -0400

On Fri, Sep 12, 2014 at 05:34:06AM +0000, Christian Huitema wrote:
> differentiation, effectively requiring that these two will be the
> same. It seems that big systems have voted that the differentiation
> causes more harm (spam, phish) than good (remailers).
> 
> wrapping." It works in the sense that the mail system sees
> consistent headers that pass all verifications, and represent the
> actual action of the remailer while not relying on Sender/From
> differences.
> 
> then the message wrapping solution would be just fine. The good
> thing is that it is very much under my control.

But unfortunately, once the UI recognizes this case, would we not be
imposing harm vis-a-vis phishing in particular?  And then DMARC Mark
II (as it were) would have to prohibit the wrapping and require a wrap
of a wrap, etc.

There's no way of winning this.  But if we are going to go down this
path, it would be useful to discuss what the UI would look at that
meets the needs of mailing lists, but without potential harm of
phishing.

							 -Ted

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 12 Sep 2014 09:55:25 -0400

> unwrapping for other kinds of encapsulated mail.

content type message/re-mailed or something?

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 12 Sep 2014 14:16:30 +0000

> meets the needs of mailing lists, but without potential harm of

Right, there's no way to win against phishing with narrow technical
counter-measures.  Phishing is not an attack on vulnerable computer
systems that follow rigid rules, it is an attack on vulnerable
fuzzy human reasoning about the online world.  Narrow defenses like
DMARC don't deter the phishers, but do damage the email infrastructure.
Sometimes more harm is done by over-eager defenders, than by the
attackers.

The main effect of DMARC has been that 419 scammers now put the
Gmail, Yahoo, ... email address in "Reply-To:", rather than "From:".
Phishers also find other alternatives:

  Return-Path: <[email-masked]>
  Received: from web116.brainhost.com (web116.brainhost.com [64.31.11.114])
	  (using unknown with cipher DHE-RSA-AES256-SHA (256/256 bits))
	  (No client certificate requested)
	  by amnesiac (Postfix) with ESMTPS id 278102AB02B
	  for <[email-masked]>; Thu, 11 Sep 2014 13:16:11 +0000 (UTC)
  To: [email-masked]
  Subject: Update You account PayPal
  From: trami zlal <[email-masked]>

This phisher did not even bother to use a plausible Display Name.
The pitch in the message payload is by far the most important
element of the attack, the machine-readable "metadata" we protect
is not nearly as significant.

-- 
	Viktor.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 12 Sep 2014 15:35:19 +0000

> -----Original Message-----
> From: ietf [mailto:[email-masked]] On Behalf Of Christian Huitema
> Sent: Friday, September 12, 2014 1:34 AM
> To: Doug Barton; [email-masked]
> Subject: RE: dmarc damage, was gmail users read on... [bozo subtopic]
> 
> seems that big systems have voted that the differentiation causes more
> harm (spam, phish) than good (remailers).
> 

This is actually not quite true. If the Sender and the From are in the same domain then there is no problem. It becomes an issue when the Sender and the From are different domains. DMARC does not care about the LHS of the email address (whether it is DKIM signing or SPF validation).

> Of the responses listed, the one that clearly works is to ask forwarders to
> forward messages, what the wiki calls "message wrapping." It works in the
> sense that the mail system sees consistent headers that pass all verifications,
> and represent the actual action of the remailer while not relying on
> Sender/From differences.
> 
> At that point, the issue is mostly with the UI. If my reader did recognize the
> "simple forwarding" case from "authorized remailers," then the message
> wrapping solution would be just fine. The good thing is that it is very much
> under my control.
> 
> -- Christian Huitema
> 

Mike

---

From: Wei Chuang <[email-masked]>
Date: Fri, 12 Sep 2014 10:20:07 -0700

On Fri, Sep 12, 2014 at 8:35 AM, MH Michael Hammer (5304) <[email-masked]>
wrote:

> This is actually not quite true. If the Sender and the From are in the
> same domain then there is no problem. It becomes an issue when the Sender
> and the From are different domains. DMARC does not care about the LHS of
> the email address (whether it is DKIM signing or SPF validation).
>

Agreed, but just wanted to add one thing- doesn't the details of the
whether the sender has to align or not depends on whether SPF or DKIM is
used as the authentication method?  (SPF w/DMARC will force the envelope
sender to agree with from.)  Also I wanted to add to mix that there must be
something by which to lookup the "sender's" DMARC policy, and the DMARC
authors choose for various reasons the FROM domain by which the
authentication methods will enforce "alignment" upon.

> to
> recognize the
> much
> > under my control

I also just wanted to bring another high level idea to the table- rather
than discuss which work arounds to mandate (and all have problems), why not
revisit the authentication methods?  In particular the current DKIM method,
while very powerful in the security sense, is very restrictive.  Any
changes to the signed message parts will cause the authentication to fail.
  For example if a mailing lists modifies the subject or body even if done
so in some sanctioned way, it will fail DKIM.  (And then since the message
is resent, fail SPF)  At the broader IETF community level, perhaps it might
be good to see about improving those RFC's?

For example there are some ideas about improving DKIM out there.  I've made
a general but heavy-handed conceptual proposal early on in the DMARC WG,
and I know there is another one by Murry Kucherawy (list-cannon) that IMO
is a very good direction.  I think there's an opportunity of taking these
approaches and simplifying them to make them palatable to the mailing-list
operators.

-Wei

---

From: Doug Barton <[email-masked]>
Date: Fri, 12 Sep 2014 10:27:05 -0700

On 9/12/14 10:20 AM, Wei Chuang wrote:
> than discuss which work arounds to mandate (and all have problems), why
> not revisit the authentication methods?  In particular the current DKIM
> method, while very powerful in the security sense, is very restrictive.

Because the large mail vendors have already spoken, and they like the 
way that SPF/DKIM/DMARC work. Spending more time talking about how we 
think they SHOULD work is wasted effort.

Doug

PS, I don't like this any more than some of y'all do, but I think it's 
rather important that we recognize the reality of the situation.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Sep 2014 10:27:04 -0700

...
> This is actually not quite true. If the Sender and the From are in the same domain then there is no problem. It becomes an issue when the Sender and the From are different domains. DMARC does not c…

In semantic terms, Christian's analysis is exactly correct.

The fact that there might be some scenarios where things are not
operationally problematic is a distraction, rather than meaningful to
the analysis.

By definition, p=reject enforces a semantic that requires the owner of
the rfc5322.From domain to have a relatively tight relationship with the
operator sending the message.

IMO, it's quite reasonable to characterize this as conflating From: and
Sender:.

What tends to be missed, throughout all of the discussions about dealing
with the effect on intermediaries such as mailing lists, is that most or
all of the mechanisms being discussed for intermediaries will work
equally well for bad actors...

d/

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 12 Sep 2014 17:46:19 +0000

From: Wei Chuang [mailto:[email-masked]]
Sent: Friday, September 12, 2014 1:20 PM
To: MH Michael Hammer (5304)
Cc: Christian Huitema; Doug Barton; [email-masked]
Subject: Re: dmarc damage, was gmail users read on... [bozo subtopic]

On Fri, Sep 12, 2014 at 8:35 AM, MH Michael Hammer (5304) <[email-masked]<mailto:[email-masked]>> wrote:

> From: ietf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Christian Huitema
> To: Doug Barton; [email-masked]<mailto:[email-masked]>

Agreed, but just wanted to add one thing- doesn't the details of the whether the sender has to align or not depends on whether SPF or DKIM is used as the authentication method?  (SPF w/DMARC will force the envelope sender to agree with from.)  Also I wanted to add to mix that there must be something by which to lookup the "sender's" DMARC policy, and the DMARC authors choose for various reasons the FROM domain by which the authentication methods will enforce "alignment" upon.

MH: Because (DMARC) alignment is required in either case it really isn't an issue whether SPF or DKIM is used for DMARC validation. Looking up the "sender's" policy is what PRA attempted in SenderID. I and others showed that it was rather trivial to game PRA to at least get a neutral status for a message. There is no reasonable way to establish that the Sender is truly representing the From, and that problematic when one is talking security/authorization models. There have been some discussions about how to implement an "authorization" for Sender but I haven't seen anything that makes sense to me.

The FROM domain was chosen for DMARC because it is what is generally used in the MUA (visible to the user). One could just as easily have argued for MailFrom as long as alignment between the two is required. Six of one half a dozen of the other.

> wrapping solution would be just fine. The good thing is that it is very much

I also just wanted to bring another high level idea to the table- rather than discuss which work arounds to mandate (and all have problems), why not revisit the authentication methods?  In particular the current DKIM method, while very powerful in the security sense, is very restrictive.  Any changes to the signed message parts will cause the authentication to fail.   For example if a mailing lists modifies the subject or body even if done so in some sanctioned way, it will fail DKIM.  (And then since the message is resent, fail SPF)  At the broader IETF community level, perhaps it might be good to see about improving those RFC's?

MH: There is always the potential to consider other authentication methods and this has been discussed. Initially it is a complexity issue and real world experience showed that for most use cases (I'm waiting for someone to jump in and wag their finger at me about MLMs) the combination of aligned SPF and DKIM validation is extremely effective (although somewhat restrictive). I'm personally not against someone(s) doing some testing for other authentication methods to see what the outcomes would be - all you need is at least a participating sender and receiver. I know that there has been some discussion of DKIM signing individual MIME parts in addition to an overall signature so that one could see which parts were modified. This coupled with a signature by the list/forwarder might be an interesting approach. On the other hand it might represent too much complexity. Some folks advocate reputation of the forwarder as the solution. I'm not a big fan of reputation (For me it falls into the category of "What have you done to me lately" rather than "you've been a good actor for the last 5 years" - would you accept crap from a good domain gone bad just because they used to be good?)

For example there are some ideas about improving DKIM out there.  I've made a general but heavy-handed conceptual proposal early on in the DMARC WG, and I know there is another one by Murry Kucherawy (list-cannon) that IMO is a very good direction.  I think there's an opportunity of taking these approaches and simplifying them to make them palatable to the mailing-list operators.

MH: I'm agnostic on this. Some advocate changes to accommodate mailing-list operators - that's fine with me as long as there is still a decent security model. Others argue that mailing-list operators must change. That may or may not be true. The mail streams I'm responsible for are typically transactional and do not go through lists so while  have an opinion I've been hanging back from that "discussion". I'm gratified that there appears to be more serious discussion in this space though.

-Wei

Mike

---

From: Doug Barton <[email-masked]>
Date: Fri, 12 Sep 2014 11:21:02 -0700

> equally well for bad actors...

Dave,

First, I don't think that point has been missed, as it's been repeated 
so often. :)  Second, if you change the From: to be @<mailing list 
domain> the message is still protected if the mailing list domain uses 
SPF, DKIM, or better yet, both; AND the receiving system verifies them.

Or, put differently, faking Bad.Actor@<valid domain> is one of the 
scenarios that SPF/DKIM/DMARC are specifically designed to address. It's 
not clear how creating a solution which will allow mailing list traffic 
to flow will weaken that.

Doug

---

From: Nico Williams <[email-masked]>
Date: Fri, 12 Sep 2014 15:17:39 -0500

On Fri, Sep 12, 2014 at 03:35:19PM +0000, MH Michael Hammer (5304) wrote:
> same domain then there is no problem. It becomes an issue when the
> Sender and the From are different domains. DMARC does not care about
> the LHS of the email address (whether it is DKIM signing or SPF
> validation).

The cases in which only the LHS differs are rather uninteresting though;
Christian H. is quite right.  We've taken a step backwards.

Nico
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 12 Sep 2014 15:16:39 -0700

On Fri, Sep 12, 2014 at 10:27 AM, Doug Barton <[email-masked]> wrote:

> Because the large mail vendors have already spoken, and they like the way
> that SPF/DKIM/DMARC work. Spending more time talking about how we think
> they SHOULD work is wasted effort.
>

What's "the current DKIM method" and how is it restrictive?

The large mail vendors are participating in these discussions, or at least
observing them, so if we have something to say to them that's different
from "go back to the way it was before", I believe it'll get heard.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 12 Sep 2014 15:18:01 -0700

> but I haven't seen a better one yet.

Isn't that SRS?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 12 Sep 2014 15:20:14 -0700

On Fri, Sep 12, 2014 at 1:17 PM, Nico Williams <[email-masked]>
wrote:

> same. It

That's curious.  Maybe I'm not understanding, but:

DMARC doesn't check Sender, so I don't see how this is relevant.  Or do you
mean that what one would now put in Sender is required to be in From?

> Christian H. is quite right.  We've taken a step backwards.

Maybe in some ways that's true.  On the other hand, if almost nothing ever
checked Sender to begin with, and a lot of things that "should" have
generated it didn't, what practical difference does it make?

-MSK

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sat, 13 Sep 2014 08:29:24 +0100

> equally well for bad actors...

Indeed.

I wonder if it might not simply make more sense to warn users that the information in the header fields cannot be trusted once they have been remailed by an exploder of any kind.  This way, transparent MUA unwrapping of encapsulated list mail is a much more plausible solution.

Cheers,
Sabahattin

---

From: "John Levine" <[email-masked]>
Date: 13 Sep 2014 13:49:07 -0000

>Agreed, but just wanted to add one thing- doesn't the details of the whether the sender
>has to align or not depends on whether SPF or DKIM is used as the authentication method? 

No.  Neither DKIM nor SPF have any connection to either the From: or
Sender: header other than what DMARC is trying to do.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 13 Sep 2014 19:14:26 -0000

>II (as it were) would have to prohibit the wrapping and require a wrap

DMARC is only useful because many crooks are remarkably lazy or
stupid.  I've seen numbers showing that it blocks vast amounts of spam
with From: addresses like <[email-masked]> which means that a lot
of crooks just uses the exact address they're attacking But it's not
effective against stuff like this, which they also use:

  From: <[email-masked]>
  From: security at paypal.com <[email-masked]>

For that second one, remember that a lot of MUAs only show the
comment on the From: line, not the address.

While I believe that it does block considerable phish now, I also
believe it's a lot of long term pain for only short term benefits.  I
also agree that if we invent ways to circumvent DMARC issues, the bad
guys will quickly adapt unless those ways have a different, ideally
better, threat model.  See the appsawg archives and the new dmarc list
for further discussion on this point.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sat, 13 Sep 2014 16:09:00 -0400

--On Saturday, September 13, 2014 19:14 +0000 John Levine
<[email-masked]> wrote:

> stupid.  I've seen numbers showing that it blocks vast amounts
> of spam with From: addresses like <[email-masked]> which
> means that a lot of crooks just uses the exact address they're
> attacking But it's not effective against stuff like this,
> which they also use:
> 

I would have added that it provides no protection against 
    From: <[email-masked]>
(the oft-cited "Cyrillic 'a'" example) either.

I think we are largely in agreement, but I think there is a
reasonable hypothesis that would substitute "lazy and
economically rational" for "remarkably lazy or stupid".  No
matter how vast the number of messages that are intercepted, the
crooks have  no incentive to adopt smarter procedures until the
number and pattern of messages intercepted hurt the bottom line.
Up to that point, they have multiple incentives to ignore DMARC
and let it trap whatever it traps.  Doing so forces us to expend
resources to adjust to a technique they know how to (mostly)
defeat and thereby lowers, however slightly, the available
resources for dealing with the next attack.  It leaves us
guessing as to what new attacks will be mounted, forcing us to
either wait and then react or to waste resources on approaches
they are unlikely to try (or will avoid trying once we've spent
the resources and deployed the solutions.

As others have pointed out, spending our resources making the
bad guys smarter is rarely a good tradeoff.  DMARC does not seem
to be a good candidate for a long-term exception.

> comment on the From: line, not the address.

I've often wondered how many successful phishing attacks we
could stop by issuing a "best practices" statement pointing out
the risks and difficulties associated with that
address-suppression practice.   I don't know that MUA
authors/maintainers would pay any attention to us, but, if we
hypothesize that they would not, it gets much harder to believe
that plans that require MUA changes to deal with DMARC
countermeasures would be effective.

best,
    john

---

From: Wei Chuang <[email-masked]>
Date: Sun, 14 Sep 2014 00:36:02 -0700

>> they SHOULD work is wasted effort.
I doubt my personal view are going to change any opinions here, but if you
could put yourselves in the mindset of the engineers trying to fight
phishing attacks at large scale that were damaging the reputation of their
service you might see things differently.  I wouldn't say those large
vendors like SPF/DKIM/DMARC per se and I think its rather that they were
the IETF sanctioned tools that they had at that moment to mitigate what
sounds like a nasty attack.  From that perspective, having a better set of
tools that don't cause collateral damage would be pretty useful in the
future as the adversaries launching those attacks are getting more and more
sophisticated.   (Again this is just my personal opinion)

> What's "the current DKIM method" and how is it restrictive?

Current is just referring to RFC6376.  I just describe it this way to
differentiate it because I later go onto mention
draft-kucherawy-dkim-list-canon-00 and a concept I pitched early in the
DMARC WG list which are essentially proposed improvements on DKIM.

My notion of restrictive got chopped off in the above reply snippet- but it
was: "Any changes to the signed message parts will cause the authentication
to fail.   For example if a mailing lists modifies the subject or body even
if done so in some sanctioned way, it will fail DKIM.".  These above two
proposed authentication methods allow for the signature verification of the
original message despite modification by some intermediate email proxy e.g.
mailing-list.

-Wei

---

From: Wei Chuang <[email-masked]>
Date: Sun, 14 Sep 2014 00:38:48 -0700

On Sat, Sep 13, 2014 at 6:49 AM, John Levine <[email-masked]> wrote:

> whether the sender

Not terribly important but- my statement about DKIM/SPF was in the context
of DMARC.

-Wei

---

From: Hector Santos <[email-masked]>
Date: Sun, 14 Sep 2014 10:40:51 -0400

> Sender: header other than what DMARC is trying to do.

DKIM has a required hash bind to the 5322.From field data -- the only 5322 header signing requirement in DKIM.  It's burned into the now DKIM now STD level specification.  That's not a DMARC requirement, but one DMARC relies on having with DKIM.  

Maybe an errata is in order?

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 14 Sep 2014 10:56:52 -0400

On September 14, 2014 10:40:51 AM EDT, Hector Santos <[email-masked]> wrote:
>DKIM has a required hash bind to the 5322.From field data -- the only
>5322 header signing requirement in DKIM.  It's burned into the now DKIM
>now STD level specification.  That's not a DMARC requirement, but one
>DMARC relies on having with DKIM.  
>

The field is required to be signed. It's not required to have any particular value. It's most certainly not required to be related to the signing domain in any way (which is what DMARC does).

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sun, 14 Sep 2014 11:07:39 -0400

> On Sep 12, 2014, at 2:21 PM, Doug Barton <[email-masked]> wrote:
> 
> First, I don't think that point has been missed, as it's been repeated so often. :)  

+1 since SSP, since ADSP, since the threat analysis RFC, since the functional requirements  RFC.  

> Second, if you change the From: to be @<mailing list domain> the message is still protected if the mailing list domain uses SPF, DKIM, or better yet, both; AND the receiving system verifies them.

Exactly, the problem has been the push by the list folks to avoid this effort. The push by the key cogs was to look up the 3rd party trusted signer, if any and valid and ignore anything else otherwise, hence all sorts of loopholes.

> Or, put differently, faking Bad.Actor@<valid domain> is one of the scenarios that SPF/DKIM/DMARC are specifically designed to address.

Yet, the ietf effort to make DKIM a STD yet a push for methods that break it. I don't get the lack or poor integration effort. 

> It's not clear how creating a solution which will allow mailing list traffic to flow will weaken that.

Integrated systems have a better scope and feel.  All the parts have to be part of the picture.  So yes, it is a complex and expensive endeavor.  It took a long time to finally get all the mail parts lined up. But we had nine years to get ready for this framework.  We are talking mostly about policy driven mail expectations for the good, the bad and the ugly. And we have not yet come to terms that policy lookups is required by all entry points.  The list people have pushed aside the need to do author domain policy lookups, and they don't need to do it as long the list mail system frontend is doing it.

---

From: Hector Santos <[email-masked]>
Date: Sun, 14 Sep 2014 11:16:12 -0400

> On Sep 14, 2014, at 10:56 AM, Scott Kitterman <[email-masked]> wrote:
> 
> 
> 

Major disagreement and why this problem is not solved. 

There is tremendous inherent value that could only be understand by working on mail systems offline, online for 30 years.  The from field is a treasured field Scott and it's not just for network mail but local and all forms of telecommunications.  There is a reason why it's the only one required to be signed and that's strongly because it was the original proof of concept since day 0.  Domainkeys started the policy concept. DKIM improved it. 

One group tried to separate it and that failed.

---

From: Hector Santos <[email-masked]>
Date: Sun, 14 Sep 2014 11:20:36 -0400

That is author domain Policy was the original proof of concept, that is why the 5322.From anchor was required,

> On Sep 14, 2014, at 11:16 AM, Hector Santos <[email-masked]> wrote:
> 
> 
>

---

From: Dave Crocker <[email-masked]>
Date: Sun, 14 Sep 2014 12:29:15 -0700

On 9/13/2014 1:09 PM, John C Klensin wrote:
> address-suppression practice.

Like most user interface ideas, it's an entirely reasonable line of
inquiry.

However based on the experience of 'usable security' folks, there's also
quite a bit of evidence that it would make no meaningful difference.

The best model to invoke, with respect to the idea of recruiting end
users to be active participants in abuse detection or prevention is
mostly:

  Don't.

That's a reality that tends to be rejected or ignored around the IETF,
so it would be quite nice to see proposals offer an empirical basis for
expecting efficacy.

d/

---

From: David Morris <[email-masked]>
Date: Sun, 14 Sep 2014 20:41:36 -0700 (PDT)

It seems to me that the wrapped original mail could be signed by the
forwarding list processor so that the DMARC recipient would accept the
forwarded mail as coming from the forwarder and the ultimate MUA would
be able to verify that the wrapped messaged was indeed wrapped by the
forwarding list processor and transparently unwrap the original
email.

Since some list mail is re-forwarded along the path to the ultimate MUA,
this mechanism should support multiple layers of signed wrapping.

Dave Morris

On Sat, 13 Sep 2014, Sabahattin Gucukoglu wrote:

> I wonder if it might not simply make more sense to warn users that the
> information in the header fields cannot be trusted once they have been
> remailed by an exploder of any kind.  This way, transparent MUA
> unwrapping of encapsulated list mail is a much more plausible solution
>
> Cheers,
> Sabahattin
>

---

From: "John Levine" <[email-masked]>
Date: 15 Sep 2014 21:06:24 -0000

>forwarding list processor and transparently unwrap the original

Well, yes, but you don't need to wrap mail to re-sign it.  By design,
any host that relays a message can add a DKIM signature.  Well run
mailing lists sign mail now.  Look at any IETF list mail for an
example.

The problem with wrapped mail is basically a UI problem, and the IETF
has a long history of knowing less than nothing about UI (as in, much
of what we think we know is wrong.)

Anything a list can do to wrap mail, a bad guy can do, too.  Work out
a few scenarios and you'll find that wrapping isn't very attractive as
a long term solution to anything.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 15 Sep 2014 21:06:24 -0000

R's,
John

---

From: Rich Kulawiec <[email-masked]>
Date: Sat, 20 Sep 2014 06:47:06 -0400

On Sun, Sep 14, 2014 at 12:36:02AM -0700, Wei Chuang wrote:
> service you might see things differently.

Those engineers should focus first on the abuse that's coming *from*
or supported by their own operations, not on the abuse directed at them.
In the case of some of the providers involved in the DMARC debacle,
they've spent many years studiously pretending that the problem is external
when in fact much of it is internal and when they've tried their
very best to block, ignore or discard problem reports concerning it.

---rsk

---

From: Rich Kulawiec <[email-masked]>
Date: Sat, 20 Sep 2014 06:49:16 -0400

> users to be active participants in abuse detection or prevention is

Yes, a thousand times yes.  Users (as a whole) have spent the past
several decades conclusively proving beyond any possible argument that
they should not be, in ANY way, involved in this process. [1]

---rsk

[1] Unless every action they take is manually reviewed by someone with
appropriate expertise.  This of course has its own issues; notably, it
doesn't scale well and it raises substantial privacy and security issues.