Subject: [dmarc-ietf] A case to be addressed in the BCP document for DMARC

From: "J. Gomez" <[email-masked]>
Date: Wed, 3 Apr 2013 22:27:40 +0200

Hello.

I have this sample email which I got that would fail both SPF and DKIM in the realm of DMARC, although it would pass both SPF and DKIM "by-themselves". However as the RFC5322.From header is not aligned with SPF nor DKIM, it would fail DMARC.

This is legitimate marketing email from Symantec to which I am subscribed, it's not spam.

========================sample email begins==============================
 Return-Path: <bounce-mc.us1_1110737.1350597-username=[email-masked]>
 X-Original-To: [email-masked]
 Delivered-To: [email-masked]
 X-Greylist: delayed 903 seconds by postgrey-1.27 at mta.example.com; Wed, 03 Apr 2013 16:24:22 CEST
 Received-SPF: pass (mail24.wdc01.mcdlv.net: 205.201.129.24 is authorized to 
  use 'bounce-mc.us1_1110737.1350597-username=[email-masked]' in 'mfrom' identity 
  (mechanism 'ip4:205.201.129.24' matched)) receiver=mta.example.com; identity=mfrom; 
  envelope-from="bounce-mc.us1_1110737.1350597-username=[email-masked]"; 
  helo=mail24.wdc01.mcdlv.net; client-ip=205.201.129.24
 Received: from mail24.wdc01.mcdlv.net (mail24.wdc01.mcdlv.net [205.201.129.24])
  by mta.example.com (Postfix) with ESMTP id AB742DDC
  for <[email-masked]>; Wed,  3 Apr 2013 16:24:22 +0200 (CEST)
 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=k1; d=mail24.wdc01.mcdlv.net;
  h=Subject:From:Reply-To:To:Date:Message-ID:List-Unsubscribe:Sender:Content-Type:MIME-Version; i=noreply=[email-masked];
  bh=6IA6whsf6Mi46BRi22XWXWox/5E=;
  b=NTAL+qICFA0yYELNcLO1prdSsCBvdnpAWsk1ldUZcowdg3hUO2bsmmq8Ozv2F1FRnN7lMBc+1jQ8
    +Tw8kcRt4/yD3mAsdXfQzvlgRIs55W1vJm7jn8SBhLcmK68PlAdB1jg6zWKMJVkv0M09rpC5l04x
    7/wCUrnuL9EMVEb0P1k=
 DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=k1; d=mail24.wdc01.mcdlv.net;
  b=l69UWJaIbsYh5rKEXj7xG9MYNKIyxh67fHRU5Rog9hGjqsc5jOI5sWyV/FA+U7e6XD6oTpmJvLbc
    pLVD1a0jbFybeN3Y98o8mkvntmQpQe0dpUb2ASXWkthAneLqFh/+GGh5UHa0lNi56heF+5zmUT0P
    r7Ef+4hXZO4yBij7EQA=;
 Received: from (127.0.0.1) by mail24.wdc01.mcdlv.net (PowerMTA(TM) v3.5r16) id hbgtpg0rhiou for <[email-masked]>; Wed, 3 Apr 2013 14:09:15 +0000 (envelope-from <bounce-mc.us1_1110737.1350597-username=[email-masked]>)
 Subject: =?utf-8?Q?News=20from=20the=20Symantec=20Connect=20Community?=
 From: =?utf-8?Q?Symantec=20Connect?= <[email-masked]>
 Reply-To: =?utf-8?Q?Symantec=20Connect?= <[email-masked]>
 To: <[email-masked]>
 Date: Wed, 3 Apr 2013 14:09:15 +0000
 Message-ID: <[email-masked]>
 X-Mailer: MailChimp Mailer - **CID8bb792691bd8db17d31c**
 X-Campaign: mailchimpb7d514bd368b15a2ce69ce107.8bb792691b
 X-campaignid: mailchimpb7d514bd368b15a2ce69ce107.8bb792691b
 X-Report-Abuse: Please report abuse for this campaign here: http://www.mailchimp.com/abuse/abuse.phtml?u=b7d514bd368b15a2ce69ce107&id=8bb792691b&e=d8db17d31c
 x-accounttype: pd
 List-Unsubscribe: <mailto:[email-masked]?subject=unsubscribe>, <http://symantec.us1.list-manage.com/unsubscribe?u=b7d514bd368b15a2ce69ce107&id=63cfc79b25&e=d8db17d31c&c=8bb792691b>
 Sender: "Symantec Connect" <noreply=[email-masked]>
 x-mcda: FALSE
 Content-Type: multipart/alternative; boundary="_----------=_MCPart_639961374"
 MIME-Version: 1.0
========================sample email endns==============================

I would like cases like this to be addressed in the BCP document for DMARC, toghether with suggestions for alternative ways to send such an email in a DMARC-compatible way.

Regards,

J. Gomez

---

From: Franck Martin <[email-masked]>
Date: Wed, 3 Apr 2013 20:45:22 +0000

Yes, and I got through the same problems to get all our third parties to
align it was not too hard but it required some focus, some involving
getting them to start to DKIM sign.

This FAQ http://www.dmarc.org/faq.html#s_14 answers briefly what has to be
done for a third party. I don't know other solutions, but they have proven
sufficient for everyone I had to work with.

I think DMARC offers an opportunity to inventory all the mail streams an
organization uses, and to get them to a certain corporate level of
standards. It may requires you to write new on boarding rules for third
parties, and be capable to say to a vendor, and more important to your own
people: "sorry, you can't comply with our security rules, so we can't have
you as a vendor until you do". I guess I have a slight bit more power on
vendors to open this road...

So this seems to me a problem at OSI layer 9
http://en.wikipedia.org/wiki/Layer_8

It is important to see that DMARC relies heavily on
http://tools.ietf.org/html/draft-kucherawy-dmarc-base-00#section-3.4 1.

1.   The RFC5322.From domain is the identifier used for all message
        validation operations, as it is the single identifier in the
        message likely to be visible to the user.

If there is no authentication glue to RFC5322.From then you allow anyone
to send for you...

On 4/3/13 1:27 PM, "J. Gomez" <[email-masked]> wrote:

>Hello.
>
>I have this sample email which I got that would fail both SPF and DKIM in
>the realm of DMARC, although it would pass both SPF and DKIM
>"by-themselves". However as the RFC5322.From header is not aligned with
>SPF nor DKIM, it would fail DMARC.
>

---

From: Terry Zink <[email-masked]>
Date: Wed, 3 Apr 2013 21:11:28 +0000

I don't think any of the options DMARC FAQ are satisfactory:

> A.Integrate externally: The third party sender uses its own mail
> servers to send your emails 
>   1. Delegate a sub domain so they can put their own DKIM record and
>      SPF record in the DNS. 
>   2. Give the third party a DKIM private key to sign the emails and 
>      publish the public key in your DNS and/or add their sending IP, 
>      maybe via a SPF include, to your SPF record. 

This is probably the most realistic workaround. But it makes diagnosis difficult to see who is actually sending the messages. For example, suppose BigBank.com outsources its email to BigEmailers.com and the setup is as above, and the message looks as below:

SMTP Mail From: [email-masked]
5322 From: communications.email.BigBank.com

Neither of those lets the receiver know that the mail actually came from BigEmailers.com. You also have to manage private keys both within your own organization and with a 3rd party. Who knows how reliable they are? On the other hand:

SMTP Mail From: [email-masked]
5322 From: communications.email.BigBank.com

This makes it easier to see who is the originator of the email. But it also fails DMARC.

> B. Integrate internally: Get the third party sender to relay all your emails via 
> your mail server.

Many large organizations would strongly push back at this, and rightly so. It's a security risk to allow someone else to send mail through your own hardware and network (unless that is your business model).

> C. Do not integrate and tell them not to spoof

This is not workable, either. As a consumer, I would be confused if mail from [email-masked] arrived in my inbox, claiming to be from BigBank. I'd think it was a phish. BigBank wants the 5322 From to be BigBank.com.

Thus, in my view, the sending-mail-on-behalf-of-another is problematic for DMARC and each workaround has its own constraints which may not be satisfactory to many senders and brands.

-- Terry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Franck Martin
Sent: Wednesday, April 03, 2013 1:45 PM
To: J. Gomez; [email-masked]
Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DMARC

Yes, and I got through the same problems to get all our third parties to align it was not too hard but it required some focus, some involving getting them to start to DKIM sign.

This FAQ http://www.dmarc.org/faq.html#s_14 answers briefly what has to be done for a third party. I don't know other solutions, but they have proven sufficient for everyone I had to work with.

I think DMARC offers an opportunity to inventory all the mail streams an organization uses, and to get them to a certain corporate level of standards. It may requires you to write new on boarding rules for third parties, and be capable to say to a vendor, and more important to your own
people: "sorry, you can't comply with our security rules, so we can't have you as a vendor until you do". I guess I have a slight bit more power on vendors to open this road...

If there is no authentication glue to RFC5322.From then you allow anyone to send for you...

On 4/3/13 1:27 PM, "J. Gomez" <[email-masked]> wrote:

>Hello.
>
>I have this sample email which I got that would fail both SPF and DKIM 
>in the realm of DMARC, although it would pass both SPF and DKIM 

_______________________________________________
dmarc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: Terry Zink <[email-masked]>
Date: Wed, 3 Apr 2013 21:12:48 +0000

To clarify my point, these workarounds work, but the tradeoffs may not be worth it.

-- Terry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Terry Zink
Sent: Wednesday, April 03, 2013 2:11 PM
To: Franck Martin; J. Gomez; [email-masked]
Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DMARC

> B. Integrate internally: Get the third party sender to relay all your 
> emails via your mail server.

-- Terry

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 03 Apr 2013 23:37:41 +0200

Hi, Terry,

On 04/03/2013 11:11 PM, Terry Zink wrote:
> Neither of those lets the receiver know that the mail actually came from BigEmailers.com.

Well, that depends on what you define as 'came from'. The d= payload of 
a DKIM signature refers to the owner of the domain that is 'claiming 
some responsibility for the message by signing it', see paragraph 2.5 of 
http://tools.ietf.org/html/rfc6376. Furthermore, there is the difference 
between the Sender of a message and the Author of it. In your example 
BigEmailers.com might be the sender, but BigBank can still take the 
responsibility for submitting the message to the e-mail ecosystem 
(sending it via the mailers of BigEmailers.com).

> You also have to manage private keys both within your own organization and with a 3rd party. Who knows how reliable they are?

Many organizations have delegated their DNS administration to their 
provider or another 3rd party, which means the trust model of DKIM and 
SPF has its own weaknesses as well. That doesn't mean DKIM and SPF 
cannot be used. Likewise, we cannot say DMARC cannot be used in this 
scenario, but it is important to keep in mind these weaknesses, make a 
risk analysis and decide whether to use these technologies (or not) and 
whether to delegate DNS and/or signing to 3rd parties (or not).

/rolf

---

From: Terry Zink <[email-masked]>
Date: Wed, 3 Apr 2013 21:41:13 +0000

> Furthermore, there is the difference between the Sender of a message and the Author of 
> it. In your example BigEmailers.com might be the sender, but BigBank can still take the 
> responsibility for submitting the message to the e-mail ecosystem (sending it via the 
> mailers of BigEmailers.com).

True.

> Likewise, we cannot say DMARC cannot be used in this scenario, but it is important 
> to keep in mind these weaknesses, make a risk analysis and decide whether to use these 
> technologies (or not) and whether to delegate DNS and/or signing to 3rd parties (or not).

Correct, this is a better way to put it.

-- Terry

-----Original Message-----
From: Rolf E. Sonneveld [mailto:[email-masked]] 
Sent: Wednesday, April 03, 2013 2:38 PM
To: Terry Zink
Cc: Franck Martin; J. Gomez; [email-masked]
Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DMARC

Hi, Terry,

> Neither of those lets the receiver know that the mail actually came from BigEmailers.com.

Well, that depends on what you define as 'came from'. The d= payload of a DKIM signature refers to the owner of the domain that is 'claiming some responsibility for the message by signing it', see paragraph 2.5 of http://tools.ietf.org/html/rfc6376. Furthermore, there is the difference between the Sender of a message and the Author of it. In your example BigEmailers.com might be the sender, but BigBank can still take the responsibility for submitting the message to the e-mail ecosystem (sending it via the mailers of BigEmailers.com).

> You also have to manage private keys both within your own organization and with a 3rd party. Who knows how reliable they are?

Many organizations have delegated their DNS administration to their provider or another 3rd party, which means the trust model of DKIM and SPF has its own weaknesses as well. That doesn't mean DKIM and SPF cannot be used. Likewise, we cannot say DMARC cannot be used in this scenario, but it is important to keep in mind these weaknesses, make a risk analysis and decide whether to use these technologies (or not) and whether to delegate DNS and/or signing to 3rd parties (or not).

/rolf

---

From: Franck Martin <[email-masked]>
Date: Wed, 3 Apr 2013 21:47:43 +0000

On 4/3/13 2:12 PM, "Terry Zink" <[email-masked]> wrote:

>This is probably the most realistic workaround. But it makes diagnosis
>difficult to see who is actually sending the messages. For example,
>suppose BigBank.com outsources its email to BigEmailers.com and the setup
>is as above, and the message looks as below:
>

The sending IP and received headers and message id, will tell you who sent
the email, but is it important (see later)?

>
>Neither of those lets the receiver know that the mail actually came from
>BigEmailers.com. You also have to manage private keys both within your
>own organization and with a 3rd party. Who knows how reliable they are?
>On the other hand:
>

BigBank is the one contracting bigemailers, I find them responsible for
the email they send rather than bigemailers. When you lodge a complain to
bigemailers the reaction will be to complain to bigbank. If you can't
control a vendor, or upheld them to your standards don't contract them. So
I prefer to complain to big bank directly because they do care about their
emails.

>Many large organizations would strongly push back at this, and rightly
>so. It's a security risk to allow someone else to send mail through your
>own hardware and network (unless that is your business model).
>

It is their choice, but also many large organizations do it too. And this
is the business model of sendgrid and messagebus, just to cite a few that
comes to mind.

>This is not workable, either. As a consumer, I would be confused if mail
>from [email-masked] arrived in my inbox, claiming to be from
>BigBank. I'd think it was a phish. BigBank wants the 5322 From to be
>BigBank.com.

It depends what your use case is, if it is to send a survey from
surveymonkey, I guess this would be fine, and they could have a dmarc
record with p=reject too...

>
>
>Thus, in my view, the sending-mail-on-behalf-of-another is problematic
>for DMARC and each workaround has its own constraints which may not be
>satisfactory to many senders and brands.
>

Sure, it is not to be taken lightly, it is about your reputation and you
don't want to be associated with anyone that cannot upheld your standards.
I don't consider any as a workaround, define your use cases, assess your
security risks and make your choices wisely.

---

From: "J. Gomez" <[email-masked]>
Date: Thu, 4 Apr 2013 00:01:17 +0200

On Wednesday, April 03, 2013 11:11 PM [GMT+1=CET], Terry Zink wrote:

> This is probably the most realistic workaround. But it makes
> diagnosis difficult to see who is actually sending the messages. For
> example, suppose BigBank.com outsources its email to BigEmailers.com
> and the setup is as above, and the message looks as below:   
> 

Well, I don't think in your example the receiver would mind that the "material" sender, BigEmailers.com, was transparent to him, as the receiver only knows and only cares for BigBank.com, who is the "branded" sender that he is interested to hear about. So as long as what the receiver sees in his MUA, "From: [email-masked]", is authentic, then all is good.

Option 2 above I regard and cumbersome, error prone, and ugly.

However, option 1 above seems to me as the way to go, and in my opinion the industry SHOULD standardize on it.

I have received an email (to which I am subscribed, it's not spam) which I think illustrates perfectly the use of option 1 above:

==========================email with delegated subdomain begins===============
 Return-Path: <[email-masked]>
 X-Original-To: [email-masked]
 Delivered-To: [email-masked]
 Received-SPF: pass (news.foromtb.com: Sender is authorized to use [email-masked]' in 'mfrom' identity 
  (mechanism 'include:spf-a.emailvision.net' matched)) receiver=mta.example.com; identity=mfrom; 
  envelope-from="[email-masked]"; helo=lithium-thfi.ccemails.com; client-ip=81.92.114.35
 Received: from lithium-thfi.ccemails.com (lithium-thfi.ccemails.com [81.92.114.35])
  by mta.example.com (Postfix) with ESMTP id 5EC10C6A
  for <[email-masked]>; Tue,  2 Apr 2013 10:46:34 +0200 (CEST)
 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=emv; d=news.foromtb.com;
  h=Date:From:Reply-To:To:Message-ID:Subject:MIME-Version:Content-Type:List-Unsubscribe; i=[email-masked];
  bh=aGJl9CDQjnYr4CUovQNBDurhsmE=;
  b=xRKeHeiQtBFOg5wmUfIbIJ0GvBQH5mgZNnXm5L6bhyulecHl9qH5n6jNP8YZ2hHiT0Uafdw5/VYD
    cKh2xtMqX4kF8+jiXQItC0CEO9Mg5ljrcmMlRAQk3NMvxYQB8a046tXMs65onDR+BH0Di2hZWX/f
    EqT5vJjImOnxiXM3j1A=
 Received: by lithium-thfi.ccemails.com id hbades167582 for <[email-masked]>; Tue, 2 Apr 2013 10:46:33 +0200 (envelope-from <[email-masked]>)
 Date: Tue, 2 Apr 2013 10:46:33 +0200 (CEST)
 From: Boletin ForoMTB <[email-masked]>
 Reply-To: Boletin ForoMTB <[email-masked]>
 To: Username in ForoMTB <[email-masked]>
 Message-ID: <[email-masked]>
 Subject: =?iso-8859-15?Q?Tres_a=F1os_pedaleando_juntos_con_Retto_tienen_premio?=
 MIME-Version: 1.0
 Content-Type: multipart/alternative; boundary=4771087584587300
 X-EMV-Platform: p2ccc.campaigncommander.com$
 X-EMV-CampagneId: 477108$
 X-EMV-MemberId: 7584587300$
 List-Unsubscribe: <http://p2trc.emv2.com/HD?a=ENX7Cqjinq_L8SA9MKJInE7nGHxKLEXWy_cStGb5lw8W0bBhOG5mpqVsje_HhdDQSlHx>, <mailto:[email-masked]?subject=unsubscribe-2-ENX7Cqjinq_L8SA9MKJInE7nGHxKLEXWy_cStGb5lw8W0bBhOG5mpqVsje_HhdDQSlHx>
==========================email with delegated subdomain ends===============

Here, the domain owner, "foromtb.com", is running naked regarding SPF, etc:

 $ host -t txt _dmarc.foromtb.com.
 Host _dmarc.foromtb.com. not found: 3(NXDOMAIN)

 $ host -t txt foromtb.com.
 foromtb.com has no TXT record

 $ host -t mx foromtb.com.
 foromtb.com mail is handled by 0 mail.foromtb.com.
 foromtb.com mail is handled by 10 www.foromtb.com.

However, they have outsourced their email marketing operations to EMV2.com by means of giving them control of their subdomain "news.foromtb.com", which EMV2 has clothed up handsomely in SPF, DKIM and DMARC, together with proper reverse DNS, etc.:

 $ host -t txt news.foromtb.com.
 news.foromtb.com descriptive text "v=spf1 include:spf-a.emailvision.net include:spf-b.emailvision.net include:spf-c.emailvision.net -all"
 news.foromtb.com descriptive text "spf2.0/pra include:senderid-a.emailvision.net include:senderid-b.emailvision.net include:senderid-c.emailvision.net -all"

 $ host -t txt _dmarc.news.foromtb.com.
 _dmarc.news.foromtb.com descriptive text "v=DMARC1\; p=none\; rua=[email-masked]\; rf=afrf\; pct=100\;"

 $ host -t mx news.foromtb.com.        
 news.foromtb.com mail is handled by 10 smtp1.emv2.com.
 news.foromtb.com mail is handled by 20 smtp2.emv2.com.

 $ host 81.92.114.35
 35.114.92.81.in-addr.arpa domain name pointer lithium-thfi.ccemails.com.

 $ host lithium-thfi.ccemails.com
 lithium-thfi.ccemails.com has address 81.92.114.35
 lithium-thfi.ccemails.com mail is handled by 10 smtp1.emv2.com.
 lithium-thfi.ccemails.com mail is handled by 20 smtp2.emv2.com.

This approach in my opinion is clean and non convoluted, for (1) the "branded" sender, (2) the "material" sender, and (3) the final recipient. Note the perfect alignment of the RFC5322.From header with both SPF and DKIM, and that only in the "Reply-To:" header is the domain owner's main domain used.

Plus, it passed (1) SPF by its own, (2) DKIM by its own, and (3) DMARC itself. I could not dream of a more perfect execution than this!

Regards,

J. Gomez

---

From: "John Levine" <[email-masked]>
Date: 3 Apr 2013 22:12:34 -0000

>I have this sample email which I got that would fail both SPF and DKIM in the realm of DMARC, although it
>would pass both SPF and DKIM "by-themselves". However as the RFC5322.From header is not aligned with SPF nor
>DKIM, it would fail DMARC.
>

It was sent on Symantec's behalf by Mailchimp, an ESP in the US.  The
return address is at one of Mailchimp's domains, presumably so they
can more easily do the bounce handling and analytics.  This is a very
common setup at ESPs.

I know people at Mailchimp, they're quite sophisticated, and I have no
doubt that if Symantec told them they were worried about phishing and
wanted to mail with a restricive DMARC policy, Mailchimp would adjust
the mail stream to make it happen.  Do you have reason to believe
otherwise?

I don't have deep insight into the motivations of the people who
designed DMARC, but I am quite sure that allowing every mailer in the
world to keep mailing with no change whatsoever to their existing
cruddy practices was not on the list.  You might want to review the
list archives at dmarc.org where a lot of these issues have come up
before.

R's,
John

---

From: Franck Martin <[email-masked]>
Date: Wed, 3 Apr 2013 22:21:59 +0000

To be noted:
From: Boletin ForoMTB <[email-masked]>

with no reply-to: would have been fine with DMARC in relaxed mode (which
is the record they published).

On 4/3/13 3:01 PM, "J. Gomez" <[email-masked]> wrote:

>Well, I don't think in your example the receiver would mind that the
>"material" sender, BigEmailers.com, was transparent to him, as the
>receiver only knows and only cares for BigBank.com, who is the "branded"
>sender that he is interested to hear about. So as long as what the
>receiver sees in his MUA, "From: [email-masked]", is authentic, then
>all is good.
>
>I have received an email (to which I am subscribed, it's not spam) which
>I think illustrates perfectly the use of option 1 above:
>
>
> Received-SPF: pass (news.foromtb.com: Sender is authorized to use
>[email-masked]' in 'mfrom' identity
>  (mechanism 'include:spf-a.emailvision.net' matched))
>receiver=mta.example.com; identity=mfrom;
>  envelope-from="[email-masked]";
>helo=lithium-thfi.ccemails.com; client-ip=81.92.114.35
> Received: by lithium-thfi.ccemails.com id hbades167582 for
><[email-masked]>; Tue, 2 Apr 2013 10:46:33 +0200 (envelope-from
><[email-masked]>)
> Subject: 
>=?iso-8859-15?Q?Tres_a=F1os_pedaleando_juntos_con_Retto_tienen_premio?=
> MIME-Version: 1.0
> List-Unsubscribe:
><http://p2trc.emv2.com/HD?a=ENX7Cqjinq_L8SA9MKJInE7nGHxKLEXWy_cStGb5lw8W0b
>BhOG5mpqVsje_HhdDQSlHx>,
><mailto:[email-masked]?subject=unsubscribe-2-ENX7Cqjinq_L8SA
>9MKJInE7nGHxKLEXWy_cStGb5lw8W0bBhOG5mpqVsje_HhdDQSlHx>
>However, they have outsourced their email marketing operations to
>EMV2.com by means of giving them control of their subdomain
>"news.foromtb.com", which EMV2 has clothed up handsomely in SPF, DKIM and
>DMARC, together with proper reverse DNS, etc.:
>
> news.foromtb.com descriptive text "v=spf1 include:spf-a.emailvision.net
>include:spf-b.emailvision.net include:spf-c.emailvision.net -all"
> news.foromtb.com descriptive text "spf2.0/pra
>include:senderid-a.emailvision.net include:senderid-b.emailvision.net
>include:senderid-c.emailvision.net -all"
>
> _dmarc.news.foromtb.com descriptive text "v=DMARC1\; p=none\;
>rua=[email-masked]\; rf=afrf\; pct=100\;"
>
>This approach in my opinion is clean and non convoluted, for (1) the
>"branded" sender, (2) the "material" sender, and (3) the final recipient.
>Note the perfect alignment of the RFC5322.From header with both SPF and
>DKIM, and that only in the "Reply-To:" header is the domain owner's main
>domain used.
>
>Plus, it passed (1) SPF by its own, (2) DKIM by its own, and (3) DMARC
>itself. I could not dream of a more perfect execution than this!
>
>Regards,
>
>J. Gomez
>

---

From: "John Levine" <[email-masked]>
Date: 3 Apr 2013 22:30:16 -0000

>Neither of those lets the receiver know that the mail actually came from BigEmailers.com. You also have to
>manage private keys both within your own organization and with a 3rd party. Who knows how reliable they are?

Apparently reliable enough, since it's a very common way for big
companies to configure their ESP mail including the DKIM signatures.
If the ESP turns out to be corrupt or incompetent, the company always
has the option of removing the DNS delegation for email.bigbank.com,
installing poison records to make all the SPF and DMARC fail, and
using a different DNS name at their new ESP.

I know that Forefront has a lot of big corporate customers, but it is
my impression that you're mostly doing individual mail, exactly the
kind that DMARC has the most trouble with due to forward to gmail,
mailing lists and the like.  We could round up some more people from
the ESPs and bulk mailers that DMARC matches best and see what kinds
of configurations they expect would be hard and what would be easy.

R's,
John

---

From: Steve Jones <[email-masked]>
Date: Wed, 3 Apr 2013 16:15:28 -0700

On Wed, Apr 3, 2013 at 2:11 PM, Terry Zink <[email-masked]>wrote:

> This is probably the most realistic workaround.

The use of a sub-domain per product and/or 3rd party vendor, and providing
them with signing keys, is the preferred model for my employer (BofA). It
takes work, it may cost more, but having our customers compromised costs us
too.

> But it makes diagnosis difficult to see who is actually sending the
> messages. For example, suppose BigBank.com outsources its email to
> BigEmailers.com and the setup is as above, and the message looks as below:
>
> BigEmailers.com.

What does "actually came from" mean? If you want something provable in any
way, 5321.MFROM is useless because it isn't signed.

If you just mean for troubleshooting, why you have IP address data, reverse
lookups, and asserted hostnames in logs and headers - and you're parsing
all that or you wouldn't have the 5322.From available. You certainly have
the "last hop" data available as state when you're handling the inbound
connection... So I have all that information available, but you need to see
the 3rd party identified in the 5321.MFROM in order to tell where it came
from?

I don't get it. Or is your "receiver" not the ISP/IT staff or the software
they operate?

Sidenote: Are you deliberately omitting an "@" in both of your 5322.From
examples? Or is there a notational convention I've misplaced?

> You also have to manage private keys both within your own organization and
> with a 3rd party. Who knows how reliable they are?

We have revised contract terms to specify how 3rd parties must perform in
these areas. If they want our business, they'll meet the standards. And we
audit all of our vendors periodically.

Initially we got all kinds of pushback from ESPs who were happy with their
existing business models and didn't want to make changes. We got absurd
proposal prices - basically to buy them entire new infrastructures - or
flat refusals. From those who wanted our business, we got a timeline or
roadmap that led to compliance...

I don't expect the average small business to go through all that. But it is
my hope that as we require more responsible practices at the top of the ESP
market, they filter down through the middle to the bottom of the market,
and small businesses and their customers will benefit too.

> Many large organizations would strongly push back at this, and rightly so.
> It's a security risk to allow someone else to send mail through your own
> hardware and network (unless that is your business model).
>

Then again, we may require it. Consider the case where a CRM platform like
SalesForce is sending out messages on your behalf, from regulated employees
- financial advisors, portfolio managers, etc. You're not only dealing with
sensitive traffic with considerable potential losses in the event of
successful phishing, you're usually under legal obligation to archive all
such traffic.

But aside from that specific example, we've spec'd several cases where we
would do this for email originating at partner firms to make sure the
authentication is done right. Again sub-domains are useful to segment
traffic, allow for different policies, and help prevent a "mishap" at the
partner from resulting in email masquerading as an address/domain that we
haven't authorized them to use. If they do spew badness with the authorized
sub-domain, we can disable relaying and push policies to block all of that
traffic as soon as it's detected - without impacting the rest of our
mailstreams.

Thus, in my view, the sending-mail-on-behalf-of-another is problematic for
> DMARC and each workaround has its own constraints which may not be

There are trade-offs, to be sure. And not every existing practice is going
to continue to work, anymore than it's acceptable now, as it was ten years
ago, for a random employee to go out with a credit card and hire a
marketing firm to register a domain and send out an email marketing
campaign using one of our brands. (Usually with each URL and <img> tag in
the message using a different domain from all the others...)

--S.

---

From: Steve Jones <[email-masked]>
Date: Wed, 3 Apr 2013 16:35:02 -0700

> way, 5321.MFROM is useless because it isn't signed.

Sorry, that second sentence is as puzzling as anything I'm asking about...
Please disregard.

--S.

---

From: Terry Zink <[email-masked]>
Date: Thu, 4 Apr 2013 00:03:10 +0000

> The use of a sub-domain per product and/or 3rd party vendor, and providing them 
> with signing keys, is the preferred model for my employer (BofA). It takes work,
> it may cost more, but having our customers compromised costs us too.

If it works for BofA, that's a good sign that it would work for other brands, too.

> Sidenote: Are you deliberately omitting an "@" in both of your 5322.From examples? 
> Or is there a notational convention I've misplaced?

First time was a typo. Second time was copy-and-paste of that typo.

Also, I just discovered that there is a MAAWG video and pdf series on DMARC and third-parties are covered in section 6. It goes into the pros and cons of various options:
http://www.maawg.org/activities/training/dmarc-training-series

I withdraw my previous objections to option A.

Move along, move along.

-- Terry

-----Original Message-----
From: Steve Jones [mailto:[email-masked]] 
Sent: Wednesday, April 03, 2013 4:15 PM
To: Terry Zink
Cc: Franck Martin; J. Gomez; [email-masked]
Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DMARC

 On Wed, Apr 3, 2013 at 2:11 PM, Terry Zink <[email-masked]> wrote:

The use of a sub-domain per product and/or 3rd party vendor, and providing them with signing keys, is the preferred model for my employer (BofA). It takes work, it may cost more, but having our customers compromised costs us too.

But it makes diagnosis difficult to see who is actually sending the messages. For example, suppose BigBank.com outsources its email to BigEmailers.com and the setup is as above, and the message looks as below:

What does "actually came from" mean? If you want something provable in any way, 5321.MFROM is useless because it isn't signed.

If you just mean for troubleshooting, why you have IP address data, reverse lookups, and asserted hostnames in logs and headers - and you're parsing all that or you wouldn't have the 5322.From available. You certainly have the "last hop" data available as state when you're handling the inbound connection... So I have all that information available, but you need to see the 3rd party identified in the 5321.MFROM in order to tell where it came from?

I don't get it. Or is your "receiver" not the ISP/IT staff or the software they operate?
Sidenote: Are you deliberately omitting an "@" in both of your 5322.From examples? Or is there a notational convention I've misplaced?

We have revised contract terms to specify how 3rd parties must perform in these areas. If they want our business, they'll meet the standards. And we audit all of our vendors periodically.
Initially we got all kinds of pushback from ESPs who were happy with their existing business models and didn't want to make changes. We got absurd proposal prices - basically to buy them entire new infrastructures - or flat refusals. From those who wanted our business, we got a timeline or roadmap that led to compliance...
I don't expect the average small business to go through all that. But it is my hope that as we require more responsible practices at the top of the ESP market, they filter down through the middle to the bottom of the market, and small businesses and their customers will benefit too.

Then again, we may require it. Consider the case where a CRM platform like SalesForce is sending out messages on your behalf, from regulated employees - financial advisors, portfolio managers, etc. You're not only dealing with sensitive traffic with considerable potential losses in the event of successful phishing, you're usually under legal obligation to archive all such traffic.
But aside from that specific example, we've spec'd several cases where we would do this for email originating at partner firms to make sure the authentication is done right. Again sub-domains are useful to segment traffic, allow for different policies, and help prevent a "mishap" at the partner from resulting in email masquerading as an address/domain that we haven't authorized them to use. If they do spew badness with the authorized sub-domain, we can disable relaying and push policies to block all of that traffic as soon as it's detected - without impacting the rest of our mailstreams.

There are trade-offs, to be sure. And not every existing practice is going to continue to work, anymore than it's acceptable now, as it was ten years ago, for a random employee to go out with a credit card and hire a marketing firm to register a domain and send out an email marketing campaign using one of our brands. (Usually with each URL and <img> tag in the message using a different domain from all the others...) --S.

---

From: Terry Zink <[email-masked]>
Date: Thu, 4 Apr 2013 16:14:36 +0000

Hmm, the timing of this message makes it seem like I have reservations about the various options. 

I don't; this mail just arrived late.

-- Terry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Terry Zink
Sent: Wednesday, April 03, 2013 2:13 PM
To: [email-masked]
Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DMARC

-- Terry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Terry Zink
Sent: Wednesday, April 03, 2013 2:11 PM
To: Franck Martin; J. Gomez; [email-masked]
Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DMARC

-- Terry

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 05 Apr 2013 19:14:40 +0200

Hi

> using a different DNS name at their new ESP.

I couldn't help thinking back to when you wrote:

   In the physical world, banks have marble counters, vaults with
   heavy steel doors, and other physical objects that are hard to
   fake. A building that looks like a bank probably is a bank.
      http://www.circleid.com/posts/fight_phishing_with_branding/

All of that marble and heavy steel was built by external service
providers who contracted those jobs.  Even surveillance is outsourced.
 The only reason for not delegating BigBank.com altogether would be if
they want web and mail to be handled by different providers.  IMHO
getting persuaded to outsource email to competent providers, lest be
accused of insufficient protection against phishing, is the only way
that banks can catch up.

> mailing lists and the like.

Newbie's question (be patient):  As I'm new to DMARC, perhaps I may
ask why cannot a list manager or similar operator change the From:
slightly?  For this message, that would be:

IN:
   From: Alessandro Vesely <[email-masked]>

OUT:
   From: Alessandro Vesely <[email-masked]> (sent by ietf.org)

Where the domain-like token in the trailing comment, if authenticated,
is to be used for alignment instead of the author domain.  That would
stop everyone from getting DMARC feedback that don't pertain to them,
while still being visible in the MUA.  Note that some MUA already
attempts a similar merging of header.from and smtp.mailfrom by
displaying "on behalf of".  In addition, such change would most
probably break any original DKIM signature, thereby clarifying that
any claim of some responsibility was taken over.

BTW:  Why messages in this list are not signed?

> We could round up some more people from the ESPs and bulk mailers
> that DMARC matches best and see what kinds of configurations they
> expect would be hard and what would be easy.

---

From: Franck Martin <[email-masked]>
Date: Fri, 5 Apr 2013 17:48:59 +0000

>   From: Alessandro Vesely <[email-masked]> (sent by ietf.org)

What you describe if I'm not mistaken, is not a valid email syntax (or
deprecated one), but what your MUA present you with.
http://tools.ietf.org/html/rfc5322#section-3.4 mailbox syntax

The use of the Sender: header for DMARC as an identifier was not adopted
because it could be easily abused (cf systems like send this article to a
friend) and not all MUAs display it to the user (or in a meaningful way).

However, and that's another topic your could do:
From: "Alessandro Vesely (via IETF)" <[email-masked]>

Reply to: "DMARC List" <[email-masked]>

or

From: "Alessandro Vesely (via IETF)" <[email-masked]>
Reply to: "DMARC List" <[email-masked]>, "Alessandro Vesely"
<[email-masked]>

Note I also do not want to encourage people to put anything that looks
like an email address or domain in the friendly From part.

---

From: "John R Levine" <[email-masked]>
Date: 5 Apr 2013 14:08:56 -0400

> BTW:  Why messages in this list are not signed?

Beats me.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: "John Levine" <[email-masked]>
Date: 5 Apr 2013 18:11:20 -0000

>>slightly?

For the umpteenth time, because they have no incentive to do so.

If DMARC is going to be successful, it has to work with the existing
mail system.  For the most part it does.  

The mailing list arguments are a tempest in a teapot and only arise
because a few people wilfully publish inappropriate DMARC records.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 05 Apr 2013 20:14:54 +0200

> http://tools.ietf.org/html/rfc5322#section-3.4 mailbox syntax

The trailing comment is the CFWS there.

> friend) and not all MUAs display it to the user (or in a meaningful way).

Yup, for visibility.

> Reply to: "DMARC List" <[email-masked]>, "Alessandro Vesely"

These were discussed various times, e.g.
http://mipassoc.org/pipermail/dkim-dev/2009-September/000202.html

> like an email address or domain in the friendly From part.

Yeah, Thunderbird chokes a bit on that, placing a comma before the
comment and displaying it as if it were an additional sender...

---

From: Franck Martin <[email-masked]>
Date: Fri, 5 Apr 2013 18:58:39 +0000

>The trailing comment is the CFWS there.

Ah, ABNF is really obscure to me... I work better with examples and I have
never seen your example in use... Sorry for that.

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 06 Apr 2013 12:40:33 +0200

> For the umpteenth time, because they have no incentive to do so.

Thank you for your patience.  Perhaps, DMARC consideration for such
slight change (and let me underline _slight_) could be enough of an
incentive for some mailing lists.  For sure, we cannot expect that all
of them suddenly change, considering that many don't even sign.

> because a few people wilfully publish inappropriate DMARC records.

Right, but isn't that the same weakness as ADSP?  Both protocols seem
to be good at anti-phishing, but then they work for transactional mail
only.

---

From: "John Levine" <[email-masked]>
Date: 6 Apr 2013 16:49:40 -0000

>to be good at anti-phishing, but then they work for transactional mail

DMARC and ADSP share many of the same issues, most notably that it is
incredibly difficult to explain to people that a stricter policy is
not necessarily "more secure" and that if your published policy does
not match your real mailing practices, you will cause problems both
for yourself and for recipient systems who (unwisely) believe what you
say.

---

From: Franck Martin <[email-masked]>
Date: Sat, 6 Apr 2013 20:53:50 +0000

>of them suddenly change, considering that many don't even sign.

What DMARC still suffers from is tools. The community has been working on
some. You know the saying people scratch their own itch. opendmarc is
released, can be used in production, but it is just now that you have a
package to install it relatively easily on Ubuntu. I have heard of RPMs,
but opendmarc is still hard to install. It will come when it is shipped by
default in linux distro releases.

Same for mailing lists, the issue is not new
(http://wiki.list.org/display/DEV/DKIM), but the people involved in
developing say mailman, are focusing on some other more important parts,
like releasing 3.0. So until there are options available, in a mailing
list software, we won't know if operators would make this change or not,
at the moment they cannot. Granted there is no incentive, but is it
because like when I talk to third parties mailers who would like to do
business with us, they mostly have never heard of DMARC?

There is a patch for mailman 2.1, you can try it
https://code.launchpad.net/~mlm-author/mailman/2.1-author

I have not had the time to push it into 3.0, volunteers?

>to be good at anti-phishing, but then they work for transactional mail

Even with transactional emails there are issues:
http://www.it.cornell.edu/services/cmail/howto/spoof.cfm
This specific problem has not yet been addressed, it is quite typical in
dot edu organizations, but I have seen people being more and more mindful
about it, because now it is not anymore one odd user, and I have seen
system changes to avoid that forwarding breaks DKIM.

I cannot find any article describing conditions when Exchange break/don't
break DKIM when forwarding... If someone has a pointer?

---

From: "John Levine" <[email-masked]>
Date: 6 Apr 2013 21:34:32 -0000

>Authentication-Results: iecc.com / 1; spf=pass spf.mailfrom=[email-masked] spf.helo=mail.ietf.org;
>dkim=fail (bad signature) header.d=linkedin.com header.b="dNQNjB+m"; dmarc=fail.reject
>header.from=linkedin.com

>What DMARC still suffers from is tools.

Well, that, and some serious education for mail system operators about
what is or isn't appropriate in their DMARC assertions.

If I actually implemented DMARC according to the spec, Linkedin's
incorrect policy assertions would bounce me off the list.  They know
this and refuse to fix it, or even to admit the problems they're
causing.  It isn't a big problem now, since the overall adoption of
DMARC is still relatively low, but it could be a significant problem
in the future if it's widely used.

>developing say mailman, are focusing on some other more important parts,

For the zillionth time, there is no chance whatsoever that Mailman and
other open source list managers will change to work around DMARC's
limitations.  I wish people would stop wasting time by claiming
otherwise.  (The most they would plausibly do is a simple hack to
prevent damage to the rest of their users by refusing mail from
senders with policies other than p=none, which is easy to do with a
shim between the incoming MDA and the list manager.)

List software didn't change for SPF, they didn't change for DKIM ADSP,
and they're not going to change for DMARC.  This is not a bug or flaw
in mailing lists, it's a limitation in DMARC that we have to be sure
to document as clearly as possible and see if we can somehow persuade
people to publish accurate policy statements.

R's,
John

---

From: Franck Martin <[email-masked]>
Date: Sat, 6 Apr 2013 21:52:55 +0000

But you got this email, I don't see where is the problem. :P

I think we will agree to disagree.

On 4/6/13 2:34 PM, "John Levine" <[email-masked]> wrote:

>>Authentication-Results: iecc.com / 1; spf=pass
>>spf.mailfrom=[email-masked] spf.helo=mail.ietf.org;

---

From: "John Levine" <[email-masked]>
Date: 6 Apr 2013 22:23:58 -0000

>But you got this email, I don't see where is the problem. :P

Sigh.  My point exactly.

R's,
John

---

From: "J. Gomez" <[email-masked]>
Date: Sun, 7 Apr 2013 01:26:09 +0200

On Friday, April 05, 2013 8:11 PM [GMT+1=CET], John Levine wrote:

> > > Newbie's question (be patient):  As I'm new to DMARC, perhaps I
> > > may ask why cannot a list manager or similar operator change the
> > > From: slightly?
> 

If DMARC is going to be successful, it will be so when you can implement "p=reject", which is not compatible with the current state of the art in mailing list software and common behaviour.

If you cannot, as a sender, annouce "p=reject" for DMARC, then DMARC is not going to help you much as a sender, except for its reporting capabilities.

Regards,

J. Gomez

---

From: "J. Gomez" <[email-masked]>
Date: Sun, 7 Apr 2013 01:46:25 +0200

On Saturday, April 06, 2013 10:53 PM [GMT+1=CET], Franck Martin wrote:
> I cannot find any article describing conditions when Exchange
> break/don't break DKIM when forwarding... If someone has a pointer?

Microsoft Exchange most definetly breaks DKIM (*) in already received email messages. Microsoft Exchange stores the received messages in it's own proprietary TNEF format, wich you can only access through MAPI, which prety much means only through Outlook. If you access the messages in an Exchange mailbox through POP3 or IMAP, you get a "translation" on-the-fly of the body of the message done by Exchange from its internal TNEF format to "whatever" (**) (***).

(*) That happens for sure when a message lands in an Exchange mailbox. But I can not say about a pure forwarding scenario where the forwarded message does not land into a Exchange mailbox.

(**) "Whatever" by default is "BestBodyFormat", which means Exchange will present you with an aproximation to the orginal content of the message when it serves the message to you through POP3 or IMAP. See: http://esupport.lenovo.com/mss/mss.pl?doctype=kb&docid=OTQ0MTUz
https://groups.google.com/forum/?fromgroups=#!topic/WAGIT/D16Yygt4xmo
http://forums.mozillazine.org/viewtopic.php?f=39&t=628678

(***) This "translation" is a modification of the message and therefore obviously breaks the DKIM signature.

Regards, 

J. Gomez

---

From: "J. Gomez" <[email-masked]>
Date: Sun, 7 Apr 2013 02:04:06 +0200

On Saturday, April 06, 2013 11:34 PM [GMT+1=CET], John Levine wrote:
> otherwise.

Is this assetion based on the comtemplation of some magic cristal ball for the future?

If the major mailbox providers (Hotmail, Gmail, Yahoo, AOL, etc.) implement DMARC to the tee, mailing list software will either change to be compatible with DMARC or die.

I bet that if the major mailbox providers implement DMARC to the tee, mailing list software will change to become compatible with DMARC.

The other option is DMARC does not gain traction, and/or it is implemented in the real world with receivers ignoring the "p=reject" policy, which would mean DMARC would become mostly useless.

For example, mailing list software could change the RFC5322.From header from:

 From: John Smith <[email-masked]>

to become:
   
 From: Mailman on behalf of John Smith <[email-masked]>

and then the organizational domain foo.com would sign with DKIM the outgoing message forwarded to the list's subscribers and relay it through a "foo.com" SPF-authorized smarthost. That would make that mailing list message fully DMARC compatible.

Will mailing list sofware go through all this trouble? Nobody knows, but if DMARC becomes an industry standard, it may well be the case.

Regards,

J. Gomez

---

From: "John Levine" <[email-masked]>
Date: 7 Apr 2013 01:05:48 -0000

>Is this assetion based on the comtemplation of some magic cristal ball for the future?

No, it's based on having run mailing lists for several decades,
switching among too many list management packages.  I run about 100
lists, of which about 30 have an interesting amount of traffic.

Just for reference, have you ever run a mailing list?  How many list
management systems are you familiar with?

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 7 Apr 2013 10:29:17 -0700

This is the first I've heard someone say OpenDMARC is hard to install.  So
far the feedback has been the opposite.

I invite you to the opendmarc-users list to describe your experience and
suggest ways to improve it.

---

From: Franck Martin <[email-masked]>
Date: Sun, 7 Apr 2013 18:10:23 +0000

Don't take it personally, not everyone is a technologist and can compile/install a tarball, until there are RPMs (there are debs, I have not seen any RPMs yet) and it is included in linux distributions, openDMARC will remain "hard to install".

http://www.rpmfind.net/linux/rpm2html/search.php?query=opendmarc&submit=Search+...
http://packages.ubuntu.com/search?keywords=opendmarc

This is my point and I stick to it.

I invite you to meet people outside technologist circles and see what the real world is about :P

From: "Murray S. Kucherawy" <[email-masked]<mailto:[email-masked]>>
Date: Sunday, April 7, 2013 10:29 AM
To: Franck Martin <[email-masked]<mailto:[email-masked]>>
Cc: Alessandro Vesely <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question

This is the first I've heard someone say OpenDMARC is hard to install.  So far the feedback has been the opposite.

I invite you to the opendmarc-users list to describe your experience and suggest ways to improve it.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 7 Apr 2013 11:37:41 -0700

I don't find it particularly helpful to answer "How can we improve?" with
antagonism.

But since you said it so nicely, a Google search revealed these:

https://github.com/stevejenkins/OpenDMARC-Fedora
http://packages.debian.org/search?keywords=opendmarc
http://packages.ubuntu.com/quantal-backports/mail/opendmarc

So they're out there if you're willing to look for them.

-MSK

On Sun, Apr 7, 2013 at 11:10 AM, Franck Martin <[email-masked]> wrote:

>  Don't take it personally, not everyone is a technologist and can
> compile/install a tarball, until there are RPMs (there are debs, I have not
> seen any RPMs yet) and it is included in linux distributions, openDMARC
> will remain "hard to install".
>
>
>   From: "Murray S. Kucherawy" <[email-masked]>
> To: Franck Martin <[email-masked]>
> Cc: Alessandro Vesely <[email-masked]>, "[email-masked]" <[email-masked]>
>   This is the first I've heard someone say OpenDMARC is hard to install.
> So far the feedback has been the opposite.
>

---

From: "John Levine" <[email-masked]>
Date: 7 Apr 2013 18:59:48 -0000

>far the feedback has been the opposite.

The documentation is a bit sparse for the reporting part, and it would
be nice to have a cheat sheet for the libraries.

---

From: Franck Martin <[email-masked]>
Date: Sun, 7 Apr 2013 19:04:53 +0000

I said I have seen debs and they are part of ubuntu and I have put the link to them, I have not yet seen a rpm yet, what you point to is a spec file that allows to create a rpm. It is not a RPM.

There is a source RPM at http://stevej.fedorapeople.org/OpenDMARC/

Keep the good work, the rpm will eventually appear on fedora or other distro. It is just a question of time and encouragements, and looks like Steve Jenkins is about to break it on Fedora.

Date: Sunday, April 7, 2013 11:37 AM

I don't find it particularly helpful to answer "How can we improve?" with antagonism.

-MSK

On Sun, Apr 7, 2013 at 11:10 AM, Franck Martin <[email-masked]<mailto:[email-masked]>> wrote:
Don't take it personally, not everyone is a technologist and can compile/install a tarball, until there are RPMs (there are debs, I have not seen any RPMs yet) and it is included in linux distributions, openDMARC will remain "hard to install".

---

From: "J. Gomez" <[email-masked]>
Date: Sun, 7 Apr 2013 22:20:29 +0200

On Sunday, April 07, 2013 3:05 AM [GMT+1=CET], John Levine wrote:

> > > For the zillionth time, there is no chance whatsoever that
> > > Mailman and other open source list managers will change to work
> > > around DMARC's limitations. I wish people would stop wasting time
> > > by claiming otherwise.
> > 

Argument from authority ( http://en.wikipedia.org/wiki/Argument_from_authority ) while warranted, is not of special value to predict the future.

Mailman already has an option to become DMARC-compatible. If that option would become the default configuration for "Mailman out-of-the-box", then all would be fine.

The option is in General Options -> anonymous_list, set to Yes. This puts the mailing list address in the RFC5322.From header in the emails the mailing list software forwards to its subscribers. Do you see any problem in that option?

With time, things do change. Several decades is about time for a change.

Regards,

J. Gomez

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 7 Apr 2013 13:27:17 -0700

Thanks for the suggestions.  I've opened tracker items to deal with both of
those doc points in the next release.

People with feedback about that particular project should avail themselves
of the ticket system on SourceForge or the mailing lists for the project
hosted at trusteddomain.org.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 7 Apr 2013 13:38:05 -0700

The issue isn't so much whether Mailman has an option to support it, but
rather what corners of the deployed email infrastructure are going to be
unable or unwilling to comply for whatever reason.  New or well-maintained
deployments can benefit, but anything upon which a lot of people depend
that doesn't enjoy such attention and flexibility will become a pain
point.  I don't think it's a winning strategy to decide that the people who
would be thus affected will just have to suffer.

To be more specific: What about sites that don't run Mailman?  There are
some pretty big and busy lists out there that run the original Majordomo.

On Sun, Apr 7, 2013 at 1:20 PM, J. Gomez <[email-masked]> wrote:

> Argument from authority (
> http://en.wikipedia.org/wiki/Argument_from_authority ) while warranted,
> is not of special value to predict the future.
>
> Mailman already has an option to become DMARC-compatible. If that option
> would become the default configuration for "Mailman out-of-the-box", then
> all would be fine.
>
> The option is in General Options -> anonymous_list, set to Yes. This puts
> the mailing list address in the RFC5322.From header in the emails the
> mailing list software forwards to its subscribers. Do you see any problem
> in that option?
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 7 Apr 2013 13:40:00 -0700

On Sat, Apr 6, 2013 at 4:26 PM, J. Gomez <[email-masked]> wrote:

> If DMARC is going to be successful, it will be so when you can implement
> "p=reject", which is not compatible with the current state of the art in
> mailing list software and common behaviour.
>
> If you cannot, as a sender, annouce "p=reject" for DMARC, then DMARC is
> not going to help you much as a sender, except for its reporting
> capabilities.
>
>
>
We have already heard from some senders for whom "p=none" plus reporting is
already extremely attractive.  Let's not decide it's a failure just because
"p=reject" has a more limited use case than some people would like.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 7 Apr 2013 13:45:52 -0700

On Sat, Apr 6, 2013 at 5:04 PM, J. Gomez <[email-masked]> wrote:

> If the major mailbox providers (Hotmail, Gmail, Yahoo, AOL, etc.)
> implement DMARC to the tee, mailing list software will either change to be
> compatible with DMARC or die.
>

I think this logic presupposes that all sent mail will at some point in the
future be covered by DMARC "p=reject" policies.  It's already been stated
that "p=reject" is not intended to be used by all senders.  Perhaps the
draft needs to be more assertive about this point.

Suppose we make it clear that "p=reject" is only for transactional mail, or
marketing mail from addresses that don't have users; user mail comes from
another domain or a subdomain that's not guarded by DMARC.  It seems
unlikely transactional mail would even transit lists (would you subscribe
to get your bank statements via a list?  or marketing mail?), so DMARC
doesn't need to interact with lists at all.

> I bet that if the major mailbox providers implement DMARC to the tee,
> mailing list software will change to become compatible with DMARC.
>

I think several have, and I don't think list servers are feeling this
pressure.  Maybe I just don't have all the information yet.

> The other option is DMARC does not gain traction, and/or it is implemented
> in the real world with receivers ignoring the "p=reject" policy, which
> would mean DMARC would become mostly useless.
>

I think that's also a pretty long jump logic-wise.  The traction is already
there, and "p=reject" is already being honoured in at least some places.
The sky doesn't appear to be falling so far.

Will mailing list sofware go through all this trouble? Nobody knows, but if
> DMARC becomes an industry standard, it may well be the case.
>

As you've observed, at least one implementation has the option.  As you've
also observed, time will tell whether it becomes necessary to default it
"on".

We ran through this debate with ADSP years ago.  The solutions then are the
same as the solutions now, as far as I can tell.

-MSK

---

From: Franck Martin <[email-masked]>
Date: Sun, 7 Apr 2013 21:33:35 +0000

Thanks, best explanation on this subject I have seen so far.

On 4/6/13 4:46 PM, "J. Gomez" <[email-masked]> wrote:

>Microsoft Exchange most definetly breaks DKIM (*) in already received
>email messages. Microsoft Exchange stores the received messages in it's
>own proprietary TNEF format, wich you can only access through MAPI, which
>prety much means only through Outlook. If you access the messages in an
>Exchange mailbox through POP3 or IMAP, you get a "translation" on-the-fly
>of the body of the message done by Exchange from its internal TNEF format
>to "whatever" (**) (***).
>
>
>(*) That happens for sure when a message lands in an Exchange mailbox.
>But I can not say about a pure forwarding scenario where the forwarded
>message does not land into a Exchange mailbox.
>
>(**) "Whatever" by default is "BestBodyFormat", which means Exchange will
>present you with an aproximation to the orginal content of the message
>when it serves the message to you through POP3 or IMAP. See:
>http://esupport.lenovo.com/mss/mss.pl?doctype=kb&docid=OTQ0MTUz

---

From: "John Levine" <[email-masked]>
Date: 7 Apr 2013 21:53:20 -0000

>unable or unwilling to comply for whatever reason.

Unwilling is the key point.  Mailman has had the anonymous_list option
for a long time, but nobody uses it because the stuff that regular
lists do like adding subject tags is useful.  That won't change, and
it's not because the people who run mailing lists are stupid or
ignorant.

As I said before, and should be apparent to people who are familiar
with mailing list operation, this shouldn't be a big deal in practice
so long as senders understand why they have to publish DMARC policies
that reflect their actual practices, and not incorrectly say p=reject
because they wrongly imagine it to be "more secure".

R's,
John

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 8 Apr 2013 00:23:08 +0200

On Sunday, April 07, 2013 11:53 PM [GMT+1=CET], John Levine wrote:

> > The issue isn't so much whether Mailman has an option to support
> > it, but rather what corners of the deployed email infrastructure
> > are going to be unable or unwilling to comply for whatever reason.
> 

My guess is that "p=reject" will become in wider and wider use as years past after DMARC is born to the public email ecosystem, just as "-all" is becoming in wider and wider use as years are passing after SPF was born to the public email ecosystem. It's the natural thing to do: "Oh, look, a hammer! Hmm, I guess what it will do to this spam nail problem..."

You are right that "p=reject" will not reflect faithfully the real practice of many Organizational Domains, but nonetheless many Organizational Domains will set "p=reject" anyways, it's such a promising hammer...

Reject,

J. Gomez

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 08 Apr 2013 10:53:36 +0200

On Sun 07/Apr/2013 22:40:00 +0200 Murray S. Kucherawy wrote:
>> If you cannot, as a sender, announce "p=reject" for DMARC, then
>> DMARC is not going to help you much as a sender, except for its
>> reporting capabilities.
>
> We have already heard from some senders for whom "p=none" plus
> reporting is already extremely attractive.  Let's not decide it's a
> failure just because "p=reject" has a more limited use case than
> some people would like.

It is definitely extremely attractive and useful!  Yet there are some
points where reports can be improved.  And one of them is mailing
lists:  Some reports have a "mailing_list" entry in the "reason and
disposition" column.  Now, one can reckon that feedback never hurts,
or rather that it is fairly interesting to evaluate which mail sites
turn out to be the targets chosen by the subscribers of a given list.
 However, I don't think that's what DMARC reports are for.  That extra
information is not only distracting for the recipient, but also a
leakage from the reporter.

For senders, it is difficult and questionable to limit an email domain
to transactional mail only.  A company would need to force users to
hide behind external free-mail accounts, obscuring their own brand.
Or they could set up subdomains, calling upon the public to
discriminate between the secure and the insecure ones.  Not an
alluring prospect.

IMHO DMARC had better handle mailing lists properly, if at all possible.

---

From: John Sweet <[email-masked]>
Date: Mon, 8 Apr 2013 08:32:13 -0700

On Sun, Apr 7, 2013 at 1:45 PM, Murray S. Kucherawy <[email-masked]> wrote:
> another domain or a subdomain that's not guarded by DMARC.

I'd agree with that.  At a DMARC talk recently, someone (maybe you,
maybe Paul Midgen) said that right from the outset: it's not for all
your mail.  It might even have been on the first slide.

For addresses that do have users, I can see the value of a permanent
p=none policy, for monitoring.  An organization may need to enforce an
email usage policy, but be unable to back it up with an SPF -all or
DMARC p=reject.  Reporting makes it possible to track and mitigate
taboo usage.

The only issue might be spam filters assigning any DMARC failure a
score, making it more likely a mailing list digest will end up in
someone's spam folder.  But we pretty much already live in that world
(wrt SPF and DKIM), and I'd expect the filters to evolve over time.

J

---

From: Franck Martin <[email-masked]>
Date: Mon, 8 Apr 2013 16:22:29 +0000

>discriminate between the secure and the insecure ones.  Not an

splitting the email domain into the brand name and the brand name -inc has
been done by some, but some others do not like it. Say you interact with
customers, you want to email from the brand domain not the corporate
domain, it creates confusion for the sender too.

>IMHO DMARC had better handle mailing lists properly, if at all possible.

Besides some widely used MTAs breaking DKIM signatures when forwarding,
the only other problem is mailing lists as you point. There is an
alternative to this problem is to requires employees of brands to use a
personal email address to join mailing lists. It serves two purposes.
1) p=reject can be applied, and too bad if the employee did not follow
company policy and don't have his/her email delivered,
2) one may think because the person use an email address using the brand
domain is a spokesperson for say company. Obliging people to use a
personal email address, in some large companies, could align with
restrictions on public speaking of employees

---

From: "John Levine" <[email-masked]>
Date: 8 Apr 2013 19:11:09 -0000

>to transactional mail only.

That's simply untrue.  Lots of companies use one domain for
transactions and another for individual mail.  Ask Paypal if you don't
believe me.

To look at it another way, if it's not worth your effort to change
your mail setup to separate the transactions that merit p=reject from
the live users who don't, it's not worth the effort for the rest of
the world to change their mail setup to work around you, either.

R's,
John

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 8 Apr 2013 21:32:39 +0200

On Monday, April 08, 2013 9:11 PM [GMT+1=CET], John Levine wrote:

> > For senders, it is difficult and questionable to limit an email
> > domain to transactional mail only.
> 

So if you are not Paypal-size or if you don't have Paypal-equivalent technical resources, but you still care about making your brand resilient to spoofing, tough luck!, no DMARC for you.

Anyway, I bet p=reject will get more and more adopted with the years, and I sure hope your whitelisting file is on a big enough filesystem...

Regards,

J. Gomez

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 8 Apr 2013 21:40:09 +0200

> (wrt SPF and DKIM), and I'd expect the filters to evolve over time.

Well, this list's posts (and many other lists') get to my inbox with a nice "received-spf: Pass" header, so I don't get how SPF hurts mailing list's posts. Sender-ID with PRA does have problems with mailing lists, but not SPF itself, which is fine.

Regards,

J. Gomez

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 8 Apr 2013 21:44:09 +0200

> IMHO DMARC had better handle mailing lists properly, if at all

It seems not to be possible with the currently defined scope for the DMARC proposed standard. Which is the same as saying there is no will to make it possible, i.e. there is no will to broaden DMARC's scope to provide for mailing lists.

Regards,

J. Gomez

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Apr 2013 13:42:38 -0700

On Mon, Apr 8, 2013 at 12:32 PM, J. Gomez <[email-masked]> wrote:

> So if you are not Paypal-size or if you don't have Paypal-equivalent
> technical resources, but you still care about making your brand resilient
> to spoofing, tough luck!, no DMARC for you.
>

Why is use of two subdomains for different mail streams from the same
common parent domain such a high-cost endeavour?  I do it with my own
private domain, and I'm one person with one computer.

-MSK

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 8 Apr 2013 23:01:55 +0200

> private domain, and I'm one person with one computer.  

You are not an example about low-cost technological endeavours. Your are an author of several published RFC's.

It's one thing to create a subdomain for outsourcing the email marketing operations (key word there being "outsourcing") to a third party with the in-house required expertise. It's another thing to take on yourself the convoluted approach of running two domains, one for your mailing users and another for your branded presence in the intertubes.

I bet we all in this list can do it easily. But the world is big and wide, and many people who will end up tasked with managing medium-sized business' email will not take a convoluted route at all, AND they will publish a "p=reject" DMARC policy as big as a cathedral. Pain will ensue. And then nobody will take "p=reject" as seriously as it is intended, with the final effect of watering down DMARC effectiveness in the real world --which is big, wide and hard to tame--.

Regards,

J. Gomez

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 8 Apr 2013 14:17:35 -0700

> an author of several published RFC's.

I wasn't aware those were mutually exclusive.

>
> It's one thing to create a subdomain for outsourcing the email marketing
> operations (key word there being "outsourcing") to a third party with the
> in-house required expertise. It's another thing to take on yourself the
> convoluted approach of running two domains, one for your mailing users and
> another for your branded presence in the intertubes.
>

There are existence proofs available as counterexamples.  Very large ones,
in fact.

>
> I bet we all in this list can do it easily. But the world is big and wide,
> and many people who will end up tasked with managing medium-sized business'
> email will not take a convoluted route at all, AND they will publish a
> "p=reject" DMARC policy as big as a cathedral. Pain will ensue. And then
> nobody will take "p=reject" as seriously as it is intended, with the final
> effect of watering down DMARC effectiveness in the real world --which is
> big, wide and hard to tame--.
>
>

...which brings us back to "This tool is not for everyone."

I think this topic has been beaten to death now, so I won't carry on the
thread absent new information.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 09 Apr 2013 17:32:08 +0200

> the world to change their mail setup to work around you, either.

It's not so much who does the effort as how to automate it.

There is no method (yet) whereby a receiver can ascertain that a
message really belongs to a mailing list.  Therefore it is savvy of
phished domains to preventively reserve their domain name for
transactional mail.  However, when a receiver /knows/ who operates a
given message stream, why does it still send DMARC reports to the
wrong destinations, especially in case the "sender" is paypal-inc.com
or another domain specifically designed to participate to mailing lists?

As an identifier, belonging to a mailing list is paramountly visible
to users, for it is often associated to a specific destination folder
and a subject tag.  Recognizing mailing lists, even if not (yet)
comprehensively, would adjust the balance between SPF and DKIM,
resulting in a better overall cohesion of these protocols.

Is this silly?

---

From: "John Levine" <[email-masked]>
Date: 9 Apr 2013 16:44:32 -0000

>message really belongs to a mailing list.

Of course there is.  The list can use DKIM and SPF just like anyone or
anything else.  It's not hard, my lists all do it.  There is no magic
way to mechanically determine that a domain is a "real" mailing list
but that's in FUSSP territory.

>  However, when a receiver /knows/ who operates a

Sorry, this makes no sense at all.  I know of no case where reports
from mailing list mail go to the wrong destination.  The DMARC record
for paypal-inc.com says p=none and asks for reports.  There's nothing
wrong with that, my DMARC records all say the same thing.

R's,
John

---

From: SM <[email-masked]>
Date: Tue, 09 Apr 2013 15:40:53 -0700

At 13:20 07-04-2013, J. Gomez wrote:
>The option is in General Options -> anonymous_list, set to Yes. This 
>puts the mailing list address in the RFC5322.From header in the 
>emails the mailing list software forwards to its subscribers. Do you 
>see any problem in that option?

I saw someone trying that once.  It led to a denial of service and 
several complaints.  I believe that it may be possible to object to 
such a requirement in an IETF specification.

Regards,
-sm

---

From: Franck Martin <[email-masked]>
Date: Tue, 9 Apr 2013 23:03:37 +0000

On Apr 9, 2013, at 3:40 PM, SM <[email-masked]> wrote:

> I saw someone trying that once.  It led to a denial of service and several complaints.  I believe that it may be possible to object to such a requirement in an IETF specification.
> 

The anonymous option strips a lot of things from the original email, it is a bit drastic as you won't know who posted to the list.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 10 Apr 2013 10:34:52 +0200

On Tue 09/Apr/2013 18:44:32 +0200 John Levine wrote:
> Of course there is.  The list can use DKIM and SPF just like anyone
> or anything else.  It's not hard, my lists all do it.

Yup, if spf=pass and smtp.mailfrom matches the List-Post: domain, then
the message is from a mailing list or a fake thereof.

> There is no magic way to mechanically determine that a domain is a
> "real" mailing list but that's in FUSSP territory.

Well, if the recipient repeatedly sent messages to the List-Post:
address in the past, we can conclude it is authentic.  Such criterion
would miss the very first messages after subscription, but after all
we do the same when manually setting the destination folder, don't we?

>> when a receiver /knows/ who operates a given message stream, why
>> does it still send DMARC reports to the wrong destinations,
>> especially in case the "sender" is paypal-inc.com or another
>> domain specifically designed to participate to mailing lists?
> 
> Sorry, this makes no sense at all.  I know of no case where
> reports from mailing list mail go to the wrong destination.  The
> DMARC record for paypal-inc.com says p=none and asks for reports.
> There's nothing wrong with that, my DMARC records all say the same
> thing.

The MLM is unable to publish a DMARC record for its list.  Reports go
to its subscribers instead.  Just because I subscribed to your list I
suddenly have more rights than you to know how it goes.  Isn't that
wrong?  Consider the alternative:

OLD

NEW
 1.   Either the RFC5322.From or the RFC2369.List-Post domains are
      the identifiers used for all message validation operations, as
      they are the single identifiers in the message whose upshot is
      paramountly visible to the user.

We can specify mailing list recognition to be as stringent as needed,
tunable, and possibly deploying VBR, DNSWL, and triple opt-in.  We
know we'll never be able to catch all list messages, but could do the
right thing when we see one.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Apr 2013 07:03:30 -0700

> anything else.  It's not hard, my lists all do it.  There is no magic

John, your response isn't just wrong, it dangerous.

There is nothing in the semantics of DKIM or SPF that can provide 
validation of list origination.

For example, DKIM merely asserts that the domain owner specified in d= 
has 'some' responsibility for the message; no statement about the 
validity of any content, nevermind membership or ownership of a list. 
SPF's semantics are a bit different, but no more relevant to validating 
list membership or origination.

There might be a value-add layer of convention, processing, or the like, 
that could permit such validation, but neither of these mechanisms do it 
on their own, and there are no standards for it.  And forgive me, but 
that added layer actually qualifies as magic, in the absence of formal 
standards to achieve it, since it's a receive-side heuristic.

d/
-- 
  Dave Crocker
  bbiw.net

---

From: Franck Martin <[email-masked]>
Date: Wed, 10 Apr 2013 17:07:02 +0000

> right thing when we see one.

1) Why List-Post and not List-Id or another List-Header?

2) The trouble with list-x is that it is not exposed to the end user in any way by any MUA (well may be some but I doubt it).

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 10 Apr 2013 11:00:17 -0700

> 1) Why List-Post and not List-Id or another List-Header?

None of them are suitable.  If we were to do this, I can craft a message
with a From: of [email-masked] that will pass DMARC via the List-*
header field containing whatever domain I want.

>
> 2) The trouble with list-x is that it is not exposed to the end user in
> any way by any MUA (well may be some but I doubt it).
>
>
Right.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Apr 2013 11:04:03 -0700

On 4/10/2013 11:00 AM, Murray S. Kucherawy wrote:
> any way by any MUA (well may be some but I doubt it)

So?

What's the usage that you (or whoever) envision here, that is concerned 
with end-user behavior, and why should/will it work?

(If I missed that premise in the thread, apologies; but it's worth 
reviewing carefully.)

d/
-- 
  Dave Crocker
  bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 10 Apr 2013 11:17:13 -0700

> (If I missed that premise in the thread, apologies; but it's worth
Unless I'm mistaken, Alessandro proposed solving the lists problem by
having DMARC authenticate an identifier from the List-* header field set
rather than only the From: field.  The issue, as was discussed back in the
ADSP days, is that you're then deciding this message passes based on an
identifier the end user will never see.  So I could craft a message with:

From: [email-masked]
List-Something: [email-masked]

...and then arrange that the message passes DKIM and SPF for
phish-r-us.example, and put a DMARC policy up for that domain which will
also pass.  The end user sees "[email-masked]" in their inbox,
possibly even with a gold star next to it, and would likely not be shown
the List-Something field.

Better yet, PayPal isn't notified of the problem because no DMARC report
request applies here.

-MSK

---

From: "J. Gomez" <[email-masked]>
Date: Wed, 10 Apr 2013 21:00:06 +0200

On Wednesday, April 10, 2013 1:03 AM [GMT+1=CET], Franck Martin wrote:

> > > The option is in General Options -> anonymous_list, set to Yes.
> > > This puts the mailing list address in the RFC5322.From header in
> > > the emails the mailing list software forwards to its subscribers.
> > > Do you see any problem in that option?   
> > 
> The anonymous option strips a lot of things from the original email,
> it is a bit drastic as you won't know who posted to the list. 

You can know who posted to the list if the poster added a signature at the bottom of the email body.

You further could know who posted, if the mailing list software (Mailman in this case) would had replaced the orginal email address in the RFC5322.From header with the mailing list email address but had left the descriptive portion of the RFC5322.From header mostly untouched, like thus:

 From: "John Smith" <[email-masked]>

would become:

 From: "Mailman from John Smith" <[email-masked]>

This can already be achieved with some custom filters in the MTA, but if the majority of mailing list sofware were to provide for that option be set in a non convoluted way, then the mailing list problem of DMARC would be almost a non-issue.

Regards,

J. Gomez

---

From: Franck Martin <[email-masked]>
Date: Wed, 10 Apr 2013 20:32:29 +0000

On Apr 10, 2013, at 11:04 AM, Dave Crocker <[email-masked]<mailto:[email-masked]>> wrote:

So?

What's the usage that you (or whoever) envision here, that is concerned with end-user behavior, and why should/will it work?

(If I missed that premise in the thread, apologies; but it's worth reviewing carefully.)

http://tools.ietf.org/html/draft-kucherawy-dmarc-base-00#section-3.4 point 1)

1.   The RFC5322<http://tools.ietf.org/html/rfc5322>.From domain is the identifier used for all message
        validation operations, as it is the single identifier in the
        message likely to be visible to the user.

Otherwise we could have used the Sender: header or whatever other header.

---

From: Franck Martin <[email-masked]>
Date: Wed, 10 Apr 2013 20:34:50 +0000

On Apr 10, 2013, at 11:00 AM, Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>> wrote:

None of them are suitable.  If we were to do this, I can craft a message with a From: of [email-masked]<mailto:[email-masked]> that will pass DMARC via the List-* header field containing whatever domain I want.

Yes, sure, my question is outside this alignment business and header spoofing. What header "most" describes a mailing list? Is there some convention already in place?

---

From: "John R Levine" <[email-masked]>
Date: 10 Apr 2013 18:48:45 -0400

> John, your response isn't just wrong, it dangerous.

Hi, Dave.  If you'd read the rest of my note, I think you'd find that we 
basically agree.

My point is that mailing lists can apply an SPF or DKIM identifier to 
their mail stream just like anyone else.  And they don't have to change 
anything to do it, since neither one depends on what address is in the 
From: header, or what is or isn't in the subject line, or any of the other 
stuff that people have wrongly been claiming that cause problems with 
mailing lists.

You are quite right that just an SPF or DKIM pass doesn't prove anything 
unless you have some other knowledge about the associated domain.  But we 
have ways to deal with that, whether it's per-system lists of known 
list signing domains or shared lists via VBR.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Apr 2013 15:54:59 -0700

> Hi, Dave.  If you'd read the rest of my note, I think you'd find that we

I wasn't commenting on the larger context.  It was your specific 
statement, and I think it largely undermined the larger point.

d/

-- 
  Dave Crocker
  bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 11 Apr 2013 04:07:18 -0000

>Yes, sure, my question is outside this alignment business and header spoofing. What header "most" describes a mailing list?
>Is there some convention already in place?

Before we go down this rathole, I would point out that I do not think
I have ever seen spam that pretended to be from a real mailing list.

The identfier is List-ID defined in RFC 2919, but since any bad guy
can insert any List-ID he wants, it's not useful for any sort of
security.  (It's plenty useful for mail sorting, of course.) As is
always the case, assertions about the virtue of your own mail are not
credible, so there is no way that lists can securely identify
themselves without outside help.

If you want to securely whitelist mail from lists, you need to to the
same thing you do to whitelist any other kind of mail: A) define a
convention to associate identifers with lists, e.g. DKIM signing
domains or SPF bounce domains, and B) create private or shared sets
of reputable identifiers.

Of course, since lists tend to have good reputations anyway, we
wouldn't need to worry about this if people didn't deliberately break
list mail by publishing false DMARC policy assertions and signing up
for lists.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 11 Apr 2013 10:28:37 +0200

> 1) Why List-Post and not List-Id or another List-Header?

It is not straightforward to extract the domain from List-Id.  In
addition, a system that tracks recurrent targets --for example, to
implement an auto address-book feature-- can verify whether the user
had previously written mail to such address.

> 2) The trouble with list-x is that it is not exposed to the end
> user in any way by any MUA (well may be some but I doubt it).

IME it is a no-brainer to see that a message pertains to a mailing
list, and also to discern which one.  Possibly end users are not aware
of some particular list-x, but lists tend to make sure their
subscribers can tell list traffic from the rest of their mail.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 11 Apr 2013 10:34:23 +0200

On Wed 10/Apr/2013 20:17:13 +0200 Murray S. Kucherawy wrote:
> rather than only the From: field.

Yes.  Currently, the I-D just says that mailing lists need to be
considered.  My proposal is to identify them as one out of two
possible mail-stream controllers.

> The issue, as was discussed back in the ADSP days, is that you're
> then deciding this message passes based on an identifier the end
> user will never see.  So I could craft a message with:
> 

Assuming spf=pass smtp.mailfrom=phish-r-us.example, the above is a
/hint/ that the message may belong to such mailing list.  I don't
think DMARC should specify how to make sure that's the case, albeit it
can mention some techniques (user's address-book, VBR, DNSWL,
OAuth-driven opt-in, ...)  Needless to say, receivers should err on
the safe side.  If, for any reason, the receiver is unable to
ascertain the true mailing-listness of a message, it discards the hint
and proceeds as it does currently.

> Better yet, PayPal isn't notified of the problem because no DMARC
> report request applies here.

I'm not sure on this.  Perhaps tuning could allow to determine
notifications and policies from a matrix.  Both notifications may be
important: letting PayPal know that its user subscribed using the
wrong domain, and letting the MLM know that one of its subscribers'
domains switched to a transaction-only policy.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 11 Apr 2013 06:20:52 -0700

> possible mail-stream controllers.

This can't be done with any accuracy.  If you relax DMARC processing of
messages because they appear to be lists merely because of the presence of
List-* header fields, then attackers will simply make all their mail look
like list traffic.

It feels a lot like we can make some fast progress by taking the DKIM
mailing list archives, replace ADSP with DMARC, and skip to the end.  :-)

> and proceeds as it does currently.

I would say we should go no further than we have, which is to say that
there's a way in the reports to indicate the report generator has a means
to indicate it thinks the message came from a list.  I'm wary of
recommending any heuristics at all; that's like saying to an attacker
"There's a big hole around here somewhere, if you can find it, and it might
look something like this..."

Existing implementations apply their own heuristics to relax for traffic
they think is a list.  DMARC as it stands provides for that option and
includes it as a report parameter.  I really think we should stop there.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 11 Apr 2013 15:34:06 -0000

>mailing list archives, replace ADSP with DMARC, and skip to the end.  :-)

What he said.

---

From: Franck Martin <[email-masked]>
Date: Thu, 11 Apr 2013 16:51:20 +0000

On Apr 11, 2013, at 6:20 AM, Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Apr 11, 2013 at 1:34 AM, Alessandro Vesely <[email-masked]<mailto:[email-masked]>> wrote:
Yes.  Currently, the I-D just says that mailing lists need to be
considered.  My proposal is to identify them as one out of two
possible mail-stream controllers.

This can't be done with any accuracy.  If you relax DMARC processing of messages because they appear to be lists merely because of the presence of List-* header fields, then attackers will simply make all their mail look like list traffic.

It feels a lot like we can make some fast progress by taking the DKIM mailing list archives, replace ADSP with DMARC, and skip to the end.  :-)

Except there is a slight difference, ADSP was seldom adopted at receivers. At best it became a score in spamassassin. DMARC is widely adopted.

This I think change the perspective. Remember the difference between theory and practice. In theory there should be no spam...

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 11 Apr 2013 10:19:49 -0700

On Thu, Apr 11, 2013 at 9:51 AM, Franck Martin <[email-masked]> wrote:

> Except there is a slight difference, ADSP was seldom adopted at receivers.
> At best it became a score in spamassassin. DMARC is widely adopted.
>
>  This I think change the perspective. Remember the difference between
> theory and practice. In theory there should be no spam...
>

I think all of us experienced in this space are aware of the difference.
The best solutions appear to be those that look at the problem through both
lenses, wouldn't you say?

---

From: Franck Martin <[email-masked]>
Date: Thu, 11 Apr 2013 17:33:17 +0000

On Apr 11, 2013, at 10:19 AM, Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Apr 11, 2013 at 9:51 AM, Franck Martin <[email-masked]<mailto:[email-masked]>> wrote:

I think all of us experienced in this space are aware of the difference.  The best solutions appear to be those that look at the problem through both lenses, wouldn't you say

Sure, but I was not there and the landscape has changed, and DMARC is the example of an operator group, coming to IETF to create a standard with researchers. It has been argued that IETF has lost some of its running code power since the operators do not attend much IETF anymore and prefer to meet at various nog.

Anyhow, saying we had this discussion before, read the archives, has always been what I disliked about IETF group theory.

---

From: "J. Gomez" <[email-masked]>
Date: Thu, 11 Apr 2013 22:36:15 +0200

Murray S. Kucherawy said:

> Except there is a slight difference, ADSP was seldom adopted at
> receivers. At best it became a score in spamassassin. DMARC is widely
> adopted.  

There is another difference: DMARC states as a high level requirement for itself to "Minimize false positives", see Section 3.1 https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1

Mailing list messages are a know false positive for DMARC. What is DMARC doing to minimize it, as per its own high level requirement?

We can not dismiss this issue and pretend at the same time we are "minimizing false positives", but rather "ignoring false positives".

It may be the case that DMARC cannot avoid the false positives in mailing list messages. But what is DMARC doing to "minimize them"?

This problem is far from "already discussed, read the archives for 'gizmo-foo'.

Regards,

J. Gomez

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 11 Apr 2013 16:52:25 -0700

On Thu, Apr 11, 2013 at 1:36 PM, J. Gomez <[email-masked]> wrote:

> There is another difference: DMARC states as a high level requirement for
> itself to "Minimize false positives", see Section 3.1
> https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1
>
> Mailing list messages are a know false positive for DMARC. What is DMARC
> doing to minimize it, as per its own high level requirement?
>

> We can not dismiss this issue and pretend at the same time we are
> "minimizing false positives", but rather "ignoring false positives".
>

> It may be the case that DMARC cannot avoid the false positives in mailing
> list messages. But what is DMARC doing to "minimize them"?
>

The simplest answer is: If we can't fix this problem directly, then de
facto they're already minimized; we can't make the problem smaller.

The more complex answer is that DMARC enables operators to identify lists
using its own heuristics and apply whatever special local policy handling
they want to use, for whatever value of "special" is appropriate for them.
Gmail has been held up as the prime example of this.

Another part of the answer is that DMARC doesn't target mailing lists as
part of its problem space.  Just how much phishing takes place through
mailing lists?

This problem is far from "already discussed, read the archives for
> 'gizmo-foo'.
I have no doubt that the community would be happy to act on new information
in this context, but so far there has been none.  That's when "read the
archives" becomes the right answer.  For the rest of us that have expended
huge energy going down this path before, it's better for us to save our
remaining energy for the work ahead.

It may well be the case that you weren't around for the discussions, but
that doesn't mean it hasn't been beaten until it's just a moist place in
the dirt.

Those of us who ignore history are doomed to repeat it.

-MSK

---

From: Michael Adkins <[email-masked]>
Date: Fri, 12 Apr 2013 00:46:35 +0000

DMARC minimizes false positives by providing reporting to inform domain
owners of potential false positives prior to them adopting an overly or
unnecessarily strict policy for their domain.

DMARC also provides sufficient data to judge whether stopping the amount
of actual abuse that exists, and that it can stop, is worth the damage
caused by potential false positives.

There is no assumption that every domain on the internet needs a reject
policy, nor would there be a reason for every domain on the internet to
adopt one, as not every domain on the internet has the kind of phishing
problem that DMARC attempts to solve.  Just as every personal residence
doesn't need the same level of physical security as a bank, every person
doesn't need an armed escort everywhere they go, every vehicle doesn't
need to be bulletproof, etc. because they aren't under constant threat of
being robbed/abducted/shot.

Unless someone has some aggregate reports they want to share for domains
that actually have both a large phishing problem and a large mailing list
false positive problem, its not worth spending time trying to fix.  We've
been looking and asking for a couple of years now, and still haven't found
sufficient evidence of a practical problem.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 12 Apr 2013 00:50:13 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Michael Adkins
> Sent: Thursday, April 11, 2013 8:47 PM
> Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about
> outsourcing strategies
> 
> of actual abuse that exists, and that it can stop, is worth the damage caused
> by potential false positives.
> 
> that actually have both a large phishing problem and a large mailing list false
> positive problem, its not worth spending time trying to fix.  We've been
> looking and asking for a couple of years now, and still haven't found sufficient
> evidence of a practical problem.
> 

A big +1

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 12 Apr 2013 16:41:11 +0200

On Fri 12/Apr/2013 01:52:25 +0200 Murray S. Kucherawy wrote:
>> Mailing list messages are a known false positive for DMARC. What is DMARC

My reading of the spec is not deep, but glancing at Section 11.2 I
find no step where mailing list heuristics come to play.

> part of its problem space.  Just how much phishing takes place through

Right.  But feedback might be valuable for MLM admins too.

> remaining energy for the work ahead.

Feedback and cohesive integration with SPF are new tasks, not new info.

> Those of us who ignore history are doomed to repeat it.

What I think we don't want to repeat is the transactional-mail-only
applicability restriction:

   Don't think of it as domains wishing to make strong assertions
   breaking mailing lists. Think of it as domains making strong
   assertions voluntarily excluding themselves. They value security
   more than the pleasure of your company on a list that does not
   respect their assertion with regard to their domain. They wish to
   be master of their domain. If they wish to have the pleasure of
   your company they will either have to change their assertion/
   practice or participate using another account at a more flexible
   domain.
          http://mipassoc.org/pipermail/ietf-dkim/2008q1/009196.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 12 Apr 2013 09:28:31 -0700

> find no step where mailing list heuristics come to play.

Correct.  They belong to the operators, not to the specification.

> Feedback and cohesive integration with SPF are new tasks, not new info.

I'm afraid I don't know what that means.

>           http://mipassoc.org/pipermail/ietf-dkim/2008q1/009196.html

What's changed since 2008 to change either the problem space or the
solution space?

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 13 Apr 2013 13:15:48 +0200

> Correct.  They belong to the operators, not to the specification.

If applications are coded according to specifications, what should
operators tweak in order to apply heuristics?

A challenge here is that there have to be databases of messages and
domains on which to operate.  While it sounds clumsy to maintain one
DB for DMARC, one for greylisting, one for FBL, ..., customizing SQL
statements makes applications difficult to install, so it sounds
daunting to integrate all operations on a single DB.  Neither we want
to specify APIs, since all of that stuff is going to be hosted on
existing MTAs, which dictate the architecture, the programming model,
and so forth.

Nevertheless, because of its stance at integrating DKIM, SPF, and
possibly more, DMARC has a chance to inspire implementations that take
the lead in establishing a data model that other mail filtering
utilities may want to adapt to.

> What's changed since 2008 to change either the problem space or the

The problem seems to be tackled differently, except for the policy
part.  And I see that "a mechanism for mitigating the effect of
failures of DMARC policy when a message transits a mailing list" is on
the todo list.  A most welcome change w.r.t. 2008 :-)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 13 Apr 2013 08:08:17 -0700

> operators tweak in order to apply heuristics?

Anything they want, based on local operational needs and capabilities.
DMARC hands a result to the operator; what it does with that result is its
own business.

> utilities may want to adapt to.

Sure, but none of that belongs in a protocol document.

> the todo list.  A most welcome change w.r.t. 2008 :-)

You'll have to explain how it's tackled differently in protocol, because I
can't think of what you might be referring to here.

The charter also says if that turns into a rathole that produces nothing,
it will be abandoned.

-MSK

---

From: Tim Draegen <[email-masked]>
Date: Sun, 14 Apr 2013 22:59:16 -0400

On Apr 11, 2013, at 9:20 AM, Murray S. Kucherawy <[email-masked]> wrote:
> Existing implementations apply their own heuristics to relax for traffic they think is a list.  DMARC as it stands provides for that option and includes it as a report parameter.  I really think we should stop there.

I'd like to second this view, but add my understanding.  DMARC as a specification can't fix "the mailing list problem", but has a place to drop in "hey I thought this came from a mailing list so I didn't apply your policy".  In other words, fixing the mailing list problem is not something DMARC does, but at least it can point out an area that needs work.

Alessandro Vesely mentioned something about "a mechanism for mitigating the effect of failures of DMARC policy when a message transits a mailing list", but I see this as more of a spin off effort to:

1. create a standardized way for mailing lists to identify themselves,
2. include some sort of authentication,
3. write up a specification to tie it all together.

I'm not sure the above would matter to the installed base of mailing list authors, operators, and users, though.  It would be useful for some set of people that want to the right thing but don't know what right is.  Updating all the rest might be impossible or take a long time.  In the meantime, though, receivers are getting email through mailing lists from domains that want policy applied, and yet would lead to bad end-user experiences.  Bad user experience is currently mitigated by through a local decision to apply an "override" reason of "mailing_list".  From DMARC's PoV.... done!

I wish there was an association of mailing list operators to squeeze to get the spin off effort done.  Aside from that, I agree with the expressed sentiment "need more tools and patches to fix stuff", 'cause IMO, fixing the mailing list problem is similar to "fixing the problem of unauthenticated email"... requiring a long, multi-year commitment that relies on strangers to determine success.

=- Tim

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 15 Apr 2013 13:14:27 +0200

On Sat 13/Apr/2013 17:08:17 +0200 Murray S. Kucherawy wrote:
>> Nevertheless, because of its stance at integrating DKIM, SPF,
>> and possibly more, DMARC has a chance to inspire implementations
>> that take the lead in establishing a data model that other mail
>> filtering utilities may want to adapt to.
> 

The protocol specifies the XML table used in transfer, and that may
suffice.  Outlining some of the relevant features and characteristics
of the database might be useful, just like outlining the algorithm.

>> The problem seems to be tackled differently, except for the
>> policy part.
> 
> You'll have to explain how it's tackled differently in protocol,
> because I can't think of what you might be referring to here.

The feedback protocol is about a meta-SMTP data flow.  While the
transport uses XML and SMTP, the data semantics stay somewhat parallel
to the SMTP protocol.  Someone tells a peer:  "Look, your mail is
being forwarded here by X, so what are you gonna do about that?"  In
that respect, it's rather similar to FBL, as depicted in RFC 6650.
The peer can reply:  "Oh, X?  That's legitimate, let them through."
Such replies use SPF/DKIM and DNS, and are not as synchronous and
specific as it might be desirable.  Moreover, X is identified loosely,
and has no say.

SPF and ADSP simply tried to push a new layer on top of email.  FBL
and DMARC break new ground by establishing real communication.

> The charter also says if that turns into a rathole that produces
> nothing, it will be abandoned.

It should be a joy to design a suite such that more and more protocols
can come forth in the meta-SMTP arena, neither over-constrained nor
marooned by prior design decisions.

---

From: "John Levine" <[email-masked]>
Date: 15 Apr 2013 11:33:37 -0000

>3. write up a specification to tie it all together.

Does anyone actually have trouble recognizing and delivering mail from
mailing lists?  (Real discussion lists, that is.)  Not that I've ever
heard.

This is an awful lot of mechanism to work around Franck publishing a
wrong DMARC policy and refusing to fix it.  Should DMARC rejections
become a problem for lists, I can assure you that list managers will
solve the problem by telling people with those DMARC policies to
change them, and if they don't, kicking them off either manually or
with a shim in front of the list to reject their mail.

In the one actual case I know like this, in which a wrong ADSP policy
and an overenthusiastic receiver implementation combined to bounce
people off some IETF lists, the list managers told them DON'T DO THAT
and it was fixed immediately.

Case closed, problem's gone.  Can we stop now, please?

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

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 15 Apr 2013 13:36:50 +0200

On Mon 15/Apr/2013 04:59:16 +0200 Tim Draegen wrote:
> 
> DMARC as a specification can't fix "the mailing list problem", but
> has a place to drop in "hey I thought this came from a mailing list
> so I didn't apply your policy".

That could be made a bit sharper:  "I thought" and "I knew" are quite
different from one another.

> In other words, fixing the mailing list problem is not something
> DMARC does, but at least it can point out an area that needs work.

Better yet, it can spell what a wished-for work on such problem is
expected to come out with.

> Alessandro Vesely mentioned something about "a mechanism for
> mitigating the effect of failures of DMARC policy when a message
> transits a mailing list", but I see this as more of a spin off
> effort to:
> 
> 1. create a standardized way for mailing lists to identify themselves

What's wrong with using List-Post:?

> 2. include some sort of authentication

How about SPF or, in case list posts get forwarded, DKIM?

> 3. write up a specification to tie it all together.

TBD.  With DMARC end points clearly in place, it could be a breeze.

A difficulty is that it can take quite some time --and some messages--
between "I think" and "I know".  For example, that spec might require
that the user sends a message to the List-Post address.

> I'm not sure the above would matter to the installed base of
> mailing list authors, operators, and users, though.  It would be
> useful for some set of people that want to the right thing but
> don't know what right is.  Updating all the rest might be
> impossible or take a long time.  In the meantime, though, receivers
> are getting email through mailing lists from domains that want
> policy applied, and yet would lead to bad end-user experiences.
> Bad user experience is currently mitigated by through a local
> decision to apply an "override" reason of "mailing_list".

IMHO, doing mailing lists can remain an optional part of DMARC.

> From DMARC's PoV.... done!

Yes, nearly so.  A sender may want to be able to specify a different
policy for those DMARC receivers that recognize mailing lists, rather
than simply trusting that receivers will do what best fits their
users' needs, whether they formally implement that DMARC-ML extension
or not.  Hm... Murray's argument likening l= and the evil bit seems to
apply to p= as well, doesn't it?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 15 Apr 2013 06:33:59 -0700

On Mon, Apr 15, 2013 at 4:36 AM, Alessandro Vesely <[email-masked]> wrote:

>
> Hm... Murray's argument likening l= and the evil bit seems to
>

Not exactly.  It's more like:  Who's to say DMARC can't or won't be (or
isn't being) tried by phishers?  As with DKIM and SPF, a "pass" doesn't
tell you anything about the party sending you the message, only something
about the way it got to you.  You have to decide for yourself if the
content is safe to consume.

---

From: Tim Draegen <[email-masked]>
Date: Mon, 15 Apr 2013 09:39:34 -0400

> mailing lists?  (Real discussion lists, that is.)  Not that I've ever

I totally agree; this discussion would benefit from input of folks involved in professional email list management.

=- Tim

---

From: Tim Draegen <[email-masked]>
Date: Mon, 15 Apr 2013 10:05:12 -0400

> different from one another.

Alessandro,

I think this is the crux of the issue.  Today there is not a reliable way to systematically identify mailing lists.  Michael Adkins suggested that what is needed today is a shared public repo of such info that will bring some consistency to how receivers are applying the "mailing_list" override.

I'd add that, in parallel, it would be nice if the people involved in professional email list management context got together and normalized aspects of how they generated email, made a spec out of it, and spent some cycles advocating for changes.  Because I'm not a mailing list pro and I think that "market forces" will cause changes faster than I could get done anyway, I'm happy to take a back seat on this one.

> expected to come out with.

FWIW, I agree with Murray Kucherawy's opinion that DMARC has already carved out a place for a drop in solution, and that's good enough.  Since its going to take a very long time for the mailing list problem to be fixed, might as well focus on the interface for the drop in solution, call it a day and move on.

> What's wrong with using List-Post:?

I can't speak to whether or not this is wrong or right.  I'd have to look at a whole lot of data to form an opinion on which header covers the most ground.  

> How about SPF or, in case list posts get forwarded, DKIM?

This would be ideal, for sure, but without a real mountain of data to work from or people involved in developing mailing lists, who is to say how easy it is to deploy SPF and/or DKIM in a mailing list operator context?

> TBD.  With DMARC end points clearly in place, it could be a breeze.

I agree!   Hopefully I'm clear in articulating why I don't think the proto DMARC WG is the place to get this done, though.  There simply isn't enough representation of the mailing list community.

> IMHO, doing mailing lists can remain an optional part of DMARC.

Given that DMARC is shining a light on mailing lists, it might be possible to get the mailing list community together to work something out.  Leaving this specific item as an optional WG item, though, feels like it would become an excuse for not taking action.  If we say "No, its not going to happen here", it'll force the issue to be resolved in a more effective context/group.

> apply to p= as well, doesn't it?

A little evil bit, yes.  In terms of senders specifying different policies for various ways that break DMARC, I think this is a bad idea.  Give the domain owner visibility into what is actually happening, and let the domain owner figure out how to clean up their own practices.  Otherwise, punching out holes for the various ways that break DMARC could be a slippery slope of exceptions.

=- Tim

---

From: "John R Levine" <[email-masked]>
Date: 15 Apr 2013 18:14:44 +0200

> I totally agree; this discussion would benefit from input of folks involved in professional email list management.

I'm not sure I count as a professional, but I've been running more lists 
than I can remember lists for about 30 years.

Regards,

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 15 Apr 2013 16:15:25 +0000

I'm going to top post (apologies). The bottom line is that when an (abused) sending domain publishes a p=reject DMARC policy it is taking responsibility for any discarded legitimate mail that fails to pass - for whatever reason. As soon as a validator starts trying to determine which failing mail is legitimate, it takes back responsibility for any malicious mail (that failed to validate) which reaches an enduser. 

Don't muddy the waters. Sending domains with endusers should not allow those endusers to subscribe to maillists from that domain. While validators/mailbox providors will do what they will do, they really should apply pressure to sending domains that publish p=reject b and allow their endusers to send through maillists.

Mike 

> Of Tim Draegen
> Sent: Monday, April 15, 2013 10:05 AM
> To: Alessandro Vesely
> Cc: [email-masked]
> I think this is the crux of the issue.  Today there is not a reliable way to
> systematically identify mailing lists.  Michael Adkins suggested that what is
> needed today is a shared public repo of such info that will bring some
> consistency to how receivers are applying the "mailing_list" override.
> 
> I'd add that, in parallel, it would be nice if the people involved in professional
> email list management context got together and normalized aspects of how
> they generated email, made a spec out of it, and spent some cycles
> advocating for changes.  Because I'm not a mailing list pro and I think that
> "market forces" will cause changes faster than I could get done anyway, I'm
> happy to take a back seat on this one.
> 
> >
> FWIW, I agree with Murray Kucherawy's opinion that DMARC has already
> carved out a place for a drop in solution, and that's good enough.  Since its
> going to take a very long time for the mailing list problem to be fixed, might
> as well focus on the interface for the drop in solution, call it a day and move
> on.
> 
> 
> I can't speak to whether or not this is wrong or right.  I'd have to look at a
> whole lot of data to form an opinion on which header covers the most
> ground.
> 
> This would be ideal, for sure, but without a real mountain of data to work
> from or people involved in developing mailing lists, who is to say how easy it
> is to deploy SPF and/or DKIM in a mailing list operator context?
> 
> I agree!   Hopefully I'm clear in articulating why I don't think the proto DMARC
> WG is the place to get this done, though.  There simply isn't enough
> representation of the mailing list community.
> 
> Given that DMARC is shining a light on mailing lists, it might be possible to get
> the mailing list community together to work something out.  Leaving this
> specific item as an optional WG item, though, feels like it would become an
> excuse for not taking action.  If we say "No, its not going to happen here", it'll
> force the issue to be resolved in a more effective context/group.
> 
> >
> A little evil bit, yes.  In terms of senders specifying different policies for
> various ways that break DMARC, I think this is a bad idea.  Give the domain
> owner visibility into what is actually happening, and let the domain owner
> figure out how to clean up their own practices.  Otherwise, punching out
> holes for the various ways that break DMARC could be a slippery slope of
> exceptions.
> 
> =- Tim
>

---

From: Franck Martin <[email-masked]>
Date: Mon, 15 Apr 2013 17:57:11 +0000

On Apr 15, 2013, at 6:15 PM, MH Michael Hammer (5304) <[email-masked]> wrote:

> Don't muddy the waters. Sending domains with endusers should not allow those endusers to subscribe to maillists from that domain. 

In theory it works, in practice... How do you plan to do that?

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 15 Apr 2013 18:47:01 +0000

> From: Franck Martin [mailto:[email-masked]]
> Sent: Monday, April 15, 2013 1:57 PM
> To: MH Michael Hammer (5304)
> Cc: Tim Draegen; Alessandro Vesely; [email-masked]
> > I'm going to top post (apologies). The bottom line is that when an (abused)
> sending domain publishes a p=reject DMARC policy it is taking responsibility
> for any discarded legitimate mail that fails to pass - for whatever reason. As
> soon as a validator starts trying to determine which failing mail is legitimate, it
> takes back responsibility for any malicious mail (that failed to validate) which
> reaches an enduser.
> >
> > Don't muddy the waters. Sending domains with endusers should not allow
> those endusers to subscribe to maillists from that domain.
> 

I do it now for my domains. It is called self control.

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 15 Apr 2013 23:36:54 +0200

On Monday, April 15, 2013 1:33 PM [GMT+1=CET], John Levine wrote:

> change them, and if they don't, kicking them off

Your reassurance on the future course of human action is quite dogmatic, I think.

What about this other alternative outcomes?

1. "Should DMARC rejections become a problem for lists, I can assure you that DMARC will be deemed a failed attempt at solving the authentication problem of email and not achieve wide adoption."

2. "Should DMARC rejections become a problem for lists, I can assure you that mailing lists operators will adapt their installations to make them compatible with DMARC."

3. "Should DMARC rejections become a problem for lists, I can assure you that mailing lists developers will adapt their software to make it compatible with DMARC."

4. "Should DMARC rejections become a problem for lists, I can assure you that mailing lists will become a thing of the past like gopher and FTP-through-email."

And what about a mix of 2+3+4?

> Can we stop now, please?

I prefer to hear more opinions, and not yet give up looking for some way to minimize the false positives of mailing lists with DMARC.

Regards,

J. Gomez

---

From: Josh Aberant <[email-masked]>
Date: Mon, 15 Apr 2013 14:55:18 -0700

As another stakeholder with a domain that has users and p=reject, it seems
to me that simply saying the DMARC reject shouldn't be used on domains with
users will significantly limit the potential value of DMARC to the email
community.  One of our main goals in deploying DMARC was to protect our
users.  Before we deployed p=reject we were seeing phishing attacks on our
employees (to their work and personal addresses) that were spoofing our
domain. DMARC p=reject made these mostly go away and added a lot of value.

Perhaps, a focus of DMARC should be on protecting domains with users.

And, yes, I know I'm walking into a land mine here and top posting to boot;
fire away....

Josh

http://t.co/Josh
Josh Aberant
@jaberant

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 16 Apr 2013 00:04:47 +0200

On Monday, April 15, 2013 6:15 PM [GMT+1=CET], MH Michael Hammer (5304) wrote:

> I'm going to top post (apologies). The bottom line is that when an
> (abused) sending domain publishes a p=reject DMARC policy it is
> taking responsibility for any discarded legitimate mail that fails to
> pass - for whatever reason. As soon as a validator starts trying to
> determine which failing mail is legitimate, it takes back
> responsibility for any malicious mail (that failed to validate) which
> reaches an enduser.

Nice theory. How many of the big four/five mailbox providers (Gmail, Hotmail, Yahoo, AOL...) who have originally come up privately with DMARC (in coordination with sending brand owners like Paypal, Ebay, Facebook, etc.) are following "p=reject" to the letter? I think the number is zero. Why? Because the theory is nice and clean, the real world not so much.
      
> Don't muddy the waters. Sending domains with endusers should not
> allow those endusers to subscribe to maillists from that domain.

Oh, man. Oh, man. I would vote you for President.

Regards,

J. Gomez

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 15 Apr 2013 15:16:01 -0700

On Mon, Apr 15, 2013 at 3:04 PM, J. Gomez <[email-masked]> wrote:

> Nice theory. How many of the big four/five mailbox providers (Gmail,
> Hotmail, Yahoo, AOL...) who have originally come up privately with DMARC
> (in coordination with sending brand owners like Paypal, Ebay, Facebook,
> etc.) are following "p=reject" to the letter? I think the number is zero.
> Why? Because the theory is nice and clean, the real world not so much.
>

At a minimum, Gmail and Facebook are indeed rejecting based on DMARC
failures.  I don't know about the others.

-MSK

---

From: Franck Martin <[email-masked]>
Date: Mon, 15 Apr 2013 22:22:45 +0000

On Apr 16, 2013, at 12:16 AM, Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Apr 15, 2013 at 3:04 PM, J. Gomez <[email-masked]<mailto:[email-masked]>> wrote:
Nice theory. How many of the big four/five mailbox providers (Gmail, Hotmail, Yahoo, AOL...) who have originally come up privately with DMARC (in coordination with sending brand owners like Paypal, Ebay, Facebook, etc.) are following "p=reject" to the letter? I think the number is zero. Why? Because the theory is nice and clean, the real world not so much.

At a minimum, Gmail and Facebook are indeed rejecting based on DMARC failures.  I don't know about the others.

They do have exceptions...

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 16 Apr 2013 01:10:32 +0200

Does that mean that you (who are using a Gmail.com account to subscribe to this list) are not receiving emails from Franck Martin (who is using a linkedin.com address --which is sporting a DMARC record of "p=reject"-- to subscribe to this list) addressed to this mailing list?

Hmm, but I've read you replying to him. What am I missing here?

Regards,

J. Gomez

---- Original Message ----
From: Murray S. Kucherawy
To: J. Gómez
Cc: [email-masked]
Sent: Tuesday, April 16, 2013 12:16 AM
Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not
about outsourcing strategies 

> Hotmail, Yahoo, AOL...) who have originally come up privately with
> DMARC (in coordination with sending brand owners like Paypal, Ebay,
> Facebook, etc.) are following "p=reject" to the letter? I think the
> number is zero. Why? Because the theory is nice and clean, the real
> world not so much.     
> 
>

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 15 Apr 2013 19:17:09 -0400

Perhaps that Gmail uses it's own methods to determine what it thinks is mail 
from a mailing list and then doesn't reject/quarantine those solely due to 
DMARC.

Scott K

On Tuesday, April 16, 2013 01:10:32 AM J. Gomez wrote:
> Does that mean that you (who are using a Gmail.com account to subscribe to
> this list) are not receiving emails from Franck Martin (who is using a
> linkedin.com address --which is sporting a DMARC record of "p=reject"-- to
> subscribe to this list) addressed to this mailing list?
>

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 16 Apr 2013 01:21:38 +0200

Josh Aberant wrote:

> As another stakeholder with a domain that has users and p=reject, it
> seems to me that simply saying the DMARC reject shouldn't be used on
> domains with users will significantly limit the potential value of
> DMARC to the email community.

+1

Is DMARC going to be tailor made for big-brand Senders and to hell with the rest?

Saying "p=reject" should not be used by domain owners with real users behind their domains is ... I cannot find the words ... but "very not-nice" would be about right.

If that is the state of DMARC, then DMARC needs to improve. And we know it.

Regards,

J. Gomez

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 16 Apr 2013 01:26:48 +0200

So are you saying that Gmail does not follow DMARC's "p=reject" to the letter, and just uses it as an additional input for its internal scoring system?

Then that would take Gmail out of the list of the big four/five mailbox providers who are following DMARC's "p=reject" to the letter, don't you think?

Regards,

J. Gomez

On Tuesday, April 16, 2013 1:17 AM [GMT+1=CET], Scott Kitterman wrote:

> Perhaps that Gmail uses it's own methods to determine what it thinks
> is mail from a mailing list and then doesn't reject/quarantine those
> solely due to DMARC.
> 
> Scott K
> 
> > Does that mean that you (who are using a Gmail.com account to
> > subscribe to this list) are not receiving emails from Franck Martin
> > (who is using a linkedin.com address --which is sporting a DMARC
> > record of "p=reject"-- to subscribe to this list) addressed to this
> > mailing list? 
> > 
> > Subject: Re: [dmarc-ietf] the endless mailing list silliness, was
> > not about outsourcing strategies
> > 
> > > Nice theory. How many of the big four/five mailbox providers
> > > (Gmail, Hotmail, Yahoo, AOL...) who have originally come up
> > > privately with DMARC (in coordination with sending brand owners
> > > like Paypal, Ebay, Facebook, etc.) are following "p=reject" to
> > > the letter? I think the number is zero. Why? Because the theory
> > > is nice and clean, the real world not so much.
> > > 
> > > 
> > > At a minimum, Gmail and Facebook are indeed rejecting based on
> > > DMARC failures.  I don't know about the others.
> > > 
> > > 
> > > 
> > > -MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 15 Apr 2013 19:26:23 -0400

On Tuesday, April 16, 2013 01:21:38 AM J. Gomez wrote:
> Saying "p=reject" should not be used by domain owners with real users behind
> their domains is ... I cannot find the words ... but "very not-nice" would
> be about right.
> 

I think it is what it is.  

I've read all these threads and I've yet to see any suggestion that would 
improve the situation without changing DMARC into something it is not.  It's 
not a panacea, and that's OK.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 15 Apr 2013 19:28:33 -0400

No.  I think receiver policies belong to the receiver and senders can want 
what they want, but it's up to receivers to decide.  I think it would be fair 
to say that "works fine with Gmail" isn't evidence that there's not an issue 
between DMARC and mailing lists, but RFCs aren't compliance specs that some 
internet standards inspector grades people on.  The real world is what is is 
and if they are smart enough to use their data to work around the issue, good 
for them.

Scott K

On Tuesday, April 16, 2013 01:26:48 AM J. Gomez wrote:
> So are you saying that Gmail does not follow DMARC's "p=reject" to the
> letter, and just uses it as an additional input for its internal scoring
> system?
> 
> Then that would take Gmail out of the list of the big four/five mailbox
> providers who are following DMARC's "p=reject" to the letter, don't you
> think?
> 
> Regards,
> 
> J. Gomez
>

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 15 Apr 2013 23:34:02 +0000

> Of J. Gomez
> Sent: Monday, April 15, 2013 6:05 PM
> To: [email-masked]
> > (abused) sending domain publishes a p=reject DMARC policy it is taking
> > responsibility for any discarded legitimate mail that fails to pass -
> > for whatever reason. As soon as a validator starts trying to determine
> > which failing mail is legitimate, it takes back responsibility for any
> > malicious mail (that failed to validate) which reaches an enduser.
> 
> (in coordination with sending brand owners like Paypal, Ebay, Facebook, etc.)
> are following "p=reject" to the letter? I think the number is zero. Why?
> Because the theory is nice and clean, the real world not so much.
> 

>From my perspective, if we as a (website) sending domain (we have quite a few) publish DMARC with a p=reject policy then we are asking any mailbox provider to do just that. If an enduser (generally NOT our customers) contacts us about an abusive email that would/should have been rejected if DMARC were followed, our customer service folks are instructed to let the enduser know it is fraudulent and that they wouldn't have received that email if their ISP/mailbox provider/mail admin were checking and following SPF/DKIM/DMARC. DMARC is not a magic bullet that solves all problems. It does do a good job of mitigating direct domain abuse. I've got a corpus of a billion+ (can't say how much the + equals) sent messages (with feedback) that tells me it works as described if implemented in an appropriate manner.

And yes, my organization is a participant in dmarc.org. To answer your question about mailbox providers following p=reject to the letter, to the extent that they don't, the responsibility for letting badness through to their customers is back on their shoulders. As always, mailbox providers will do what they wish (I've been waiting for John Levine to invoke King Canute) once a message gets to their systems.

> Oh, man. Oh, man. I would vote you for President.

I appreciate the vote of confidence. I'll point out that a domain with endusers CAN publish a policy of p=quarantine without causing the worst of the problems for maillist operators. That may cause problems for individuals from the domain that post to a list (presumably their posts will disappear from the perspective of some (unknown) number of list participants unless they are checking their quarantine folders. There may also be the potential for reputation damage to the sending domain in this example but I don't have enough data points to speak to that. I don't know how many times it needs to be said that p=reject is not appropriate for all sending domains. It is a strong policy statement appropriate for domains that have good control over their mailstreams.

Mike

---

From: Tim Draegen <[email-masked]>
Date: Mon, 15 Apr 2013 19:34:44 -0400

> So are you saying that Gmail does not follow DMARC's "p=reject" to the letter, and just uses it as an additional input for its internal scoring system?

This is not the case.  GMail has implemented DMARC; if they do *not* enforce policy, you'll see why under the "override" section of the corresponding XML.

HTH,
=- Tim

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 16 Apr 2013 01:37:24 +0200

Fine. And don't you think that the "l=" tag could potentially help other receivers without Google's IT department to also "work around the issue"?

On Tuesday, April 16, 2013 1:28 AM [GMT+1=CET], Scott Kitterman wrote:

> No.  I think receiver policies belong to the receiver and senders can
> want what they want, but it's up to receivers to decide.  I think it
> would be fair to say that "works fine with Gmail" isn't evidence that
> there's not an issue between DMARC and mailing lists, but RFCs aren't
> compliance specs that some internet standards inspector grades people
> on.  The real world is what is is and if they are smart enough to use
> their data to work around the issue, good for them.
> 
> Scott K
> 
> > So are you saying that Gmail does not follow DMARC's "p=reject" to
> > the letter, and just uses it as an additional input for its
> > internal scoring system?
> > 
> > Then that would take Gmail out of the list of the big four/five
> > mailbox providers who are following DMARC's "p=reject" to the
> > letter, don't you think?
> > 
> > Regards,
> > 
> > J. Gomez
> > 
> > > Perhaps that Gmail uses it's own methods to determine what it
> > > thinks is mail from a mailing list and then doesn't
> > > reject/quarantine those solely due to DMARC.
> > > 
> > > Scott K
> > > 
> > > > subscribe to this list) are not receiving emails from Franck
> > > > Martin (who is using a linkedin.com address --which is sporting
> > > > a DMARC record of "p=reject"-- to subscribe to this list)
> > > > addressed to this mailing list?
> > > > 
> > > > Subject: Re: [dmarc-ietf] the endless mailing list silliness,
> > > > was not about outsourcing strategies
> > > > 
> > > > > privately with DMARC (in coordination with sending brand
> > > > > owners like Paypal, Ebay, Facebook, etc.) are following
> > > > > "p=reject" to the letter? I think the number is zero. Why?

---

From: Elizabeth Zwicky <[email-masked]>
Date: Mon, 15 Apr 2013 23:44:05 +0000

No, because the hard part is figuring out what's a valid mailing list, not
what the sending domain thinks about mailing lists.

	Elizabeth

On 4/15/13 4:37 PM, "J. Gomez" <[email-masked]> wrote:

>Fine. And don't you think that the "l=" tag could potentially help other
>receivers without Google's IT department to also "work around the issue"?
>
>

---

From: Kurt Andersen <[email-masked]>
Date: Mon, 15 Apr 2013 23:45:43 +0000

On 2013-04-15 16:34 , "MH Michael Hammer (5304)" <[email-masked]> wrote:

>I don't know how many times it needs to be said that p=reject is not
>appropriate for all sending domains. It is a strong policy statement
>appropriate for domains that have good control over their mailstreams.

I think that it is important to point out that there is also a significant
element of business cooperation required too. If a business decides that
they want a singular domain presence, all the control in the world won't
do a bit of good. And lists which impose a domain-based membership
criterion contribute to the problem IMO (you can only join the list if you
work for example.com, and have an email address @example.com but
example.com has p=reject).

--Kurt

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 16 Apr 2013 01:49:23 +0200

If the sending domain owner publishes through DMARC a policy of "p=reject", and the receiver chooses not to enforce that policy, I think it takes a great deal of word-twisting to say that such a receiver is following "p=reject" to the letter.

Also, in DMARC "p=" is mandatory, whereas reporting is optional. To make opting out of the mandatory part of the standard be predicated on the optional part of the standard, is not what I would call "a proper thing".

This is beginnig to resemble a political debate about the fiscal cliff...

Regards,

J. Gomez

On Tuesday, April 16, 2013 1:34 AM [GMT+1=CET], Tim Draegen wrote:

> This is not the case.  GMail has implemented DMARC; if they do *not*
> enforce policy, you'll see why under the "override" section of the
> corresponding XML.  
> 
> HTH,
> =- Tim
>

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 16 Apr 2013 01:52:28 +0200

The "l=" tag is not about what the sending domain "thinks" about mailing lists, but about whether the sending domain "uses" mailing lists or not.

On Tuesday, April 16, 2013 1:44 AM [GMT+1=CET], Elizabeth Zwicky wrote:

> No, because the hard part is figuring out what's a valid mailing
> list, not what the sending domain thinks about mailing lists.
> 
> Elizabeth
> 
> > Fine. And don't you think that the "l=" tag could potentially help
> > other receivers without Google's IT department to also "work around
> > the issue"? 
> > 
> > 
> > > No.  I think receiver policies belong to the receiver and senders
> > > can want what they want, but it's up to receivers to decide.  I
> > > think it would be fair to say that "works fine with Gmail" isn't
> > > evidence that there's not an issue between DMARC and mailing
> > > lists, but RFCs aren't compliance specs that some internet
> > > standards inspector grades people on.  The real world is what is
> > > is and if they are smart enough to use their data to work around
> > > the issue, good for them. 
> > > 
> > > Scott K
> > > 
> > > > So are you saying that Gmail does not follow DMARC's "p=reject"
> > > > to the letter, and just uses it as an additional input for its
> > > > internal scoring system?
> > > > 
> > > > > > Does that mean that you (who are using a Gmail.com account
> > > > > > to subscribe to this list) are not receiving emails from
> > > > > > Franck Martin (who is using a linkedin.com address --which
> > > > > > is sporting a DMARC record of "p=reject"-- to subscribe to
> > > > > > this list) addressed to this mailing list?
> > > > > > 
> > > > > > Subject: Re: [dmarc-ietf] the endless mailing list
> > > > > > silliness, was not about outsourcing strategies
> > > > > > 
> > > > > > > Nice theory. How many of the big four/five mailbox
> > > > > > > providers (Gmail, Hotmail, Yahoo, AOL...) who have
> > > > > > > originally come up privately with DMARC (in coordination
> > > > > > > with sending brand owners like Paypal, Ebay, Facebook,
> > > > > > > etc.) are following "p=reject" to the letter? I think the
> > > > > > > number is zero. Why? Because the theory is nice and
> > > > > > > clean, the real world not so much.
> > > > > > > 
> > > > > > > 
> > > > > > > At a minimum, Gmail and Facebook are indeed rejecting
> > > > > > > based on DMARC failures.  I don't know about the others.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > -MSK
> > > > >

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 15 Apr 2013 23:53:13 +0000

> Of Kurt Andersen
> Sent: Monday, April 15, 2013 7:46 PM
> To: [email-masked]
> I think that it is important to point out that there is also a significant element
> of business cooperation required too. If a business decides that they want a
> singular domain presence, all the control in the world won't do a bit of good.
> And lists which impose a domain-based membership criterion contribute to
> the problem IMO (you can only join the list if you work for example.com, and
> have an email address @example.com but example.com has p=reject).
> 
> --Kurt
> 

So the choice of ice cream offered is chocolate or vanilla. The domain owner wants Neapolitan. That is not on the menu. If a business makes the business decision that they want a singular domain presence AND they choose to publish p=reject then it becomes a case of:

Domain: "Dr., it hurts when I do that."
Dr.:  "Then don't do that".

Mike

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 16 Apr 2013 02:00:17 +0200

On Tuesday, April 16, 2013 1:53 AM [GMT+1=CET], MH Michael Hammer (5304) wrote:

> > > I don't know how many times it needs to be said that p=reject is
> > > not appropriate for all sending domains. It is a strong policy
> > > statement appropriate for domains that have good control over
> > > their mailstreams. 
> > 
> > I think that it is important to point out that there is also a
> > significant element of business cooperation required too. If a
> > business decides that they want a singular domain presence, all the
> > control in the world won't do a bit of good. And lists which impose
> > a domain-based membership criterion contribute to 
> So the choice of ice cream offered is chocolate or vanilla. The
> domain owner wants Neapolitan. That is not on the menu. If a business
> makes the business decision that they want a singular domain presence
> AND they choose to publish p=reject then it becomes a case of:   
> 

I say: please defend why is it bad adding Napolitan ice cream to the menu? Specially now that the ice cream shop has yet to order the supplies to the distributor?

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 15 Apr 2013 20:00:10 -0400

No.  There are only three ways we can solve this problen:

1.  Sender keeps a list of lists its users send to
2. Receiver keeps a list of lists its users receive from
3. Arbitrary mediators claim they are a list.

#1/2 are not scalable. 
#3 Makes DMARC useless and inspires the evil bit jokes. 

Scott K

"J. Gomez" <[email-masked]> wrote:

>other receivers without Google's IT department to also "work around the
>issue"?
>
>

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 16 Apr 2013 02:13:51 +0200

On Tuesday, April 16, 2013 1:34 AM [GMT+1=CET], MH Michael Hammer (5304) wrote:

> To answer
> your question about mailbox providers following p=reject to the
> letter, to the extent that they don't, the responsibility for letting
> badness through to their customers is back on their shoulders.

It takes two to tango. You can theorize who is to blame and you can idealize who is the guilty party. The reality is senders what their legitimate email reaching its destination as much a receivers what to receive email that is relevant to them.

A false DMARC positive because of the intersection of "p=reject" and a mailing list is as much a problem for the sending party as for the receiving party.

I think we should focus on how to minimize the false positives, not on distributing guilt.

> I appreciate the vote of confidence. I'll point out that a domain
> with endusers CAN publish a policy of p=quarantine without causing
> the worst of the problems for maillist operators.

Ok, so you are saying real-world average-users of DMARC have to choose: either they shield themselves from phishing with "p=reject", or they make live palatable for their users behind their domain.

Well, I say we need to think more about this problem.

Regards,

J. Gomez

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 16 Apr 2013 02:20:22 +0200

The "l=no" tag means in practical terms that point 2 is no longer required for all email coming from domains with such a tag. How does not that make life easier for the receivers when receiving email from those domains?

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 16 Apr 2013 00:20:02 +0000

> Sent: Monday, April 15, 2013 8:00 PM
> To: [email-masked]
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of Kurt Andersen
> > > On 2013-04-15 16:34 , "MH Michael Hammer (5304)"
> <[email-masked]>
> > > wrote:
> > >
> > > a domain-based membership criterion contribute to the problem IMO
> > > (you can only join the list if you work for example.com, and have an
> > > email address @example.com but example.com has p=reject).
> > >
> > > --Kurt
> > >
> >
> > So the choice of ice cream offered is chocolate or vanilla. The domain
> > owner wants Neapolitan. That is not on the menu. If a business makes
> > the business decision that they want a singular domain presence
> I say: please defend why is it bad adding Napolitan ice cream to the menu?
> Specially now that the ice cream shop has yet to order the supplies to the
> distributor?

There is nothing wrong with adding it to the menu assuming it is available. The issue is that in Kurt's example, someone is demanding two things which are in conflict. This is clearly a case of cognitive dissonance.

---

From: Tim Draegen <[email-masked]>
Date: Mon, 15 Apr 2013 20:23:32 -0400

> Well, I say we need to think more about this problem.

From my perspective, a lot of people have been pretty clear about how and why solving the mailing list problem is not something that can be done through adding words to DMARC the technical specification.

There is no easy fix, just real work to do along any number of tracks.

-= Tim

---

From: Tim Draegen <[email-masked]>
Date: Mon, 15 Apr 2013 20:28:11 -0400

> The "l=no" tag means in practical terms that point 2 is no longer required for all email coming from domains with such a tag. How does not that make life easier for the receivers when receiving ema…

There is no "l=no" tag.  It's been less than a day since people replied to this suggestion with some pretty good reasons why it doesn't work.

To summarize: receivers aren't looking for a "l=no" directive to reject email.  They're looking to work-around the mailing list problem so that end-users remain calm while anti-phishing technology is installed.

HTH,
=- Tim

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 16 Apr 2013 02:38:21 +0200

On Tuesday, April 16, 2013 2:23 AM [GMT+1=CET], Tim Draegen wrote:

> From my perspective, a lot of people have been pretty clear about how
> and why solving the mailing list problem is not something that can be
> done through adding words to DMARC the technical specification.  
> 

Yes, it is clear DMARC cannot _solve_ the mailing list false positives. We are already past that.

We are now trying to _minimize_ those false positives.

One side says: it's totally up to the receiver's 'smarts' and local policies, a.k.a. the receiver's voodoo.

I say: the above, but lets help the receiver's voodoo with a little optional positive info from the sender, thus the "l=" tag.

A third side says: there is not really a problem, senders should just choose between using either "p=reject" or using mailing lists altogether.

Ok, now lets try to detach ourselves from any particular patisanship and ask ourselves this: "what would be the best course of action for a healthy and universal email ecosystem as a whole, suitable for both big and small participants?".

Yeah, not an easy question, I know.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 16 Apr 2013 00:44:07 +0000

> Sent: Monday, April 15, 2013 8:14 PM
> To: [email-masked]
> It takes two to tango. You can theorize who is to blame and you can idealize
> who is the guilty party. The reality is senders what their legitimate email
> reaching its destination as much a receivers what to receive email that is
> relevant to them.
> 

If you look at the history of SPF and DKIM, many mailbox providers would consider them but not act on assertions authoritatively because they couldn't/wouldn't trust them. The reality with DMARC (in my experience) is that it works very well for transactional mail, marketing mail and yes, even for domains with individual users as long as they avoid maillists. Individual users send mail at the discretion of the domain owner/administrator. We encounter very low rates of false positives for our mail sent under a DMARC policy of p=reject.

> A false DMARC positive because of the intersection of "p=reject" and a
> mailing list is as much a problem for the sending party as for the receiving
> party.
> 

Then don't do that.

> I think we should focus on how to minimize the false positives, not on

So far I haven't seen anything proposed that accomplishes your ask without opening opportunities for abuse.

> > I appreciate the vote of confidence. I'll point out that a domain with
> > endusers CAN publish a policy of p=quarantine without causing the
> > worst of the problems for maillist operators.
> 
> Ok, so you are saying real-world average-users of DMARC have to choose:
> either they shield themselves from phishing with "p=reject", or they make
> live palatable for their users behind their domain.
> 

That is basically what it comes down to. If you or anyone else comes up with something that doesn't open up DMARC for abuse I would gladly support it. We chose to re-architect our systems and limit individual accounts to only those that directly support the websites (customer service, security, etc). we use an unrelated domain for our corporate mail. If your domain is subject to enough abuse then you will make a choice. If your domain is not that heavily abused and you want your endusers to be able to participate in maillists you will make another choice. The ask I'm hearing is in the realm of someone wanting to publish an SPF record of +all and then expressing unhappiness when someone sends mail claiming to be them from some random host.

> Well, I say we need to think more about this problem.

The me part of we is focused on thinking about other problems. The proposed working group charter allows for extensions so my suggestion would be to come up with a detailed proposal. Find some other senders plus some receivers and maillist operators that buy into your proposal and engage a proof of concept exercise.

Mike

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 16 Apr 2013 02:46:25 +0200

On Tuesday, April 16, 2013 2:28 AM [GMT+1=CET], Tim Draegen wrote:

> > The "l=no" tag means in practical terms that point 2 is no longer
> > required for all email coming from domains with such a tag. How
> > does not that make life easier for the receivers when receiving
> > email from those domains?   
> 
> There is no "l=no" tag.  It's been less than a day since people
> replied to this suggestion with some pretty good reasons why it
> doesn't work.  
> 
> To summarize: receivers aren't looking for a "l=no" directive to
> reject email.  They're looking to work-around the mailing list
> problem so that end-users remain calm while anti-phishing technology
> is installed.   

There is a proposed "l=" tag. You can think of the "l=" tag as implicitly adjectivized as "proposed" whenever you read about it until you may happen to see it inside the DMARC draft and/or standard, if at all.

To answer you last paragraph above, the "l=" tag is all about helping receivers better "work-around the mailing list problem". So I think the "l=" tag is totally in line with what you say receivers are looking for.

Regards,

J. Gomez

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 16 Apr 2013 01:01:17 +0000

> Sent: Monday, April 15, 2013 8:38 PM
> To: [email-masked]
> I say: the above, but lets help the receiver's voodoo with a little optional
> positive info from the sender, thus the "l=" tag.
> 
So what do you do when malicious individuals look for domains publishing your proposed l= tag and start sending mail from purported maillists (or even through legitimate lists) claiming to be from those domains? You may (and I emphasize may) have reduced false positives to some unknown extent but you have encouraged a vector of abuse.

> A third side says: there is not really a problem, senders should just choose
> between using either "p=reject" or using mailing lists altogether.
> 

This is no different than saying SPF records ending in -all are not suitable for domains that don't know where they emit mail from. It is no different than saying an ADSP (DKIM) policy of discardable is not suitable for domains that don't properly DKIM sign all their mail.

> Ok, now lets try to detach ourselves from any particular patisanship and ask
> ourselves this: "what would be the best course of action for a healthy and
> universal email ecosystem as a whole, suitable for both big and small
> participants?".
> 

That's easy - throw out SMTP and start from scratch....... never mind. Not all implementations are suitable for all participants in the sense you are asking. The issues involved are NOT a function of size. Gmail is not currently in a position to implement a p=reject policy. It is the nature of their mail streams and policy choices. The same goes for some other very large senders.

Mike

---

From: Mike Jones <[email-masked]>
Date: Mon, 15 Apr 2013 18:29:41 -0700

> To answer you last paragraph above, the "l=" tag is all about helping receivers better "work-around the mailing list problem". So I think the "l=" tag is totally in line with what you say receivers…

We collect and aggregate DMARC data for a lot of domains, many of which have reject policies currently in place.  I thought I would take a quick look into current practices in identifying forwarders & mailing lists and overriding DMARC policies. 

In the last 30 days we saw:
Slightly over 1400 unique domains & sub-domains that had at least one DMARC reject disposition applied.  
A total of over 170 million messages were reported with a DMARC reject disposition
Of these, 28.5% had a policy override reported 
The most common override reason was "forwarded" accounting for roughly 60%.  After that "local policy" accounted for 27% of overrides and "mailing list" was indicated on about 12% of the overrides.  

More than one DMARC receiver currently utilizes the policy override, but not all do.  

On a per domain basis, the percentage of messages with a reject disposition and which have a policy override applied varies quite largely.  Below see the distribution of # of domains across buckets of "% of failing messages with an override" for the top 100 domains by total messages rejects.  As you can seen half of the domains fall into the first 2 buckets with less than 10% of the reject policies overridden.  But 3 domains had more than 75% of their reject policies overridden.  

My conclusions from the data and my experience working with the DMARC receivers so far is that they are using the flexibility DMARC provides to override reject policies when they believe it is appropriate for their users.  

Thanks,
Mike

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 15 Apr 2013 21:53:03 -0400

On Tuesday, April 16, 2013 02:46:25 AM J. Gomez wrote:
> There is a proposed "l=" tag. You can think of the "l=" tag as implicitly
> adjectivized as "proposed" whenever you read about it until you may happen
> to see it inside the DMARC draft and/or standard, if at all.
> 
> To answer you last paragraph above, the "l=" tag is all about helping
> receivers better "work-around the mailing list problem". So I think the
> "l=" tag is totally in line with what you say receivers are looking for.

Unless they can usefully process different values of your l= tag differently, 
then it doesn't help.  

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 15 Apr 2013 21:01:52 -0700

> from a mailing list and then doesn't reject/quarantine those solely due to
Precisely what I've been saying, yes.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 15 Apr 2013 21:08:19 -0700

> letter, and just uses it as an additional input for its internal scoring

No; Gmail does follow DMARC's "p=reject" to the letter, yet doesn't
necessarily enact rejection specifically because the draft allows for local
overrides when warranted.

> providers who are following DMARC's "p=reject" to the letter, don't you

No, that's not what I think.  Do read the last paragraph of Section 5, and
try again.

I think this thread has become circular.  Absent new information or
consensus to change something, we need to drop it.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 16 Apr 2013 10:08:22 -0000

>what the sending domain thinks about mailing lists.

It's not just mailing lists.  The number of ways that individual users
can send legitimate mail that doesn't come from their home mail server
is endless.

Here are two well known examples:

* Users forward their mail to Y! or gmail, and send mail from there
  using their home address

* Web site send to a friend features

Listing them all and defending against bad guys sneaking into the list
is hopeless.  (It reduces to the general whitelist problem.)

If someone wants to "protect" their users against phishing using
DMARC, they're also going to protect them against doing lots of the
stuff that makes mail useful to those users and cause damage to the
services those users try and fail to use.  Take your pick.

R's,
John

---

From: Tim Draegen <[email-masked]>
Date: Tue, 16 Apr 2013 11:29:44 -0400

> The most common override reason was "forwarded" accounting for roughly 60%.  After that "local policy" accounted for 27% of overrides and "mailing list" was indicated on about 12% of the overrides.…

Interesting!  Perhaps we should lump together "forwarded" and "mailing list" and think about this space as simply "transitive trust".

=- Tim

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 16 Apr 2013 23:33:25 +0200

> services those users try and fail to use.  Take your pick.

Well, it seems LinkedIn.com is not taking any of the picks you provide, for it seems they are opting to follow their own merry way (publishing both "p=reject" and subscribing to mailing lists), and so far it's working just fine and dandy for them.

The fact that there are several people subscribed to this list whose mailbox is hosted at receivers already using DMARC to filter incoming email, and yet they ALL are reading Franck's posts to this list, is proof that the two picks you presented are not the whole panoply of available picks.

This obviously is a vulnerability in DMARC. How long until, given this reality of implementation of DMARC on the field, spamers and phishers begin dressing their emails with headers (invisible to the user!) to make them look like mailing list posts, in order to bypass phished brand owners' "p=reject" policies and therefore land their phishing emails on the users' mailboxes?

All that voodoo of local policies and heuristics that receivers are wheel-reinventing separately to work around this problem, will be wasted time the very moment phishing operators become aware of this vulnerability of DMARC (*) and exploit it. And because there won't be any possibility of setting a "l=no" tag in DMARC records in DNS, this vulnerability will be there forever, or until mailing lists die as we know them now.

(*) The vulnerability is not in the letter of the standard, of course; but all indications point to the FACT that this vulnerability will be there in the implementations of DMARC in the field.

Regards,

J. Gomez

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 16 Apr 2013 23:47:49 +0200

Murray S. Kucherawy wrote:

> necessarily enact rejection specifically because the draft allows for
> local overrides when warranted.  

Excuse me, but you are playing with words here. Gmail may be following the DMARC's standard to the letter, but certainly Gmail is not following the sender's "p=reject" policy to the letter. "Reject" is a verb, a verb is an action, the action is "to reject" not "to think about rejecting" or some other thing. Was that mail rejected? No. Ergo the sender's DMARC policy of "p=reject" is not being followed to the letter.

Don't you see a problem here? How widespread do you thing that this not following DMARC's "p=reject" to the letter could become when DMARC is (if at all) massively deployed in the field? Don't you see here a potential vulnerability in DMARC, not in the letter of the standard but on how it may be implemented in the field, therefore opening a door for phishing email to sneak past "p=reject"?

Regards,

J. Gomez

---

From: "J. Gomez" <[email-masked]>
Date: Wed, 17 Apr 2013 00:05:07 +0200

On Tuesday, April 16, 2013 3:53 AM [GMT+1=CET], Scott Kitterman wrote:

> > > > The "l=no" tag means in practical terms that point 2 is no
> > > > longer required for all email coming from domains with such a
> > > > tag. How does not that make life easier for the receivers when
> > > > receiving email from those domains?
> > > 
> > > problem so that end-users remain calm while anti-phishing
> > > technology is installed.
> > 
> > There is a proposed "l=" tag. You can think of the "l=" tag as
> > implicitly adjectivized as "proposed" whenever you read about it
> > until you may happen to see it inside the DMARC draft and/or
> > standard, if at all. 
> > 
> > To answer you last paragraph above, the "l=" tag is all about
> > helping receivers better "work-around the mailing list problem". So
> > I think the "l=" tag is totally in line with what you say receivers
> > are looking for. 
> 
> Unless they can usefully process different values of your l= tag
> differently, then it doesn't help.

And the receivers indeed can process different values of the "l=" tag differently.

For example:

"v=DMARC1; p=reject; pct=100; l=no" could be seen by the receiver as: "Just reject, do not try at all to outsmart the sender applying local heuristics/policies searching for mailing list activity after DMARC processing."

"v=DMARC1; p=reject; pct=100; l=dunno" could be seen by the receiver as: "Reject, unless post-processing after DMARC finds clear traces of mailing list activity".

"v=DMARC1; p=reject; pct=100; l=yes" could be seen by the receiver as: "Reject, unles post-processing after DMARC finds plausible traces of mailing list activity and also bring in our local whitelist of known mailing lists".

Oh, that evil bit! How convenient could it be!

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 16 Apr 2013 15:39:23 -0700

On Tue, Apr 16, 2013 at 2:47 PM, J. Gomez <[email-masked]> wrote:

> Excuse me, but you are playing with words here. Gmail may be following the
> DMARC's standard to the letter, but certainly Gmail is not following the
> sender's "p=reject" policy to the letter. "Reject" is a verb, a verb is an
> action, the action is "to reject" not "to think about rejecting" or some
> other thing. Was that mail rejected? No. Ergo the sender's DMARC policy of
> "p=reject" is not being followed to the letter.
>

I'm not playing with anything, I'm reading the same spec you keep quoting
at me.  I don't know what "to the letter" even means given the spec does
two things very explicitly:

(a) Section 5, final paragraph, makes it clear that the receiver's local
policy always overrules what the sender's published policy is in the "p="
portion of the DNS record.

(b) Section 6.2, in particular the part that talks about "p=", uses
language like "requests" and "wishes".  This was not an accident.  Exactly
how is Gmail or anyone being non-compliant if they do something else?  The
"p=" is nothing more than a request.  It cannot be a demand, nor can you
claim (given that language) that a receiver is being non-compliant by
ignoring that request if it has other information it decides is better
signal about what to do with the message?

So yes, Gmail is following DMARC to the letter by doing whatever it wants
with the information it has.  Any other claim amounts to a selective
reading of the draft.

> Don't you see a problem here?

Yes, but it's not what you think it is.  The problem is that you appear to
be trying to morph DMARC into the silver bullet that it isn't, nor was it
meant to be.  To me, that means we might need to add more pedagogy up front
to make that point clear, not that either the spec or the implementations
got it wrong.

> How widespread do you thing that this not following DMARC's "p=reject" to
> the letter could become when DMARC is (if at all) massively deployed in the
> field?

Hopefully every receiver also gets what those sections actually say and not
your ultra-strict interpretation.

> Don't you see here a potential vulnerability in DMARC, not in the letter
> of the standard but on how it may be implemented in the field, therefore
> opening a door for phishing email to sneak past "p=reject"?
>

No.

-MSK

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 17 Apr 2013 02:58:16 +0000

>From: [email-masked] [mailto:[email-masked]] On Behalf Of Josh Aberant
>Sent: Monday, April 15, 2013 5:55 PM
>Cc: [email-masked]
>Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies
>
>As another stakeholder with a domain that has users and p=reject, it seems to me that simply saying the DMARC reject shouldn't be used on domains with users will significantly >limit the potential value of DMARC to the email community.  One of our main goals in deploying DMARC was to protect our users.  Before we deployed p=reject we were seeing >phishing attacks on our employees (to their work and personal addresses) that were spoofing our domain. DMARC p=reject made these mostly go away and added a lot of value.
>And, yes, I know I'm walking into a land mine here and top posting to boot; fire away....
>
>Josh 

Josh,

Domains with users CAN implement p=reject as long as the users avoid maillists from that domain and it is made clear to users that there are some situations where mail may be lost. The nice thing is that by publishing a policy of p=none, a domain owner willing to do a little analysis can determine roughly how big of an issue it is for them. There are tradeoffs that need to be considered.

So, it can be done but there are constraints to work within.

Mike

---

From: "John Levine" <[email-masked]>
Date: 17 Apr 2013 10:39:18 -0000

>Domains with users CAN implement p=reject as long as the users avoid maillists from that domain
>and it is made clear to users that there are some situations where mail may be lost.

Right, and they can't forward mail to gmail or use send to a friend,
or any of a zillion other things that human users do.  It's pretty
clear that publishing a dmarc policy other than p=none will make your
users' mail work worse.

Let's sure the DMARC documents says people SHOULD call their IT
departments and complain when their list subscriptions are cancelled
and stuff they send from gmail mysteriously disappears.

Perhaps we could try and think more clearly about providing service to
actual mail users and less about hypothetical spoofing attacks on
people who are not plausible spoof targets.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 17 Apr 2013 12:11:30 +0000

> Of John Levine
> Sent: Wednesday, April 17, 2013 6:39 AM
> To: [email-masked]
> Subject: Re: [dmarc-ietf] making mail not work for your users, was the
> endless mailing list silliness
> 
> >Domains with users CAN implement p=reject as long as the users avoid
> >maillists from that domain and it is made clear to users that there are some
> situations where mail may be lost.
> 
> Right, and they can't forward mail to gmail or use send to a friend, or any of a
> zillion other things that human users do.  It's pretty clear that publishing a
> dmarc policy other than p=none will make your users' mail work worse.
> 

Perhaps I should have been more specific and added the constraint that I was thinking of b-to-b domains as an example in crafting my comments. As far as "send to a friend", this may or may not be problematic - Many of the sites I work with do "send to a friend" without any DMARC problems whatsoever.

> departments and complain when their list subscriptions are cancelled and
> stuff they send from gmail mysteriously disappears.
> 

I absolutely agree with you that people should complain if their IT department doesn't communicate planned changes (of any sort). And if someone complains to their IT department about stuff they are sending from gmail (purporting to come from their company domain) there might be a different discussion about company security policies and AUP.

> Perhaps we could try and think more clearly about providing service to actual
> mail users and less about hypothetical spoofing attacks on people who are
> not plausible spoof targets.
> 

This is about risk management. Many want to publish p=reject when there is no significant risk. Others who have a real risk are not willing to architect their systems/policies/mailstreams to appropriately leverage DMARC to mitigate that risk without creating problems for others. 

Mike

---

From: "John R Levine" <[email-masked]>
Date: 17 Apr 2013 14:15:11 +0200

> Perhaps I should have been more specific and added the constraint that I 
> was thinking of b-to-b domains as an example in crafting my comments. As 
> far as "send to a friend", this may or may not be problematic - Many of 
> the sites I work with do "send to a friend" without any DMARC problems 
> whatsoever.

That's because very few domains with live users currently publish a DMARC 
policy.  If people use a return address with a p=none or p=quarantine 
policy, poof, DMARC will keep the message from being delivered.

> This is about risk management. Many want to publish p=reject when there 
> is no significant risk. Others who have a real risk are not willing to 
> architect their systems/policies/mailstreams to appropriately leverage 
> DMARC to mitigate that risk without creating problems for others.

Entirely agree.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 17 Apr 2013 12:22:20 +0000

> From: John R Levine [mailto:[email-masked]]
> Sent: Wednesday, April 17, 2013 8:15 AM
> Subject: RE: [dmarc-ietf] making mail not work for your users, was the
> > Perhaps I should have been more specific and added the constraint that
> > I was thinking of b-to-b domains as an example in crafting my
> > comments. As far as "send to a friend", this may or may not be
> > problematic - Many of the sites I work with do "send to a friend"
> > without any DMARC problems whatsoever.
> 
> policy.  If people use a return address with a p=none or p=quarantine policy,
> poof, DMARC will keep the message from being delivered.
> 

Care to bet on that with regard to my sites? It's all in how the "send to a friend" site architects things.

> > This is about risk management. Many want to publish p=reject when
> > there is no significant risk. Others who have a real risk are not
> > willing to architect their systems/policies/mailstreams to
> > appropriately leverage DMARC to mitigate that risk without creating
> problems for others.
> 
> Entirely agree.
>

---

From: "J. Gomez" <[email-masked]>
Date: Wed, 17 Apr 2013 22:55:45 +0200

> people who are not plausible spoof targets.

It's pretty clear by now that DMARC is not about protecting actual email users, but about protecting big brands from email spoofing their brand.

Regards,

J. Gomez

---

From: John Sweet <[email-masked]>
Date: Wed, 17 Apr 2013 14:20:37 -0700

On Wed, Apr 17, 2013 at 1:55 PM, J. Gomez <[email-masked]> wrote:

> It's pretty clear by now that DMARC is not about protecting actual email
> users, but about protecting big brands from email spoofing their brand.
>

... except, of course, that when I get a phishing mail purporting to be
from my bank, and I respond thinking it's them, and criminals gain access
to my accounts because of it, it's not the bank that takes it in the
shorts. It's me, the little guy.

When I get yet another newspaper article forwarded by my mother, using the
paper's website's "Send to a Friend" link, I actually don't particularly
care if it's someone pretending to be her.  Likewise, when I see your posts
here on dmarc-ietf, I really don't care if it's you or someone pretending
to be you. Some applications of email just aren't desperately in need of
authentication.

If my mother writes me personally saying she's stuck in London without her
passport and needs me to wire her $1500 immediately, well, that's another
matter. But she's unlikely to do that through a mailing list.

J

-- 
"Science is like an inoculation against charlatans who would have you
believe whatever it is they tell you." (Neil DeGrasse Tyson)

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 17 Apr 2013 22:00:21 +0000

> Sent: Wednesday, April 17, 2013 4:56 PM
> To: [email-masked]

Having seen the damage done to individuals clicking on those phishing or malware emails purporting to be from banks and other big brands I strongly disagree with your statement which appears somewhat dismissive. The further we can push the bad guys from being able to create and deliver fake emails that look like communications from organizations, the better off we all are. It doesn't necessarily solve the issue of fake emails claiming to be from individuals at other types of domains but then individuals aren't likely to have a legitimate reason to ask you to log into "your" bank portal and provide credentials.

Using strong email authentication, malicious site takedowns and other approaches we have significantly reduced the risk for people who receive email that claims to be from our sites. Do we benefit? Of course we do. But failing to recognize the benefit to individual people is extremely short sighted. I would argue that organizations not making these sorts of efforts are doing a disservice to their customers and the community at large.

The fact that SPF/DKIM/DMARC do not address every problem under the sun does not mean that these authentication approaches aren't useful in protecting endusers.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 17 Apr 2013 15:40:52 -0700

> shorts. It's me, the little guy.

It's both, really.  It happens to the end user to the tune of what they
have in the bank, and it happens to the bank to the tune of what their
insurers have to cover in the aggregate for fraud claims.  Those are
relatively painful numbers to both parties.

> matter. But she's unlikely to do that through a mailing list.

+1 to all of that.

-MSK

---

From: Michael Adkins <[email-masked]>
Date: Wed, 17 Apr 2013 23:21:41 +0000

If your goal is to profit from identity theft by impersonating someone
else, your best bet is to cast the widest net possible by impersonating
the largest organizations that hold user authentication credentials.
DMARC is an open version of products that were designed to combat that
problem because it was/is the biggest phishing problem.  If there was no
value to actual email users, it is unlikely that the largest mailbox
providers on the internet would have participated in it's creation or
deployed it since there would have been nothing in it for them.  If we
would like to hear about the value to end users, we could probably get one
of them to share some high level data about it.

---

From: Terry Zink <[email-masked]>
Date: Thu, 18 Apr 2013 00:12:15 +0000

Likewise, when I see your posts here on dmarc-ietf, I really don't care if it's you or someone pretending to be you. Some applications of email just aren't desperately in need of authentication.
<<<

So, are we basically on a discussion list that is in charge of moving forward the DMARC standard, but the discussion list itself can't authenticate with DMARC?

-- Terry

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 18 Apr 2013 13:44:46 +0200

On Thu 18/Apr/2013 00:00:21 +0200 MH Michael Hammer (5304) wrote:
>> From: [email-masked] On Behalf Of J. Gomez
>> 
> Having seen the damage done to individuals clicking on those
> phishing or malware emails purporting to be from banks and other
> big brands I strongly disagree with your statement which appears
> somewhat dismissive.

Spoofing a bank's brand can damage the users who become victims of
phishing.  That's what we aim at protecting from, however we call it.

> I would argue that organizations not making these sorts of efforts
> are doing a disservice to their customers and the community at
> large.

If courts argued like that, then phishing victims would be able to
claim damages from non-compliant banks.  Possibly, victims would need
to prove that scam messages would have been blocked if the bank had
complied.  Therefore they had better choose receivers who enable DMARC
rejection.

That way, we can extend the argument that mailing list posters need a
different email address:  We'd need a different email address even for
lurking.  However, experience with RFC 6109 shows that even if people
is compelled by law to get certified email accounts, they tend to
forget them and use the ones that work instead.[1]

[1] http://www.digitpa.gov.it/pec/statistichepec (in Italian)

---

From: Barry Leiba <[email-masked]>
Date: Thu, 18 Apr 2013 11:08:04 -0400

> So, are we basically on a discussion list that is in charge of moving forward the DMARC
> standard, but the discussion list itself can't authenticate with DMARC?

It wouldn't be the first time.  People didn't post to <[email-masked]>
using S/MIME, and <[email-masked]> does not use SMTP over TLS to send
its messages.  Do you really think this is a problem?

Barry, just participating

---

From: Terry Zink <[email-masked]>
Date: Thu, 18 Apr 2013 16:28:09 +0000

>> So, are we basically on a discussion list that is in charge of moving 
>> forward the DMARC standard, but the discussion list itself can't authenticate with DMARC?

> It wouldn't be the first time.  People didn't post to <[email-masked]> using S/MIME, and 
> <[email-masked]> does not use SMTP over TLS to send its messages.  Do you really think this 
> is a problem?

No, I don't.

The DMARC specification has a section that lists items that are out of scope (section 3.5). Section 2.2 explicitly that DMARC does not attempt to solve problems related to use of Cousin Domains or abuse of the RFC5322.From "display name."

Seems like mailing lists like this are also out-of-scope.

-- Terry

---

From: "Jones, Steven M" <[email-masked]>
Date: Thu, 18 Apr 2013 19:13:31 +0000

On Wednesday, April 17, 2013 1:56 PM, J. Gomez wrote:
> It's pretty clear by now that DMARC is not about protecting actual email users, but
> about protecting big brands from email spoofing their brand.

I must disagree. While we want to prevent our brands/domains from being used to exploit consumers, we also want to help prevent our customers from being exploited in general. If that weren't the case we would have been happy using proprietary services rather than promoting an open standard.

We share our customers with many thousands of other organizations. Whether a customer is phished through abuse of our brand, or Facebook, or the local tax assessor doesn't really matter if it leads to their BofA accounts being drained and their PII stolen. While the larger brands have been a primary focus because they are most often successfully exploited and have an incentive to make disruptive changes, I have always felt that it was equally important that DMARC be available to protect any domain that needs it, of whatever size or scope.

Yes there are some direct expenses when BofA makes good on fraud losses, and because of our scale it's not a small number. But it pales in comparison to the loss of customer confidence and reputational damage, not to mention the outright loss of customers, plus the loss of the Internet as a way to interact with our customers. I don't have survey data handy, but I'm pretty sure 4 out of 5 consumers don't miss having to go into physical bank locations between 10AM and 3PM, Tuesday through Thursday except random obscure holidays, every time they wanted to do something...

DMARC is not a panacea, so it does not solve certain issues with mailing lists, any more than it solves display names or cousin domains. But it does provide a solution to a very real set of problems, and it can evolve in future.

--Steve.

Steven M Jones
Messaging Strategy
STI End User Computing
Bank of America; Concord, California

----------------------------------------------------------------------
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended recipient, please delete this message.

---

From: "J. Gomez" <[email-masked]>
Date: Thu, 18 Apr 2013 23:16:48 +0200

Murray S. Kucherawy wrote:

> > How widespread do you thing that this not following DMARC's
> > "p=reject" to the letter could become when DMARC is (if at all)
> > massively deployed in the field?  
> 
> Hopefully every receiver also gets what those sections actually say
> and not your ultra-strict interpretation. 
> 
> > Don't you see here a potential vulnerability in DMARC, not in the
> > letter of the standard but on how it may be implemented in the field,
> > therefore opening a door for phishing email to sneak past "p=reject"?
> 
> No.

Time will tell.

Right now, you can get email that fails DMARC to land into the user's mailbox in Gmail just by inserting the right amount of list-related fake headers...

Regards,

J. Gomez

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 19 Apr 2013 14:37:55 +0000

> Of Alessandro Vesely
> Sent: Thursday, April 18, 2013 7:45 AM
> To: [email-masked]
> >> It's pretty clear by now that DMARC is not about protecting actual
> >> email users, but about protecting big brands from email spoofing their
> brand.
> >
> > Having seen the damage done to individuals clicking on those phishing
> > or malware emails purporting to be from banks and other big brands I
> > strongly disagree with your statement which appears somewhat
> > dismissive.
> 
> > I would argue that organizations not making these sorts of efforts are
> > doing a disservice to their customers and the community at large.
> 
> If courts argued like that, then phishing victims would be able to claim
> damages from non-compliant banks.  Possibly, victims would need to prove
> that scam messages would have been blocked if the bank had complied.
> Therefore they had better choose receivers who enable DMARC rejection.
> 

Ethics != law. 

> lurking.  However, experience with RFC 6109 shows that even if people is
> compelled by law to get certified email accounts, they tend to forget them
> and use the ones that work instead.[1]
>

---

From: John Sweet <[email-masked]>
Date: Sat, 20 Apr 2013 12:53:54 -0700

On Wed, Apr 17, 2013 at 5:12 PM, Terry Zink <[email-masked]>wrote:

> >>>
> Likewise, when I see your posts here on dmarc-ietf, I really don't care if
> it's you or someone pretending to be you. Some applications of email just
> aren't desperately in need of authentication.
> <<<
>

I have no problem with mailing lists representing posts as being from the
list, not from the original posters. I didn't subscribe to the individual
posters, I subscribed to the list. I do expect the list to authenticate
posters (especially since only certain addresses are allowed to post). I
don't expect the list to transport their authentication info through to me
to verify for myself.

Once I can tell the message is verifiably from [email-masked], I'm done
caring. I don't consider the mailing list convention of preserving the
From: of the original poster to be a useful or necessary feature. Digests
don't do it: they're always from the list.

If this means you can't post to some mailing lists from an address
protected by a DMARC reject policy, or that some mailing lists only send
digests, or always rewrite the From:, or even only rewrite the From: when
they can see the poster has a reject policy in effect, I'm fine with that.

If a list materially misrepresents the contents of a post, or identity of a
poster (same thing really), it will rapidly lose all its posters and
subscribers and cease to exist. This isn't a current scam profile, and I
can't see it ever becoming one.  This isn't a problem that needs solving,
let alone by DMARC.

J

---

From: "John Levine" <[email-masked]>
Date: 20 Apr 2013 20:17:12 -0000

>caring.

It's got an ietf.org DKIM signature.  What more do you need?

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 20 Apr 2013 13:51:21 -0700

> It's got an ietf.org DKIM signature.  What more do you need?

ietf.org signs all sorts of stuff, including messages that turn out to 
be spam.

d/

-- 
  Dave Crocker
  bbiw.net

---

From: "John R Levine" <[email-masked]>
Date: 20 Apr 2013 17:01:48 -0400

> ietf.org signs all sorts of stuff, including messages that turn out to be 
> spam.

True.  It's got an ietf.org signature on a List-ID header, which is 
somewhat more specific to this list.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Sat, 20 Apr 2013 14:11:52 -0700

> somewhat more specific to this list.

that sounds suspicious like claiming that including it in the hash 
equates to validating it contents...

anyhow, the spam that the ietf sends goes /through/ its lists...

d/

-- 
  Dave Crocker
  bbiw.net

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Sat, 20 Apr 2013 23:47:29 +0200

> anyhow, the spam that the ietf sends goes /through/ its lists...

well, nobody claims that DKIM-signed messages never can be spam. The 
keyword here again is: reputation. If ietf.org is redistributing+signing 
too much spam messages this will have impact on the reputation of 
d=ietf.org...

/rolf