Subject: [dmarc-ietf] Fwd: RFC 7489 on Domain-based Message Authentication, Reporting, and Conformance (DMARC)

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Mar 2015 13:08:27 -0700

FYI:

---------- Forwarded message ----------
From: <[email-masked]>
Date: Wed, Mar 18, 2015 at 1:04 PM
Subject: RFC 7489 on Domain-based Message Authentication, Reporting, and
Conformance (DMARC)
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 7489

        Title:      Domain-based Message Authentication, Reporting, and
                    Conformance (DMARC)
        Author:     M. Kucherawy, Ed.,
                    E. Zwicky, Ed.
        Status:     Informational
        Stream:     Independent
        Date:       March 2015
        Mailbox:    [email-masked],
                    [email-masked]
        Pages:      73
        Characters: 162707
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-kucherawy-dmarc-base-12.txt

        URL:        https://www.rfc-editor.org/info/rfc7489

Domain-based Message Authentication, Reporting, and Conformance
(DMARC) is a scalable mechanism by which a mail-originating
organization can express domain-level policies and preferences for
message validation, disposition, and reporting, that a mail-receiving
organization can use to improve mail handling.

Originators of Internet Mail need to be able to associate reliable
and authenticated domain identifiers with messages, communicate
policies about messages that use those identifiers, and report about
mail using those identifiers.  These abilities have several benefits:
Receivers can provide feedback to Domain Owners about the use of
their domains; this feedback can provide valuable insight about the
management of internal operations and the presence of external domain
name abuse.

DMARC does not produce or encourage elevated delivery privilege of
authenticated email.  DMARC is a mechanism for policy distribution
that enables increasingly strict handling of messages that fail
authentication checks, ranging from no action, through altered
delivery, up to message rejection.

INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

---

From: Tim Draegen <[email-masked]>
Date: Wed, 18 Mar 2015 16:19:59 -0400

Hi Murray & Elizabeth, thanks for wrestling this through the process.  The Working Group can now adopt this as input.

/goes off to figure out which buttons need to be pushed
=- Tim

> On Mar 18, 2015, at 4:08 PM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> FYI:
> 
> From: <[email-masked] <mailto:[email-masked]>>
> Subject: RFC 7489 on Domain-based Message Authentication, Reporting, and Conformance (DMARC)
> To: [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>, [email-masked] <mailto:[email-masked]>
> 
> 
>         Mailbox:    [email-masked] <mailto:[email-masked]>,
>                     [email-masked] <mailto:[email-masked]>
>         Pages:      73
>         Characters: 162707
>         URL:        https://www.rfc-editor.org/info/rfc7489 <https://www.rfc-editor.org/info/rfc7489>
> 
>   https://www.ietf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/mailman/listinfo/ietf-announce>
>   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist <https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist>
> 
> For searching the RFC series, see https://www.rfc-editor.org/search <https://www.rfc-editor.org/search>
> For downloading RFCs, see https://www.rfc-editor.org/rfc.html <https://www.rfc-editor.org/rfc.html>
> 
> author of the RFC in question, or to [email-masked] <mailto:[email-masked]>.  Unless
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Mar 2015 13:30:30 -0700

On Wed, Mar 18, 2015 at 1:19 PM, Tim Draegen <[email-masked]> wrote:

> Hi Murray & Elizabeth, thanks for wrestling this through the process.  The
> Working Group can now adopt this as input.
>
I have to resubmit it as "draft-ietf-dmarc-base" and then you guys have to
approve it in, assuming you still want me to act as editor.  Did you want
to do that right away or wait until the earlier milestones have been met?

-MSK

---

From: Tim Draegen <[email-masked]>
Date: Wed, 18 Mar 2015 17:01:15 -0400

> On Mar 18, 2015, at 4:30 PM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> On Wed, Mar 18, 2015 at 1:19 PM, Tim Draegen <[email-masked] <mailto:[email-masked]>> wrote:
> I have to resubmit it as "draft-ietf-dmarc-base" and then you guys have to approve it in, assuming you still want me to act as editor.  Did you want to do that right away or wait until the earlier milestones have been met?

You might as well do it right away.  The earlier milestones are not coupled to the DMARC base draft.

=- Tim

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Mar 2015 15:40:30 -0700

Dear DMARC WG,

Now that RFC7489 has been published, there remains several 
unresolved problems this WG is charted to resolve, primarily--
1. Addressing the issues with indirect mail flows

These are reviewed by
https://tools.ietf.org/html/draft-dmarc-interoperability-00

https://tools.ietf.org/html/draft-otis-dmarc-author-align-01
was written to highlight possible solutions.

John Levine's recommendation that mailing-list operators take on 
the costly burden of having their participants change their providers 
is not practical.  Based upon the almost complete lack of interest of
bulk email providers at promoting a solution, it seems the path
forward is to define a new non-aligned header field able to retain the 
author role information, otherwise the From is likely overwritten as 
the only practical means of ensuring message acceptance in the face of 
provider DMARC (ab)use.

By defining a new header field, this should reduce disparity in where to 
find the author role than that caused by current ad hoc solutions.  Such 
a definition would also better avoid downgrading 'reject' into 
'quarantine'.

Any thoughts?

Regards,
Douglas Otis

---

From: Terry Zink <[email-masked]>
Date: Wed, 18 Mar 2015 23:38:30 +0000

> Based upon the almost complete lack of interest of

If bulk email providers have shown no interest in promoting a solution, why do we think they'd latch onto this new non-aligned header field as a solution?

-- Terry

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Douglas Otis
Sent: Wednesday, March 18, 2015 3:41 PM
To: Murray S. Kucherawy
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

Dear DMARC WG,

These are reviewed by

Any thoughts?

Regards,
Douglas Otis

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Mar 2015 11:41:07 -0700

> On Mar 18, 2015, at 4:38 PM, Terry Zink <[email-masked]> wrote:
> 
> If bulk email providers have shown no interest in promoting a solution, why
> do we think they'd latch onto this new non-aligned header field as a solution?
> 
> -- Terry

Dear Terry,

Thank you for your comment.  This WG seems indicative of most bulk sender's
who often ask "How is DMARC's disruption of legitimate messaging a problem 
for me?" They are clearly not interested in preserving the social and civic 
benefits derived from open exchanges enabled by email affected by the DMARC 
(ab)use occurring against millions of users.

This is further evidenced by the current DMARC scheme that offers no strategy 
for preserving the role of Author for messages handled by various third-parties.  
Those operating a mailing-list are being forced to either reject a large 
percentage of their users, or replace the From header with what was likely to 
have been the Sender header field.  The identity of the Author becomes 
undefined and might be moved to the Reply-to or perhaps x-original-from header 
fields.

Unless DMARC defines a fallback policy which allows alignment with that of 
the Sender header field, the role of Author is placed at risk.  In such 
cases, defining a special "Non-Aligned From" header field could help better 
define where this role might be found in a message without it being
automatically displayed.  This header field might even offer provisions for
the tagging often found in the Subject header field.

Perhaps call this new header field "Author".  Since few MUAs are likely to 
display this header, only those that make extensive use of email that depends
on third-party services are likely to ensure it being displayed.  An
approach that would not require cooperation from Bulk senders, while still
allowing forums a means to track a history of who said what. 

Regards,
Douglas Otis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Mar 2015 12:52:49 -0700

On Wed, Mar 18, 2015 at 4:38 PM, Terry Zink <[email-masked]>
wrote:

>
> If bulk email providers have shown no interest in promoting a solution,
> why do we think they'd latch onto this new non-aligned header field as a
> solution?
>
>
+1.  And since the From field is the only one users really see every time,
I'm not sure that declaring and supporting yet another
no-seriously-this-is-the-author field would be of benefit.  Rather, I think
it would just confuse things further.

The closest thing I can see is considering use of Sender somehow, since
there are even a few MUAs that do pay vague attention to it.  But that's
extremely hand-wavy to start with.

-MSK

---

From: "J. Gomez" <[email-masked]>
Date: Fri, 20 Mar 2015 21:56:15 +0100

> 1. Addressing the issues with indirect mail flows

Why is it better for DMARC to be adapted to indirect email flows, instead of indirect email flows to be adapted to DMARC?

What does provide more value to end users at large: indirect email flows to be kept old-style, or the extra notch of trustworthiness that DMARC alignment provides?

How big is the volume of DMARC-problematic indirect email flows, compared to the general volume of email which can readily benefit from DMARC?

Regards,

Regards,
J.Gomez

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 20 Mar 2015 17:49:01 -0400

On Friday, March 20, 2015 09:56:15 PM J. Gomez wrote:
> Why is it better for DMARC to be adapted to indirect email flows, instead of
> indirect email flows to be adapted to DMARC?
> 
> What does provide more value to end users at large: indirect email flows to
> be kept old-style, or the extra notch of trustworthiness that DMARC
> alignment provides?
> 
> How big is the volume of DMARC-problematic indirect email flows, compared to
> the general volume of email which can readily benefit from DMARC?

I think it's fair to say it varies a lot.  I took a look at the reports for my 
personal domain for roughly the last week.   All the mail was SPF pass, DKIM 
signed, and aligned went sent.  Here's the numbers (keep in mind that 
receivers are likely to count multiple recipients of mailing list messages as 
multiple message - I don't actually write 5,000 emails a week):

Total: 5,029
My Serverss: 6
Mail List/Forwarded SPF and DKIM fail: 5,022
Mail List DKIM pass: 1

In my case (since a lot of my mail is via email lists) it's essentially all of 
it.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Mar 2015 15:19:29 -0700

On Fri, Mar 20, 2015 at 1:56 PM, J. Gomez <[email-masked]> wrote:

> Why is it better for DMARC to be adapted to indirect email flows, instead
> of indirect email flows to be adapted to DMARC?
>
> What does provide more value to end users at large: indirect email flows
> to be kept old-style, or the extra notch of trustworthiness that DMARC
> alignment provides?
>
> How big is the volume of DMARC-problematic indirect email flows, compared
> to the general volume of email which can readily benefit from DMARC?
>

I'm pretty sure volumes are not the problem as much as the painful side
effects, most notably unsubscription of uninvolved users from mailing lists
when someone protected by DMARC posts to the list.  (See Section 5.2 of
RFC6377, which describes the same problem in the context of ADSP.  RFC7372
might help with this, if and when it ever gets widely implemented.)

My own view is that we should pursue whichever of the two avenues is the
lower-hanging fruit.  The problem at the moment is that it's not at all
clear to me which of the two that is.  We have among us implementers of
both MLM packages and DKIM/SPF packages and standards, so at least the
right people are "in the room".  There are, however, substantial barriers
in both directions.

We definitely have our work cut out for us.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Fri, 20 Mar 2015 16:40:30 -0700

On 3/19/2015 12:52 PM, Murray S. Kucherawy wrote:
> And since the From field is the only one users really see every time,
> no-seriously-this-is-the-author field would be of benefit. 

I'd like to try to get us to phrase this differently.

In particular, it does not matter what user's 'see'.  The information is
processed by a filtering agent, independent of the user.

     So what matters is that the From: field domain is the
     only field certain to be provided by the author.

Everything about DMARC derives from the certainty of that presence.

For a mechanism, like DKIM, that seeks a collaborative relationship
between origin and destination, there does not need to be certainty that
the information will be present.  There merely needs to be certainty
that /if/ it is present, it is valid.

DMARC is not like that.  DMARC is an effort to look for spoofing.  This
means that bad actors will attempt to place the trust-related
information (like a domain name) into the message, but without
authorization.

So, what domain name is certain to be in the message, other than the one
in the From field?

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 21 Mar 2015 14:27:33 +0900

J. Gomez writes:

 > Why is it better for DMARC to be adapted to indirect email flows,
 > instead of indirect email flows to be adapted to DMARC?

Because they *can't* be adapted by definition.  DMARC "p=reject"
prohibits indirect mail, and "p=quarantine" sends it to the spam
bucket.

Or perhaps you're thinking of the same thing that Douglas is.  To him,
I suppose "adapting DMARC" includes third-party authorization
mechanisms.  I consider those actually to be "adapting DMARC" because
they require participation of the first party.

YMMV, you may consider that "adapting indirect mail" because often it
will be initiated by the 3rd party applying for authorization.
However, several proposals have been made for limited authorization by
mailbox owners who can't actually change the DMARC policies of the
authorizing domain.  These also require participation of the
authorizing domain but not necessarily the third party.  So I prefer
our interpretation that TPA is "adapting DMARC".

Steve

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 21 Mar 2015 14:37:09 +0900

> Everything about DMARC derives from the certainty of that presence.

Except for the very existence of DMARC, which was primarily motivated
by phishing and "recommended-by-friend spam", which depend on what the
recipient sees, and the recipient's association of trustworthiness
with the message's apparent author.

So no, the filtering agents don't really matter to DMARC as far as I
can see.  What matters to DMARC is when inauthentic From addresses get
past the filtering agents.  At that point DMARC intervenes and
(optionally at the domain owner's request) interdicts inauthentic
addresses in From:.

Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 21 Mar 2015 00:23:07 -0700

>      only field certain to be provided by the author.

Isn't it important that this information is also the most likely to be
presented to the end user as the author of the content that's also shown to
the user? Why do you claim it doesn't matter?

There would be a lot less incentive to be concerned about From: alignment
if that were not the case.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sat, 21 Mar 2015 05:55:09 -0700

On 3/21/2015 12:23 AM, Murray S. Kucherawy wrote:
> presented to the end user as the author of the content that's also shown
> to the user? Why do you claim it doesn't matter?
> 
> There would be a lot less incentive to be concerned about From:
> alignment if that were not the case.

It's important to distinguish between the initial reason people were
motivated to work on DMARC, versus what DMARC does.

     Users do not process DMARC.

     When talking about a protocol, talk about the entities
     that process it.

From: happens to be the only place that always has the presence of a
domain associated with the origin. And note that without DMARC, these
days users typically don't see the domain.  In other words, it isn't
presented to the user. This inconvenient fact is ignored or dismissed
every time someone touts the user's role in DMARC.

d/

---

From: Hector Santos <[email-masked]>
Date: Sat, 21 Mar 2015 10:36:44 -0400

As a long time total mail system product(s) developer, at this point, 
IMV, we have a marketing problem.

We did have technical solutions laid out with 3rd party authorization 
concerns.   However, it hasn't been "sold enough"  and if even if you 
do work it, you have to champion it.  One can't write documents nor 
work on ideas while still believing it won't work. If you (the 
authors) don't believe it, no one else will -- the bottom line.

Just consider that DMARC has a problem that all the previous POLICY 
FRAMEWORKS long had. So how could DMARC replaced ADSP as the "Super 
ADSP" when ADSP was abandoned by the key DKIM people within the IETF? 
  It does the same thing, same problem?  How was that possible?

Marketing.

DMARC did have the REPORTING part that we intentionally left out in 
coming up with SSP/ADSP.  The view was it would eventually could be 
abused and most certainly it would be become a high overhead redundant 
reporting feature -- can't be reporting forever.

Thats the one thing I believe I underestimated when I strongly 
supported and implemented the previous DKIM policy ideas such as SSP 
and ADSP and also my I-D DSAP (DKIM Signature Authorization Protocol) 
where some of the initial MLM interfacing ideas were written down.

Overall, you got to have a solid protocol first that makes sense 
independent of any mail component that touches mail.   I believe we 
had something with DKIM + POLICY but it requires you to change the the 
MLM software or its frontend interface to follow the POLICY concept. 
Until that happens, nothing is going to change.

-- 
HLS

On 3/20/2015 4:56 PM, J. Gomez wrote:
> On Wednesday, March 18, 2015 11:40 PM [GMT+1=VET], Douglas Otis wrote:
>
>> Dear DMARC WG,
>>

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sun, 22 Mar 2015 01:41:04 +0900

Dave Crocker writes:

 > domain associated with the origin.

Except it doesn't always have a domain associated with the originating
MTA, and there's nothing in RFC 5322 that says it does.  RFC 5322 says
you shouldn't put an address in From that you don't have the right to
use, not that it must be aligned with the domain of the injecting MTA.

So I must be missing something, because it seems to me that you've got
the DMARC From alignment tail wagging the whole RFC 5322 dog here.

 > And note that without DMARC, these days users typically don't see
 > the domain.  In other words, it isn't presented to the user. This
 > inconvenient fact is ignored or dismissed every time someone touts
 > the user's role in DMARC.

What's so inconvenient about it?  I'm apparently missing something,
but I don't see how the fact that the domain sometimes isn't presented
is particularly inconvenient for the position that user behavior
matters.  Specifically, in many cases failure to present the domain as
a character string doesn't mean that the displayed identity isn't
associated with the address in some way such as presentation of an
avatar looked up by address, or in a tool-tip.  There may be other
subtle channels by which the address can influence user behavior
without being displayed as a character string.  And sometimes it is
presented as a string.

Note that these "subtle channels" are MUA functions, and thus outside
the purview of current MTA-based DMARC implementations.  I think it's
quite valid to emphasize the user's role here.

---

From: "John Levine" <[email-masked]>
Date: 21 Mar 2015 21:31:39 -0000

>> to the general volume of email which can readily benefit from DMARC?

The numbers I've seen say that the volume of mail that DMARC screws up
is fairly low, but it is very high value. 

Personally, I would be happy never to get any more mail from my bank,
if it meant that my mailing lists would work again.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 21 Mar 2015 17:45:57 -0700

On 3/21/2015 9:41 AM, Stephen J. Turnbull wrote:
> MTA,

Well, I said 'origin' and not 'originator' but yeah, I should have
thought of a more generic term.  I meant not to invoke 'originator' and
meant mean "something around the creation of the message, such as
author, originator, gateway mta, whatever..."[*]

>  and there's nothing in RFC 5322 that says it does.  RFC 5322 says

Thanks for the refresher.

> the DMARC From alignment tail wagging the whole RFC 5322 dog here.

No idea what you mean.

> What's so inconvenient about it? 

Folks tend to promote DMARC's choice of From field due to the fact that
it's presented to the end-user, as if the end-user will behave
differently with DMARC active.  The end-user won't.  They mostly don't
see the domain name, and it mostly doesn't matter when they do.

On the other hand, the fact that the From field is the only domain name
reliably associated with content creation and that receiving filtering
engines can do an assessment of validity when DMARC validates, is
extremely meaningful.  But there is no 'user' in the handling equation
for DMARC.

 There may be other
> quite valid to emphasize the user's role here.

Subtle channels is a fun idea.  Unfortunately there is an infinite
number of fun ideas.

Perhaps you can cite some empirical research evidence of its relevance
to this topic?

d/

[*]  However note that the essence of DMARC is a /very/ tight coupling
between content author's domain owner and the originator.

---

From: "J. Gomez" <[email-masked]>
Date: Sun, 22 Mar 2015 16:06:15 +0100

> authors) don't believe it, no one else will -- the bottom line.

I consider that any "3rd party authorization scheme" for DMARC will fail --not to fail technically, but to fail be implemented in the real world-- if it happens to need, to be workable, the nuanced and labour-intensive participation of the sender's domain Owner.

Consider Yahoo and OAL reckless usage of "p=reject". Why would they suddenly be any less reckless and choose to take into account any "3rd party authorization scheme" for DMARC? Do we have any hint from big ESPs currently using "p=reject" that they are willing to take into account any "3rd party authorization scheme" for DMARC? If not, we have the risk to taking the effort to design a great "3rd party authorization scheme" for DMARC which ultimately will fail to be taken into account in any significant way in the real world.

So, Hector, no matter how good "marketing" is, it is going to be next to impossible to sell something which is nuanced and labour-intensive, and at the same time provides little --perceived-- reward to the agents tasked with implementing it and keeping it current and running in a well-oiled fashion.

Regards,
J.Gomez

---

From: "J. Gomez" <[email-masked]>
Date: Sun, 22 Mar 2015 16:25:26 +0100

On Saturday, March 21, 2015 10:31 PM [GMT+1=CET], John Levine wrote:

> > > How big is the volume of DMARC-problematic indirect email flows,
> > > compared to the general volume of email which can readily benefit
> > > from DMARC? 
> 

But do you think the general email-using population will be happy to miss authentic email from eBay, Amazon, Paypal and American Airlines, just to get email from some mailing list(s) delivered to their inbox?

Also, your mailing list would work again in a heartbeat, in a DMARC-world, if you just configured them to put the original Header-From into the "description" of a new Header-From, like:

From: "Pedro Antunez" <[email-masked]>  ==>  From: "Pedro Antunez [email-masked]" <[email-masked]>

It's about time that MLM software that modifies the in-flight message, rendering its DKIM signature invalid, takes ownership as Author of the new modified message they are resending.

Regards,
J.Gomez

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 22 Mar 2015 10:18:05 -0700

On Sun, Mar 22, 2015 at 8:06 AM, J. Gomez <[email-masked]> wrote:

> I consider that any "3rd party authorization scheme" for DMARC will fail
> --not to fail technically, but to fail be implemented in the real world--
> if it happens to need, to be workable, the nuanced and labour-intensive
> participation of the sender's domain Owner.
>

I have to agree.  I've seen nothing since the advent of SPF to convince me
otherwise.  Several have been proposed and none have seen anything more
than trivial uptake, even when written down as experimental RFCs or made
freely available in open source code.

An argument has been made that they got no uptake because they are flawed,
but I think that's myopic; the ones that are available are not set in stone
and thus could be easily mutated into something more palatable if there was
actual interest.  That nobody has proposed anything of the form "We would
implement third-party scheme X if only it had Y done to it" tells me that
the general idea is a dead end, not that the specific proposals on the
table are faulty.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 23 Mar 2015 03:39:33 +0900

Dave Crocker writes:

 > Folks tend to promote DMARC's choice of From field due to the fact
 > that it's presented to the end-user, as if the end-user will behave
 > differently with DMARC active.  The end-user won't.

I haven't noticed anybody advocating that.  The claim is that the user
behavior changes with the identity in the From field, and whether they
trust its authenticity.

People do make a lot of fuss about the display of the domain (eg,
DMARC itself deprecates From munging that puts the address in a
comment or the display name in From).  While that isn't the whole
story (can't be, since often the domain isn't displayed by the MUA),
the address in From is an important part of the correspondent's
identity, and users tend to trust that it's authentic and the MUA is
using the "right" one for each correspondent.  I think it's reasonable
to suppose that the identity in From does affect user behavior.

 > But there is no 'user' in the handling equation for DMARC.

Is that all you are trying to say?  That seems tautological to me,
since DMARC is a software system that operates (usually) in the MTA.

I took you to mean that the relationship between the purported
identity in From, based on the address in that field, and the user's
behavior is irrelevant to specification of DMARC and related
protocols.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 22 Mar 2015 13:51:46 -0500

> behavior changes with the identity in the From field, and whether they

Right.

And this is claimed in the absence of supporting research and to the
contrary of usability experience.

> since DMARC is a software system that operates (usually) in the MTA.

Heh.

> behavior is irrelevant to specification of DMARC and related

I didn't say that, but I'll say it now, too.  (Ignoring the underying
truth that users get tricked, which provides the motivation for worrying
about spoofing.)

d/

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 23 Mar 2015 04:14:48 +0900

J. Gomez writes:

 > It's about time that MLM software that modifies the in-flight
 > message, rendering its DKIM signature invalid, takes ownership as
 > Author of the new modified message they are resending.

Not going to happen.  GNU Mailman list owners have had the option
since November 2013, many were forced to use it in the Great DMARC
Fiasco of last April, and they hate it.  So we are not going to force
it on anybody.

I can't speak for other MLM maintainers, but I suspect many have had
similar experiences and probably all have some list owners who hate
the idea of "taking ownership" -- they'll probably make it optional
too.

Many of us hate the idea in principle, anyway.  In our interpretation
of RFC 5322 the modifications the MLM makes do not create a new
message any more than adding Received fields does (and of course there
are very good reasons to keep the Message-Id).

---

From: "John Levine" <[email-masked]>
Date: 22 Mar 2015 20:25:00 -0000

>But do you think the general email-using population will be happy to miss
>authentic email from eBay, Amazon, Paypal and American Airlines, just to get
>email from some mailing list(s) delivered to their inbox?

My impression is that most users put a very low value on commercial
bulk mail.  I'm not aware of any statistics available to the public.

>Also, your mailing list would work again in a heartbeat, in a DMARC-world, if
>you just configured them to put the original Header-From into the "description"
>of a new Header-From, like:

We are aware of the various kludges to circumvent DMARC breakage.  We
have a whole wiki about them at
http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail

Rehashing them here and asserting that they are solutions rather than
kludges would not be productive.

R's,
John

---

From: "J. Gomez" <[email-masked]>
Date: Sun, 22 Mar 2015 23:37:22 +0100

On Sunday, March 22, 2015 9:25 PM [GMT+1=CET], John Levine wrote:

> > But do you think the general email-using population will be happy
> > to miss authentic email from eBay, Amazon, Paypal and American
> > Airlines, just to get email from some mailing list(s) delivered to
> > their inbox? 
> 

Authentic email from eBay, Amazon, Paypal and American Airlines may not be "commercial bulk email." Instead, it can be email confiming the success of important transactions, account break-in attempts, or notifying changes in schedules, etc., and therefore be of very high value to end-users.

> > Also, your mailing list would work again in a heartbeat, in a
> > DMARC-world, if you just configured them to put the original
> > Header-From into the "description" of a new Header-From, like:
> 

You say that as if a solution that works but you don't like is not a solution but a kludge. Internet Email is built on a pile of kludges after kludges. It just wasn't designed to live as long as it has.

Why is this kludge of a solution worst that the kludge of closing down open email relays in the past? The disappearance of open email relays surely affected badly several legitimate use cases of email...

Regards,
J.Gomez

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 23 Mar 2015 14:38:34 +0900

> truth that users get tricked, which provides the motivation for worrying

Ignoring motivation was appropriate for Milestone 1, which was
concerned with ensuring a lack of ambiguity in RFC 7489, which has a
well-defined set of requirements.

But we are now looking at "next steps", ie, a new set of requirements,
because implementing the RFC 7489 requirements turned out to be
insufficient to enable many use cases people participating in this WG
care about, and to have some rather nasty side effects in combination
with preexisting systems.  I think discussion of motivation and agent
(not limited to mail recipients) behavior is exactly what is needed at
this stage, even if it's rather speculative and not founded in formal
user interface research.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 23 Mar 2015 15:02:41 +0900

> > > Airlines, just to get email from some mailing list(s) delivered to
 
I don't see why enabling mailing lists to continue their traditional
practice of adding tags to Subject and footers to the message body
would cause any problems whatsoever for authentic direct mail from the
businesses you mention.

 > You say that as if a solution that works but you don't like is not
 > a solution but a kludge.

It is.  A *solution* is a practice or product that satisfies user
requirements.  If there's only one such user, OK, you can say "tough
on you."  However, *many* mailing list users wish to have the author's
address in "From" where it will be automatically and naturally used
for reply-to-author in almost all MUAs.  As far as I know there is no
configuration of From and Reply-To that satisfies this requirement in
all use cases.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Mar 2015 01:15:56 -0700

> extremely meaningful.  But there is no 'user' in the handling equation

That's true, I suppose, but there are lots of components of a message
system that don't include user input.  Spam filters don't have user input
but they do care about what gets past them, because their purpose is to
identify and prevent delivery of things that are either annoying or
deceptive.  The user is most certainly the focus.

I'm not disagreeing, but I'm not sure where you're going with this...

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Mon, 23 Mar 2015 07:14:13 -0500

> I'm not disagreeing, but I'm not sure where you're going with this...

As always, I'm seeking to have thinking and discussion focus on software
behavior, not user behavior.

Any discussion of end user perception or behavior is distracting to
meaningful analysis or development of technologies like DMARC.

At a minimum, a reference to users tends to cause people to project
benefits that will not accrue.

d/

---

From: Anne Bennett <[email-masked]>
Date: Mon, 23 Mar 2015 16:07:54 -0400

Dave Crocker writes:

> As always, I'm seeking to have thinking and discussion focus 
> on software behavior, not user behavior.
> 

I can't entirely agree, though I'm not without sympathy to your
point of view.  DMARC is obviously intended to be applied by
the software, and it's tempting to think that the message is
either accepted or rejected, end of story, so this shouldn't
affect the user interface or user behaviour.  In practice I
don't think it's that simple.

Of course, because of the way DMARC is applied (in the DNS)
and messages are signed (by the ISP), the sending user is
not of concern here.  The expressed concerns center on the
perceptions and behaviour of the receiving user.

If p=none (or if DMARC is not used), then the receiving
user gets the message (modulo other de-spamming techniques),
but nothing can be implied about its authenticity, so nothing
changes with respect to the non-DMARC behaviour (of the software
or the user!).

And if the message is rejected due to p=reject, then the user
never gets the message at all, so we needn't be concerned with
the receiving user's behaviour.

But if the message is delivered, either because it passes DMARC,
or it fails but is "quarantined", then the receiver will see the
message, and will make assumptions regarding the authenticity of
its origin based, most likely, on the "From:" header.  It seems
not unreasonable to suppose that the writer of a user interface
would want to indicate somehow to the user that the message was
(or was not) vetted as coming from where it says it came from.
The DMARC results seem like an obvious source of information
for such an indication.

One could argue, I suppose, that once again we're talking
about the behaviour of software, but the point of all this,
unless I woefully misunderstand, is to protect the user from
fraud due to the faked provenance of a message.  I don't think
it will ever be the case that we can sort 100% of messages as
"authentic" or "fake" before they reach the user; we have to
accept that even if we block the "known fakes" based on DMARC,
there will still be authenticated and not-checkable messages
that reach the user - and ideally we'd have a way to indicate
which are which.

Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
[email-masked]                                    +1 514 848-2424 x2285

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 23 Mar 2015 20:23:27 +0000

> From: dmarc [mailto:[email-masked]] On Behalf Of Anne Bennett
> Sent: Monday, March 23, 2015 4:08 PM
> To: [email-masked]
> > As always, I'm seeking to have thinking and discussion focus on
> > software behavior, not user behavior.
> >
> I can't entirely agree, though I'm not without sympathy to your point of view.
> DMARC is obviously intended to be applied by the software, and it's
> tempting to think that the message is either accepted or rejected, end of
> story, so this shouldn't affect the user interface or user behaviour.  In
> practice I don't think it's that simple.
> 
> 
> Of course, because of the way DMARC is applied (in the DNS) and messages
> are signed (by the ISP), the sending user is not of concern here.  The
> expressed concerns center on the perceptions and behaviour of the
> receiving user.

Messages can be (DKIM) signed by any entity that handles the messages in question, not just by an ISP. Aligned (DKIM) signing can only be done with the permission of the domain owner/administrator. Messages may be unsigned and validated on the basis of SPF. 

> 
> If p=none (or if DMARC is not used), then the receiving user gets the
> message (modulo other de-spamming techniques), but nothing can be
> implied about its authenticity, so nothing changes with respect to the non-
> DMARC behaviour (of the software or the user!).
> 

Certainly something can be implied about its authenticity. All p=none says is don't apply policy to the validation.

> And if the message is rejected due to p=reject, then the user never gets the
> message at all, so we needn't be concerned with the receiving user's
> behaviour.
> 

Sure we can - if it's a false positive for an expected message and it never arrives. The receiving user's behavior !=happiness.

> But if the message is delivered, either because it passes DMARC, or it fails
> but is "quarantined", then the receiver will see the message, and will make
> assumptions regarding the authenticity of its origin based, most likely, on the
> "From:" header.  It seems not unreasonable to suppose that the writer of a
> user interface would want to indicate somehow to the user that the message
> was (or was not) vetted as coming from where it says it came from.
> The DMARC results seem like an obvious source of information for such an
> indication.
> 

DMARC addresses only the specific case of direct domain abuse. If I go out and register the domain concordia.co and I send messages from [email-masked] to targeted recipients with SPF/DKIM/DMARC properly configured, do you really want to give a trust indicator to those end users based on messages passing DMARC? Presumably Concordia.co would ultimately end up on a block list but would you really want to give trust indicators in the interim?

> One could argue, I suppose, that once again we're talking about the
> behaviour of software, but the point of all this, unless I woefully
> misunderstand, is to protect the user from fraud due to the faked
> provenance of a message.  I don't think it will ever be the case that we can
> sort 100% of messages as "authentic" or "fake" before they reach the user;
> we have to accept that even if we block the "known fakes" based on
> DMARC, there will still be authenticated and not-checkable messages that
> reach the user - and ideally we'd have a way to indicate which are which.
> 
> 
> 
> Anne.
> --

---

From: Dave Crocker <[email-masked]>
Date: Mon, 23 Mar 2015 15:41:37 -0500

Anne,

> its origin based, most likely, on the "From:" header.  It seems

Unfortunately, user references for this sort of work have no productive
use to that work, but instead often prove counter-productive.

You make an assumption about user assumptions.  Forgive me, but I doubt
you have a reliable, objective, empirical basis for making that
assertion or much that derives from it.  In fact there's a reasonable
chance that your assumption is flawed.

That's why I keep stressing the importance of keeping user references
out of these discussions.  They are not helpful to the work and they are
distracting.

> The DMARC results seem like an obvious source of information

"Not unreasonable' is a common justification for UI design choices.

The reality of successful UI design is that many choices that are "not
unreasonable" don't work or work poorly.

Consequently, "not unreasonable" is a singularly insufficient
justification.  At the very best, it can serve to provide input to
experimental processes that investigate actual efficacy.

> fraud due to the faked provenance of a message. 

As a very general mission statement -- or an even higher-level motivator
for working in this space -- perhaps, but that has essentially no effect
on design choices here.

In practical and operational terms, the point of all this is to allow
filtering engines to make better decisions about possibly-spoofed mail.

d/

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 23 Mar 2015 22:13:11 +0100

On Monday, March 23, 2015 7:02 AM [GMT+1=CET], Stephen J. Turnbull wrote:

> J. Gomez writes:
> 
> > > > But do you think the general email-using population will be
> > > > happy to miss authentic email from eBay, Amazon, Paypal and
> > > > American Airlines, just to get email from some mailing list(s)
> > > > delivered to their inbox?
> 

Verifiable authenticity of email greatly depends on DMARC's success. Because without DMARC's success the authenticity of email can only be verified heuristically and not systematically.

If mailing-lists configured old-style hinder the adoption and ultimate success of DMARC, then received email will not be able to be verified as authentic in any systematic way, but only heuristically. That greatly lessens the value of email as a viable medium for important[*] communications that users want to receive.

[*] I define here "important" as: "potentially expensive for the user if missed and/or potentially expensive for the user if successfully spoofed".

Therefore, as per the above reasoning, given that the "traditional practice of mailing lists adding tags to Subject and footers to the message body" breaks DMARC, it is also breaking the mechanism (DMARC) which could take email to the next level as a viable medium for important communications.

I vote for steam-rolling mailing lists configured old-style to the history books. Mailing list operators just need to take ownership in the Header-From for the messages whose DKIM signature they break, and all is back to working great again!

> configuration of From and Reply-To that satisfies this requirement in

Well, I posit the user requirement is, at large, to take email to the next level a viable medium for important communications.

Regards,
J.Gomez

---

From: "John Levine" <[email-masked]>
Date: 23 Mar 2015 21:45:30 -0000

>Verifiable authenticity of email greatly depends on DMARC's success. Because without
>DMARC's success the authenticity of email can only be verified heuristically and not
>systematically.

Rehashing old arguments will not change anyone's mind.  False assertions are
like these are utterly useless.

Please stop.

R's,
John

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 23 Mar 2015 22:57:17 +0100

On Monday, March 23, 2015 10:45 PM [GMT+1=CET], John Levine wrote:

> > Verifiable authenticity of email greatly depends on DMARC's
> > success. Because without DMARC's success the authenticity of email
> > can only be verified heuristically and not systematically.
> 
> Rehashing old arguments will not change anyone's mind.  False
> assertions are like these are utterly useless.
> 
> Please stop.

To castle into old denial will not change anyone's mind, either.

But please, go on.

Regards,
J. Gomez

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 24 Mar 2015 09:54:21 +0900

> can only be verified heuristically and not systematically.

This is an error of logic.  *Authenticity* (defined as "did the
message satisfy DMARC From alignment when injected?") of *each*
message *can* be verified independently of other messages, and if From
alignment is verified, the message *is* authentic (modulo black
helicopters with 4096-bit encryption breaking equipment).  It's what
to think about non-verifiable mail that becomes unclear.

Since the "important" mail is direct mail, From alignment will be
preserved until received by the addressee.  Therefore list behavior
only affects DMARC verifiability of list traffic, *not* those other
mail flows, as far as I can see.

 > Well, I posit the user requirement is, at large, to take email to
 > the next level a viable medium for important communications.

I understand what you're saying, and we all agree that email as we
currently know it has an important role for Internet communication,
and that for it to continue to fulfill that role we need to improve
its security in several ways.  But (as Dave Crocker is emphasizing in
another subthread), we need to be very careful to define requirements
in terms of what the software can do, and then do our best to
define and implement protocols that satisfy the requirements and
*prove* that the software does satisfy those requirements.

The "requirement" you propose is not implementable in a software
system alone, whether it is satisfied or not cannot be verified from
the behavior of software alone, and therefore cannot be posited as a
requirement in the sense used in software engineering.

Please think about what I've written.  It's a very useful way to think
about software systems, and IETF discussions are normally phrased
using this kind of language.  If you don't use it, people will not
know what you're talking about, and your ideas will not be picked up.

Steve

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 24 Mar 2015 13:15:52 +0100

> to think about non-verifiable mail that becomes unclear.

I think we are not talking about the same thing: when I said "depends on DMARC's success", I meant "depends on DMARC's success as an implemented technology in the real world", whereas it seems you understood "depends on a successful DMARC check".

So I say it again, now in fully qualified terms: Verifiable authenticity of email greatly depends on DMARC's success as an implemented technology in the real world.

> mail flows, as far as I can see.

I explain: if mailing-lists configured old-style keep DMARC from being a success in the real world, then mailing-lists are hindering the extra notch of trustworthiness that DMARC could bring to important email communications for end users as a whole. So it's not about individual messages, as you seem to be talking about, but about the big picture.

And it is that big picture which is begging for mailing-lists operators to abandon their old-style practices and to begin to take ownership in the Header-From of the email they relay and modify while in-flight rendering its original DKIM signature invalid.

> requirement in the sense used in software engineering.

I know that DMARC is not the silver bullet. That's way I said it "brings an extra notch of trustworthiness" to email, I didn't say DMARC brings final and ultimate trustworthiness.

Regards,
J.Gomez

---

From: Anne Bennett <[email-masked]>
Date: Tue, 24 Mar 2015 11:59:21 -0400

Dave,

> chance that your assumption is flawed.

I have a 24-year-long parade of users worried that their account was
compromised because they're receiving bounces for spam they never
sent, wondering why their best friend is suddenly sending them ads
or malware, or responding to phish messages.  In the first two cases,
they believe the "From:" header when they shouldn't; in the last case,
too often they don't even look at the domain in the From: header.

I haven't kept incident stats, so I cannot give you data that
we could reliably use to measure the likely effectiveness of
one approach or another, but my experience is objective and
empirical, in the sense of having been "acquired by means of
observation or experimentation".

But we're straying from the topic, which is indeed to come up with

> for working in this space -- perhaps, but that has essentially no effect

If "the point of all this" has "essentially no effect on design
choices", we have a serious problem.  It's all very well do do
things right, but we have to make sure we're doing the right
thing too.

> filtering engines to make better decisions about possibly-spoofed mail.

... and again, if those decisions result merely in rejecting a
message, the user isn't involved, but as soon as those decisions
can result in tagging a message for possible consideration by the user
(probably via different display by the UI), we can't ignore the user.

I agree that this isn't the place to delve deeply into user behaviour
and UI design.  But we shouldn't ignore the context of our work.

Anne.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 25 Mar 2015 01:14:23 +0900

J. Gomez writes:

 > I think we are not talking about the same thing: when I said
 > "depends on DMARC's success", I meant "depends on DMARC's success
 > as an implemented technology in the real world", whereas it seems
 > you understood "depends on a successful DMARC check".

No, we are talking about the same thing.  What I am saying is that
DMARC is already a "success as an implemented technology in the real
world" by any reasonable standard, because it *does* work for exactly
the transactional mail flows you worry about.  And it is possible to
*prove* that it does work by looking at the properties of checks for
individual messages.

On the other hand, DMARC and similar technologies *cannot* solve the
problem of spam and other abuse by those with whom you've had no
previous relationship.  That's easy to prove too: anybody with access
to a DNS server can add DMARC and DKIM records and sign their mail.

Mailing lists (among other indirect mail flows) do have problems
interacting with DMARC, and it's worth trying to solve those problems.
But they are not going to reverse DMARC's success.

 > I know that DMARC is not the silver bullet.

If you know that, I do not understand how you can classify DMARC as
anything but a success.  I'm an MLM developer; I hate p=reject with a
passion.  But I can't deny that for the vast majority of mail, DMARC
works as advertised, p=reject included.

---

From: Anne Bennett <[email-masked]>
Date: Tue, 24 Mar 2015 12:23:20 -0400

J. Gomez writes:

> given that the "traditional practice of mailing lists adding
> tags to Subject and footers to the message body" breaks DMARC,
[...]
> I vote for steam-rolling mailing lists configured old-style
> to the history books. Mailing list operators just need to
> take ownership in the Header-From for the messages whose DKIM
> signature they break, and all is back to working great again!

In most cases it would be inappropriate for mailing lists
to take ownership of the messages.  They are merely the
distribution mechanism, and wrecking (IMHO) the From: header
to avoid a verification failure seems the wrong way to go in
the long run, even if it has had to be adopted as a workaround
in the short run.

As for subject tags and list trailers, at least the former is
really helpful to me as a user (sorry, Dave! ;-) ), as it lets
me know that a given message is in the context of a public or
semi-public discussion.

I'm not against the idea that mailing list software might have to
adapt to the new reality (of the need for protection against
spoofing), even though there will be a lengthy transition period.

But we can also consider whether there are any changes to DKIM
which would enable mailing lists not to break, or at least,
which would not require changes which negatively affect the
user experience for mailing list subscribers.  Please forgive
me if this has been discussed before (it seems inconceivable
to me that it hasn't), but it should be possible to specify
a format for header tags such that the tag is not included in
the DKIM signature check for the Subject: line.

rfc6376 has:

  Note that Verifiers may treat unsigned header fields with
  extreme skepticism, including refusing to display them to
  the end user or even ignoring the signature if it does not
  cover certain header fields.

Would it be so awful to change that to:

  Note that Verifiers may treat unsigned header fields (or
  unsigned parts of header fields) with extreme skepticism,
  including refusing to display them to the end user, displaying
  them with an indication of unreliabiliy, or even ignoring the
  entire signature if it does not cover certain header fields.

So, risking Dave's wrath once again by discussing possible UI
approaches to verification information, if a header tag format
were specified (for example) to be contained within square
brackets, the UI could display the verified part one way,
and the tagged-and-ignored part another way.

I do freely admit that I don't know the implications of
making it possible to sign only part of a given header.
And I suspect that my suggestion may belong more on a DKIM
discussion list than a DMARC discussion list...

Anne.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 24 Mar 2015 11:33:32 -0500

> the long run, even if it has had to be adopted as a workaround

Formally and practically, they are more than mere re-distributors.

A mailing list typically defines a 'community' for discussion.  At least
some of the modifications it does are to assert that community in some
visible ways.

Mailing lists therefore have the right to make the changes they make.

That said, recipients consider the message to be 'from' and 'by' the
original author, not the mailing list.

> really helpful to me as a user (sorry, Dave! ;-) ), as it lets

Huh?  I /like/ Subject tags.  They help to distinguish list mail from
personal mail.

Right.

> spoofing), even though there will be a lengthy transition period.

I think the historical challenge has less been a case of philosophical
legitimacy and more of inability to gain active, constructive
participation of mailing list software maintainers.

> and the tagged-and-ignored part another way.

This is less a case of wrath -- should I be glad of such de facto and
automatic intimidation, even when it doesn't work well enough to squelch
others' views I disagree with?  Hmmm... -- and more a case of efficacy.

To make any assertions about preferred or appropriate UI behavior is to
require establishing the basis that the behavior will be useful.

The problem here is that the empirical basis for efficacy is lacking.

So making a recommendation might serve to make the specification writers
feel better, but they won't help fight abuse.

d/

---

From: Anne Bennett <[email-masked]>
Date: Tue, 24 Mar 2015 12:55:42 -0400

[...]

> require establishing the basis that the behavior will be useful.

I dispute the idea that the above text makes assertions about
"preferred" UI behaviour - rather, it mentions what might
be possible (and yes, implies that it could be appropriate),
without excluding other approaches.

> The problem here is that the empirical basis for efficacy is lacking.

True, and I agree that it's not up to us to propose
user interface designs.  But our work will be used by UI
designers; how can we best make sure that we give them the
informational tools they need in order to display a given
message "appropriately"?

Do you propose that since the UI is outside our scope, that
we give no consideration at all to the tools that might be
needed in order to implement a UI?

Anne.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 25 Mar 2015 03:02:22 +0900

Dave Crocker writes:

 > A mailing list typically defines a 'community' for discussion.  At
 > least some of the modifications it does are to assert that
 > community in some visible ways.

Sure, but From-munging is not an assertion of community, it's an
assertion that there's a war out there, and the community is taking
hits from friendly fire.

 > Mailing lists therefore have the right to make the changes they

That's an incomplete statement.  They have the right to make the
changes as long as they are compatible with community standards.  For
example, some lists provide advertising space in the footer.  Others
would have a revolution if you tried.  From-munging is just not part
of the community standard in most lists I participate in (and I've
heard that some Yahoo! and AOL users object violently to the
mitigations used to keep their posts from bouncing all over the world).

 > > spoofing), even though there will be a lengthy transition period.

Hardly.  It's already done, at least in GNU Mailman: all of the
transformations that invalidate DKIM signatures are optional.
From-munging was *released* in October 2013 (in 2.1.16 IIRC).  That's
right, *before* the April DMARC Debacle.  We have continued to refine
the features (it's now possible in 2.1.18-1 to condition mitigations
on a DNS lookup for "p=reject").  The software is not the problem.
The list owners and list subscribers are.

Back to Dave:

 > I think the historical challenge has less been a case of
 > philosophical legitimacy

From-munging is hardly open-and-shut "philosophically legitimate."  It
has its advocates, but it sucks for many users because of the way
their MUAs handle it, it arguably violates RFC 5322, and is ugly to
boot.  Nevertheless, GNU Mailman has a From-Munging option.[1]

 > and more of inability to gain active, constructive participation of
 > mailing list software maintainers.

Hey, I resent that.  You guys use GNU Mailman; you know where to find
us if you want participation.

Sure, we resist doing what is proposed.  The fact is that choices
we've been offered suck.  Go away (the choice offered by experimental
early versions of SPF)?  You jest.  From-Munging?  Yuck -- and guess
what, you're no fan, yourself.  No subject tags, no footers?  Excuse
me, but prohibiting a valuable feature is exactly the opposite of a
constructive change -- and you don't like this mitigation yourself.
Note that these mitigations are now in GNU Mailman, as options.  But
most list owners don't want them.

We've come up with our own (RFC-conforming) mitigations.  They suck,
too (MUAs are not prepared to deal with them gracefully, or in the
case of iOS Apple Mail, at all).

It's not the MLM developers you have a problem getting cooperation
from.  It's our users.

Bottom line: making indirect mail flows compatible with DMARC-style
spoof-protection is a hard problem.

Footnotes: 
[1]  Patch courtesy of Franck Martin.

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 24 Mar 2015 21:18:15 +0100

On Tuesday, March 24, 2015 7:02 PM [GMT+1=CET], Stephen J. Turnbull wrote:

> boot.

Well, it seems to me the above paragraph could also be written like this: MLM taking ownership of the Header-From (a.k.a. "From-munging" in your terms) has its detractors, but it works fine for many users who don't have a problem with it, arguably conforms to RFC 5322, and looks just nice.

> spoof-protection is a hard problem.

It's only a hard problem if mailing list operators insist on clinging to their old-style habits (mailing lists users largely either don't care or don't understand the difference; and any other indirect email flows --apart from mailing lists-- are extremely legacy and obsolete).

Regards, 
J.Gomez

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 24 Mar 2015 21:38:41 +0100

On Tuesday, March 24, 2015 5:14 PM [GMT+1=CET], Stephen J. Turnbull wrote:

> the transactional mail flows you worry about.

I do not agree. As long a major ESPs downgrade p=reject to p=quarantine or even p=none on reception of email which fails DMARC checks from domains whose Owner has published p=reject, DMARC is little more than a reporting protocol as Vlatko Salaj has already said in another post to this list. Which is nice, but is not a "success as an implemented technology in the real world" for DMARC, because DMARC aims to be more than just a reporting tool.

I know for sure I will publish only p=none for my client's domains, and use DMARC only as a reporting tool, as long as DMARC's p=reject cannot be reliably relied on. But I would love to be able to reliably rely on DMARC's p=reject.

In fact, I think that if at the end of all this process we cannot find a way to make p=reject to be reliably relied on, then p=reject should be suppressed from the DMARC formal specification, as p=reject would effectively be equal to p=do-whatever-who-cares.

Regard,
J.Gomez

---

From: "J. Gomez" <[email-masked]>
Date: Tue, 24 Mar 2015 21:47:25 +0100

On Tuesday, March 24, 2015 4:59 PM [GMT+1=CET], Anne Bennett wrote:

> > In practical and operational terms, the point of all this is to
> > allow filtering engines to make better decisions about
> > possibly-spoofed mail. 
> 

+1

Email is for the users. p=quarantine is a USER PROBLEM.

Lets not forget that.

Regard,
J.Gomez

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 24 Mar 2015 14:01:03 -0700

On Tue, Mar 24, 2015 at 1:38 PM, J. Gomez <[email-masked]> wrote:

> I know for sure I will publish only p=none for my client's domains, and
> use DMARC only as a reporting tool, as long as DMARC's p=reject cannot be
> reliably relied on. But I would love to be able to reliably rely on DMARC's
> p=reject.
>

I'm not sure I agree with the claim that p=reject is unreliable.  It seems
to me that it's working as designed, and the results are deterministic.
It's not flaky.  How receivers use it is the mushy part, but that's really
outside of the protocol.

Even if DMARC didn't have these mediator problems, there still would be no
ultimate compulsion for receivers to do what domain owners ask.  It might
be a lot more likely that they would comply without reservations, but there
would still be some operators that don't.

So just to be clear, are you using "reliable" here to talk about how
receivers apply it?

-MSK

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 24 Mar 2015 21:04:28 +0000

> From: dmarc [mailto:[email-masked]] On Behalf Of J. Gomez
> Sent: Tuesday, March 24, 2015 4:39 PM
> To: [email-masked]
> as
> > > an implemented technology in the real world", whereas it seems you
> > > understood "depends on a successful DMARC check".
> >
> I do not agree. As long a major ESPs downgrade p=reject to p=quarantine or
> even p=none on reception of email which fails DMARC checks from domains
> whose Owner has published p=reject, DMARC is little more than a reporting
> protocol as Vlatko Salaj has already said in another post to this list. Which is
> nice, but is not a "success as an implemented technology in the real world"
> for DMARC, because DMARC aims to be more than just a reporting tool.
> 

Mailbox providers/ISPs are going to do what they do. Recognizing local policy is one of the reasons that the large mailbox providers/ISPs decided to validate DMARC and play ball. By and large they get it right (at least in my experience and I've been doing DMARC since before it was public). Even for transactional mail from originators which have control over their mail flows, there will always be some small percentage of mail that gets broken because of certain types of forwarding (beyond mail lists). From my perspective, when a mailbox provider/ISP chooses to implement local policy over my request (through a published p=reject policy) then they are taking responsibility for their decision. To demand more from them is simply unrealistic. Any organization can publish a standard - the real proof is the extent to which people adopt that standard.

> I know for sure I will publish only p=none for my client's domains, and use
> DMARC only as a reporting tool, as long as DMARC's p=reject cannot be

My experience is that the overwhelming majority of time you can reliably rely on DMARC's policy implementation - and I'm looking at a corpus of Billions of sent mail. You can check this yourself by looking at the reporting you receive. If mailbox providers would have overridden your p=reject it will show in the reporting you receive and you can gauge the potential outcome yourself. You are making assertions that the data doesn't support. Mailbox providers have no incentive to randomly override DMARC with local policy for non-trivial reasons. The real problem is that once you get past the top mailbox providers, the remainder of them don't have the resources/expertise/large enough data sets to implement local policy overrides in a manner that is workable and sustainable. Perhaps someone can make a go of offering this as a service - perhaps not.

> In fact, I think that if at the end of all this process we cannot find a way to
> make p=reject to be reliably relied on, then p=reject should be suppressed
> from the DMARC formal specification, as p=reject would effectively be equal
> to p=do-whatever-who-cares.
> 

Mike

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 24 Mar 2015 21:08:55 +0000

> Sent: Tuesday, March 24, 2015 4:47 PM
> To: [email-masked]
> > message, the user isn't involved, but as soon as those decisions can
> > result in tagging a message for possible consideration by the user

No, p=quarantine is a problem WE cause. All these experts and algorithms can't figure it out so we toss it in quarantine/junk/spam folder and then tell the user to figure it out. WE cause the problem. A person who used to be active in the email space once told me that the extent to which messages are placed in quarantine/junk/spam folders is a reflection of how well or poorly the systems evaluating the mail work. If it works really well then nothing should end up in quarantine/junk/spam folders.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 24 Mar 2015 14:16:21 -0700

On Tue, Mar 24, 2015 at 2:08 PM, MH Michael Hammer (5304) <[email-masked]>
wrote:

>
> No, p=quarantine is a problem WE cause. All these experts and algorithms
> can't figure it out so we toss it in quarantine/junk/spam folder and then
> tell the user to figure it out. WE cause the problem. A person who used to
> be active in the email space once told me that the extent to which messages
> are placed in quarantine/junk/spam folders is a reflection of how well or
> poorly the systems evaluating the mail work. If it works really well then
> nothing should end up in quarantine/junk/spam folders.
>
>
That's not how I characterize the spam folder, at least at the operators
where I have mailboxes.  It's more like: "We have reason to believe this is
spam or otherwise illegitimate.  We will silently set it aside and
automatically discard it in X days, unless you come looking for something
you feel might've been miscategorized and rescue it."

That's different from telling the user to figure it out, which I take to
mean something more like an ongoing and fairly constant filter training
exercise.

Of course, this only highlights again that different receivers will treat
DMARC's output in whatever way suits them.

-MSK

---

From: Anne Bennett <[email-masked]>
Date: Tue, 24 Mar 2015 17:19:49 -0400

Michael Hammer writes:

> A person who used to be active in the email space once
> told me that the extent to which messages are placed in
> quarantine/junk/spam folders is a reflection of how well
> or poorly the systems evaluating the mail work. If it works
> really well then nothing should end up in quarantine /junk/spam
> folders.

The number of messages sorted as "not sure" is hardly the
best or only measure of how well the system works; to take
the above to an extreme, if I reject all mail, does my system
work perfectly?  ;-)

But yes, the ideal situation is where we sort every message
correctly and unambiguously.  Meanwhile...

Even if we grant that "p=quarantine is a problem WE cause",
the fact is that until we have a *good* solution for mailing
lists, most of us don't dare publish p=reject, which leaves us
with p=none, or no DMARC records at all.  Which means that (a)
many of us cannot benefit from using DMARC under the current
circumstances, and (b) many sites don't have the resources to
implement it yet, but we still have to deal with their mail.
I'm not willing to throw the baby out with the bathwater.

Anne.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 24 Mar 2015 14:26:45 -0700

> I'm not willing to throw the baby out with the bathwater.

+1.  To be a bit flippant about it: Now that we have everyone's attention,
possibly moreso than ever before, maybe it's possible to come up with a
compromise that all corners of the email ecosystem can accept.

But that doesn't mean we need to settle for creating schisms in that
ecosystem.  Entrenching is not the answer.

-MSK

---

From: Steve Atkins <[email-masked]>
Date: Tue, 24 Mar 2015 14:32:02 -0700

> I'm not willing to throw the baby out with the bathwater.

Mailing lists are only an issue if the domain owner of the
email addresses of the participants have published a
DMARC p=reject record, despite having actual users who
are legitimate source of email that fails authentication.

That's a small enough set of domains at the moment (I can think
of about five) that there are several obvious solutions for mailing
lists - a blacklist of DMARC records to treat specially would be
the simplest, though something more nuanced might be better.

Cheers,
  Steve

---

From: Dave Crocker <[email-masked]>
Date: Tue, 24 Mar 2015 16:41:15 -0500

> assertion that there's a war out there, and the community is taking

Your 'but' suggests that your comment counters mine, but I said 'some'
not all and I didn't mention the From field.  Nor did I intend to count
>From munging as an exemplar.

> changes as long as they are compatible with community standards.

There is a very long list of additional qualifiers and requirements one
might choose to include.

However I think they distract from the point I was making, which really
merely reflects what is in the Email Architecture RFC:

     When an intermediary is re-posting a message, it owns the message
it is re-posting and has the right to do what it wants.

That's a system architecture "right", not a "social' right.

> From-munging is hardly open-and-shut "philosophically legitimate."

So it's probably good that I wasn't talking about that.

>  It

There are three operational problems with From munging:

   1.  The recipient sees a different string than they are used to, for
identifying the author of the message.  That invites confusion.

   2.  The recipient's filtering engine will misbehave if it keys off of
author's name; a related problem is that message threading software will
misbehave.

   3.  From munging teaches spoofers how to bypass DMARC protections.

> us if you want participation.

I was making an historical comment.  Many years ago.  Ancient Internet.
 Most of you folk probably weren't born yet. (just kidding.)  (maybe.)

> It's not the MLM developers you have a problem getting cooperation

We need to stop worrying about users.  They are simply a distraction.

Or maybe...

+1

d/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 24 Mar 2015 16:55:41 -0500

On 3/24/2015 10:59 AM, Anne Bennett wrote:
> sent,

Forgive me (yet again) but that wasn't the issue.  Yes there's a
problem.  Long-standing, real and serious.

However the issue on the table is an assertion of efficacy by presenting
certain kinds of information to end-users.  And it's that assertion that
is (highly) problematic.  Which is why I urge everyone to bypass it.

> things right, but we have to make sure we're doing the right

Protecting users does not automatically or necessarily entail presenting
spoofing/validity information to those users.

> (probably via different display by the UI), we can't ignore the user.

The presumption that 'tagging a message for possible consideration by
the user' is in any way relevant or helpful is problematic.  Highly
problematic.

> and UI design.  But we shouldn't ignore the context of our work.

Any consideration here, which leads to assumptions or expectations of
things being presented to end users for their consideration, is a pure
distraction -- at its best.

d/

---

From: Steven M Jones <[email-masked]>
Date: Tue, 24 Mar 2015 15:01:09 -0700

> I do not agree. As long a major ESPs downgrade p=reject to p=quarantine or even p=none on reception of email which fails DMARC checks from domains whose Owner has published p=reject, DMARC is littl…

DMARC is not some declaration of the divine right of domain owners to
exercise absolute control over any message where their domain appears.

DMARC is a protocol that enables domain owners/senders and receivers to
*collaborate* in detecting and eliminating fraudulent messages that
claim to originate from a given domain. There is implicit and explicit
give-and-take in that relationship.

Policy expressions from domain owners ("p=reject") are requests - ones
that are followed in most cases - but no receiver is offering an
unreserved, 100% guarantee that they won't act otherwise when they feel
doing so is in the best interest of their users.

The fact that receivers can and will do what they think best, even in
the face of a given policy request, runs throughout the DMARC specification.

> In fact, I think that if at the end of all this process we cannot find a way to make p=reject to be reliably relied on, then p=reject should be suppressed from the DMARC formal specification, as p=…

Again, in my experience, receivers do honor policy assertions in an
overwhelming majority of cases.

The reporting mechanisms in DMARC are there to help domain
owners/senders improve the authentication rates of their legitimate
mailflows - so the receivers can block more fraudulent messages, more
reliably. Without the support for so-called "blocking policies," you
have eliminated the reason for receivers to pay for complex, expensive
DMARC filtering and reporting.

--Steve.

---

From: Hector Santos <[email-masked]>
Date: Tue, 24 Mar 2015 21:52:38 -0400

For nearly 10+ years we have discussed the same basic design issues. 
Nothing has changed other than the fact it is DMARC, as it is 
currently written as the replacement protocol for a DKIM POLICY 
SSP/ADSP framework, is very lacking intentionally. We don't have 
enough of the advocates we once had, pushing the COMPLETE DKIM POLICY 
FRAMEWORK concept.  Either they got tired walked away, they saw can't 
beat a dead horse or realize the people in "IETF control" were pushing 
other ideas that were not necessarily wrong, but they PUT barriers up 
to support the AUTHOR domain framework.

We will not move forward in a major way until the 3rd party SIGNATURE 
authorization methodology is worked out.  It was a thorn on the side 
then and it continues to be a thorn on the side today.

We have quite a few RFCs related to DKIM signature methodologies and 
we never did properly resolved it (3rd party signers) because the key 
folks running the show were pushing a 3rd party TRUST methodology. 
They were militarily adamant about making sure the AUTHOR domain would 
not be dictating anything, hence the DKIM myth the AUTHOR DOMAIN was 
not related to the DKIM SIGNER AUTHENTICATION and AUTHORIZATION.  That 
SEPARATION was impossible to ACHIEVE because the AUTHOR was a minimal 
hash binding requirement.

But today, the TRUST part has gone no where, i.e. VBR was the closest 
thing to a DKIM TRUST model (we support it, do you?). It was AUTHOR 
POLICY that has prevailed but DMARC crippled it by sticking with the 
same problems ADSP had.

Add 3rd party POLICY extensions and we will begin to get sensible 
software solutions again.   We done it with ADSP/ATPS. So can large 
boys too with DMARC/ATPS.   Add ATPS support or similar and we will 
begin to move forward with a framework for proper SOFTWARE CHANGE at 
the MLM.

Wasting too much time again.  Just update ATPS for DMARC and get MURRY 
to support the idea and maybe we will get others to get it a try.  But 
if he is going to continue to block it, talk negative about it, well, 
  we have a technical marketing problem that is not representative of 
a good technical, plug and play, easier solution for DKIM SIGNATURE 
AUTHORIZATION PROTOCOL.

-- 
HLS

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 25 Mar 2015 13:24:49 +0900

J. Gomez writes:
 > Well, it seems to me the above paragraph could also be written like
 > this: MLM taking ownership of the Header-From
 > (a.k.a. "From-munging" in your terms) has its detractors, but it
 > works fine for many users who don't have a problem with it,
 > arguably conforms to RFC 5322, and looks just nice.

OK, well, we'll just have to agree to disagree.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 25 Mar 2015 13:29:41 +0900

> are legitimate source of email that fails authentication.

False.  Mailing lists only have an obvious problem if p=reject is
published, but DMARC doesn't say that you can't differentiate between
aligned mail and unaligned mail, only that you can't differentiate
between a failed signature verification and no signature at all.

Sites can and do assign negative spam points to verified signatures,
so there is a (smaller, but still real) problem for MLs even if nobody
publishes p=reject.

---

From: "J. Gomez" <[email-masked]>
Date: Wed, 25 Mar 2015 20:17:22 +0100

On Tuesday, March 24, 2015 10:08 PM [GMT+1=CET], MH Michael Hammer (5304) wrote:

> > > can result in tagging a message for possible consideration by the
> > > user (probably via different display by the UI), we can't ignore
> > > the user. 
> > > 
> > > I agree that this isn't the place to delve deeply into user
> > > behaviour and UI design.  But we shouldn't ignore the context of
> > > our work. 
> > 
> > +1
> > 
> No, p=quarantine is a problem WE cause.

Yes, but a problem that ultimately the user gets directly planted before his eyes, and which the user has to roll up his sleeves to deal with as well/bad as he can possibly manage.

Translation: p=quarantine has vey high support costs.

As I understand it, in the beginning of the coming up with DMARC, p=quarantine was designed as a stepping stone in the journey towards p=reject. In that view, the high support costs of p=quarantine were tolerable because p=quarantine was meant to be a temporary situation for the sender domain Owner. Now that p=reject is a dead end for all practical purposes, p=quarantine has less and less utility. Only p=none is safe to use unless you do not have real people as users.

We must work hard to find a solution which makes p=reject a viable setting which can be reliably relied on.

Regards,
J.Gomez

---

From: "J. Gomez" <[email-masked]>
Date: Wed, 25 Mar 2015 20:30:19 +0100

> the simplest, though something more nuanced might be better.

That "blacklist of DMARC records [with p=reject] to treat specially" I'm afraid is a solution which will not scale. You say there are now "about five" of such domains. Well, about five big enough for everyone to notice them, but surely there are many more which are small enough to fly under our radar.

It would take just some more data breaches and we might get to a "blacklist for DMARC records with p=reject" in the form of: "*"  ;-)

Regards,
J.Gomez

---

From: "J. Gomez" <[email-masked]>
Date: Wed, 25 Mar 2015 20:58:23 +0100

Hi, Murray.

(Aside: Your email client is sending messages in "multipart/alternative" format, but then its "text/plain" section has the quoting broken...  Could you fix that, please? I had to manually add ">>" below to differentiate your text from mine, I hope I didn't gaffe it...)

---- Original Message ----
From: Murray S. Kucherawy
To: J. Gómez
Cc: [email-masked]
Sent: Tuesday, March 24, 2015 10:01 PM
Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC)

>> I know for sure I will publish only p=none for my client's domains,
>> and use DMARC only as a reporting tool, as long as DMARC's p=reject
>> cannot be reliably relied on. But I would love to be able to reliably
>> rely on DMARC's p=reject.   
> 
> I'm not sure I agree with the claim that p=reject is unreliable.  It
> seems to me that it's working as designed, and the results are
> deterministic.  It's not flaky.  How receivers use it is the mushy
> part, but that's really outside of the protocol.   

The set (DMARC + p=reject) is unreliable, in the current situation, because it fails to describe the legitimate and real scenario of mailing lists.

> Even if DMARC didn't have these mediator problems, there still would
> be no ultimate compulsion for receivers to do what domain owners ask.
> It might be a lot more likely that they would comply without
> reservations, but there would still be some operators that don't.   
> 

No. It is "unreliable" for Receivers to apply it. Sure, for the Sender p=reject is perfectly reliable, if he happens to have all his ducks neatly in a row. But the Receiver cannot know if the Sender has all his ducks neatly in a row when said Sender publishes p=reject. Question that the Receiver asks to himself: Is the Sender aware of p=reject drawbacks and can therefore the Receiver rely on the Sender's declared p=reject? Answer to that question: The Receiver has no way to know, therefore p=reject is unreliable from the point of view of the Receiver, irrespective of what the Receiver ultimately decides to do with the Sender's declared p=reject.

Regards,
J.Gomez

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Mar 2015 14:04:33 -0700

On Wed, Mar 25, 2015 at 12:58 PM, J. Gomez <[email-masked]> wrote:

> No. It is "unreliable" for Receivers to apply it. Sure, for the Sender
> p=reject is perfectly reliable, if he happens to have all his ducks neatly
> in a row. But the Receiver cannot know if the Sender has all his ducks
> neatly in a row when said Sender publishes p=reject. Question that the
> Receiver asks to himself: Is the Sender aware of p=reject drawbacks and can
> therefore the Receiver rely on the Sender's declared p=reject? Answer to
> that question: The Receiver has no way to know, therefore p=reject is
> unreliable from the point of view of the Receiver, irrespective of what the
> Receiver ultimately decides to do with the Sender's declared p=reject.
>

I think you're actually saying exactly what I thought you meant.  Thanks
for confirming.  I just wanted to be clear for context.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Wed, 25 Mar 2015 22:08:35 -0400

Mr. Gomez,

Traditionally, many in the IETF and the mail industry had an aversion 
towards strong deterministic transport (system) level filtering ideas. 
  This is burned into RFC2821/5321:

    7. Security Considerations
    7.1 Mail Security and Spoofing

    This specification does not further address the authentication issues
    associated with SMTP other than to advocate that useful functionality
    not be disabled in the hope of providing some small margin of
    protection against an ignorant user who is trying to fake mail.

The text different between 2821 and 5321 is that the "user" is no 
longer "ignorant."

Many preferred to pass the buck to the user for making decisions on 
what is considered accepted mail. The DMA, the "Spammer" world, good 
or bad, want you to ACCEPT the mail to pass to the user.  CAN-SPAM 
also plays a role here too in the area of User Vendor contracts.

So in general, whenever we had new strong deterministic rejection 
protocols, we had the friction of dealing with "ACCEPT/SEPARATE" or 
"Quarantine" ideas embedded as well as means to reduce the potential 
false positive nature of rejection policies.

Case in point with SPF.

SPF had a strong REJECTION concept with RFC4408 and with the latest 
spec RFC7202, it was relaxed with allowing for quarantining ideas 
(mail separation). RFC7208 made RFC4408 more costly by adding more 
complexity for an "ACCEPT/SEPARATE" mode of operation for failed SPF 
messages as opposed to just REJECTING failed SPF messages.

Part of the problem is that the idea of quarantine does presumed a 
backend mail storage design that mail separation was even possible. 
It is not an universal concept to have this multiple mail folders 
idea, ability and/or MUA/UI infrastructure for end-users.  So in that 
vain, it does come with a high support and also high implementation 
cost to include Mail Quarantine functionality into a specification. 
REJECTION is a must lower design implementation cost.

In theory, rejection or quarantine, both must provide the same end of 
result of protecting users from harm and also the domain from being 
exploited.  If you are going to quarantine mail instead of rejecting 
it, then  you need to make sure the USER does not get the mail 
directly in the natural in-box, including the POP3 mail stream -- it 
must not be part of the pick up.

--
HLS

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Thu, 26 Mar 2015 12:08:45 +0900

J. Gomez writes:

 > >> But I would love to be able to reliably rely on DMARC's
 > >> p=reject.

Even if you can in practice, you can't get to 100.0%.  Even at
ducks-in-a-row sites like <frequent-DMARC-contributor-employer.com>
(which is a financial institution and uses that domain for
transactional mailflows), <frequent-DMARC-contributor> has at least
once used his/her "p=reject" address to post to a mailing list I
subscribe to (which didn't implement DMARC).  These things happen.

It's possible that the rate of occurance is low enough that you would
be happy to set your receiving MTA to reject that post because it
failed alignment with the "p=reject" domain.  But I might not,
preferring to rely on a filter that weights "reject legitimate" (eg,
"reject existing correspondent") far more negatively than yours does.

Of course it's up to you what you do.  I'm just saying that the
protocol needs to deal with extreme preferences like the ones I
(hypothetically) attribute to myself.

 > The set (DMARC + p=reject) is unreliable, in the current situation,
 > because it fails to describe the legitimate and real scenario of
 > mailing lists.

Technically, it does describe them: author domains "should not" use
p=reject if it authorizes indirect mailflows From its mailboxes.  AOL
and Yahoo! were abusing p=reject according to the draft of April 2014.

The reason I bring this up is that I find it hard to imagine a world
in which, even after that experience, non-transactional mailflows
currently covered by p=none would have all of their third party relays
registered with a third-party authorization protocol.  On the other
hand botnets mean that draft-kucherawy-dkim-delegate and
draft-levine-dkim-conditional can be massively exploited if ordinary
users at those sites are allowed to use those mechanisms without
oversight by the author domain.  So I suspect that a registry of third
parties is an essential precondition for p=reject to be compatible
with open-subscription mailing lists.

AFAICS, that means that any such protocol is going to be unreliable
in the face of a security breach like those at AOL and Yahoo!.

Of course you could imagine a world where everybody implements DMARC
and p=none doesn't exist.  Then Mediators must register or their
messages won't be delivered, period.  But to me, that's not email. :-(

---

From: "J. Gomez" <[email-masked]>
Date: Thu, 26 Mar 2015 20:51:45 +0100

> subscribe to (which didn't implement DMARC).  These things happen.

Yes, but then in that DMARC rejection which you describe above the Receiver can blame it on the Sender, who did not put his ducks neatly in a row as he should have done.

The question is: who bears the cost of DMARC's p=reject "false positives"? As a Receiver, I will be blind and will not obey to Sender's p=reject unless I can blame on said Sender the rejection --derived form the Sender's declared DMARC of p=reject-- of legitimate email.

> and Yahoo! were abusing p=reject according to the draft of April 2014.

That Yahoo and AOL are "abusing p=reject" is a way to see the case. Another way to see it, is that DMARC's p=reject fails to describe real email usage, and therefore is unreliable (i.e., cannot be relied on).

Regards,
J.Gomez

---

From: "J. Gomez" <[email-masked]>
Date: Thu, 26 Mar 2015 21:21:48 +0100

> REJECTION is a must lower design implementation cost.

+1.

For Google/Hotmail/big-ESP, the support costs are already accounted for in their cost structure. For small or "boutique" Email Service Providers, support costs are very important and can grow very fast: an user has a problem with suspect or missing email?, we go on-site, we hand-hold them, we give face, we remote into their system and get to deal with the mess, we do whatever until the troubled user finds peace...

If DMARC is going to increase support costs for small email operators, I may as well migrate all my clients to Google Apps or Office 365 and be done with costly email.

That is why, in my view, DMARC's p=reject has to either be reliable to be relied on, or be suppressed from DMARC's formal specification if it is going to mainly be equal to p=do-whatever.

Regards,
J.Gomez

---

From: Franck Martin <[email-masked]>
Date: Thu, 26 Mar 2015 16:37:00 -0500 (CDT)

----- Original Message -----
> From: "J. Gomez" <[email-masked]>
> That is why, in my view, DMARC's p=reject has to either be reliable to be
> relied on, or be suppressed from DMARC's formal specification if it is going
> to mainly be equal to p=do-whatever.
> 

when you see a p=reject and DMARC tells you, you should bounce the email, then just bounce it. Why?

1) there are reports to tell the sender why you bounced the email. And it should get the bounce too. If it is not what the sender wants, he has all the tools to assess if it was important for the receiver to receive this message or not and what can the sender do to change that.
2) Mailing lists should be able to differentiate between an Hard bounce and a Soft bounce (by now). http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml is 7 years old now.

If you do anything else, it is because you want to be nice to the sender. (pulling leg here)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 26 Mar 2015 15:23:08 -0700

On Thu, Mar 26, 2015 at 1:21 PM, J. Gomez <[email-masked]> wrote:

> If DMARC is going to increase support costs for small email operators, I
> may as well migrate all my clients to Google Apps or Office 365 and be done
> with costly email.
>
> relied on, or be suppressed from DMARC's formal specification if it is
> going to mainly be equal to p=do-whatever.
>

Can anyone point to a single instance of a sender-receiver policy protocol
that was "reliable" by this definition, enough that receivers would blindly
agree to do whatever the sender asked/suggested/demanded?

I can't think of any.  Some, many, or most of them were supposed to be, but
it has never turned out that way.  I don't know why DMARC is being held to
a different standard.

-MSK

---

From: Michael Jack Assels <[email-masked]>
Date: Thu, 26 Mar 2015 19:12:13 -0400

On Thu, 26 Mar 2015 15:23:08 PDT, 

> it has never turned out that way.  I don't know why DMARC is being held to

Isn't DMARC holding itself to a different standard?  What's a receiver
supposed to do with unaligned mail whose "From:" domain specifies p=reject?
Clearly, the domain owner is explicitly asking that the message be
rejected.  If DMARC intends that this be merely one of many factors to
consider, then doesn't it boil down to nothing more than p=do-whatever?

Yes, I know that receivers can and will do as they please, but some
receivers would be pleased as punch to cooperate in a scheme that gave
solid proof of a message's illegitimacy in every case where it was
asserted.  The problem is that publishing p=reject effectively asserts that
almost all submissions to mailing lists by users in the domain are
illegitimate, and I'm afraid the real world doesn't believe that to be the
case.

That's not to say that DMARC should change anything about itself.  It's
just recognition that making it a great success will depend on someone
finding a way to let mailing lists collaborate with DMARC without
alienating their list users, owners or managers.

I'd love to announce that I've found the way, but I'm as befuddled as
anyone else.

MJA

---

From: Franck Martin <[email-masked]>
Date: Thu, 26 Mar 2015 18:22:44 -0500 (CDT)

----- Original Message -----
> From: "Michael Jack Assels" <[email-masked]>
> To: "Murray S. Kucherawy" <[email-masked]>
> Cc: [email-masked], "J. Gomez" <[email-masked]>
> Sent: Thursday, March 26, 2015 4:12:13 PM

You can't please everyone at the moment, and there are solutions to please various subsets of your lists.

I'm on various mailings lists, some friendly to DMARC, some not, with email with a domain with p=reject, or not...

What I learn for all the combinations: It does not change much, people still ignore my posts :P

---

From: Steven M Jones <[email-masked]>
Date: Thu, 26 Mar 2015 16:38:08 -0700

> What I learn for all the combinations: It does not change much, people

Franck, that's waaaay outside the charter of this working group...

---

From: Franck Martin <[email-masked]>
Date: Thu, 26 Mar 2015 18:46:09 -0500 (CDT)

----- Original Message -----
> From: "Steven M Jones" <[email-masked]>
> To: [email-masked]
> Sent: Thursday, March 26, 2015 4:38:08 PM
We were there a few posts back already...

Can people please review the last version of https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ and comment?

This document still needs some improvemments and its completion is a milestone to progress further.

Thanks.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 27 Mar 2015 14:28:18 +0900

Franck Martin writes:

 > 2) Mailing lists should be able to differentiate between an Hard
 >    bounce and a Soft bounce (by now).
 >    http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml
 >    is 7 years old now.

They can, but the problem that caused collateral damage to subscribers
is hard bounces, and "p=reject" is a hard bounce.  Perhaps you mean
discriminating between "technical hard bounces" and "policy hard
bounces", but even there (a) I don't understand why you think there's
a difference in the way the ML should treat them, and (b) many
receiving sites deliberately conceal policy bounces, and especially
the reason for them.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 27 Mar 2015 15:22:04 +0900

Michael Jack Assels writes:

 > > I can't think of any.  Some, many, or most of them were supposed
 > > to be, but it has never turned out that way.  I don't know why
 > > DMARC is being held to a different standard.
 > 
 > Isn't DMARC holding itself to a different standard?

That's a reasonable interpretation given the choice of mood ("reject"
is a command), but in the end it's untenable.  As Murray says,
"policy frameworks" have been tried before, and they just don't work
for "generic" email, although they work very well (as indeed DMARC
does) for several important, but restricted, mail flows.

The problem with "generic" email is that the incentives of Author
Domains which provide mailboxes for personal use are poorly aligned
with the incentives of their mailboxes' users.  Specifically, Author
Domains consider spam-fighting priority one, and consider mailing
lists and other indirect flows at best neutral, and often on net a
nuisance, while their users want to participate freely in indirect
flows (leaving the costs of spam-fighting up to the Author Domains).

 > What's a receiver supposed to do with unaligned mail whose "From:"
 > domain specifies p=reject?

Whatever they want to.  If they think they can do filtering better
than the sender, they may choose to ignore it, and there's nothing
that can be done about it.  Furthermore, I don't see why anyone other
than the receiver's mailbox users should care what the receiver
chooses to do.

 > rejected.

No, they are not, not in the case of AOL and Yahoo!.  Representatives
of both domains have thanked MLM developers for providing mitigations
so that messages that in the normal (until DMARC) course of events
would fail From alignment can be delivered to DMARC-participating
receiving domains which (since DMARC) would reject them.  Thus, Yahoo! 
and AOL are clearly taking the position that they would like those
messages to be delivered.

Hector, J. Gomez, Franck, and others take the position that the world
has changed due to spam and phishing, and therefore "what *was*
normal" is now irrelevant.  The new norm is conform to DMARC and other
dictatorial sender policy frameworks or you're part of the problem.

I disagree.  Spamming and phishing are the problem, traditional
practices of mailing lists are not.

 > If DMARC intends that this be merely one of many factors to

No, there is valuable information in the policy.  As far as I can see,
the semantics of "p=reject" are

    We have a serious spoofing problem.  It is so serious compared to
    the potential damage due to rejecting legitimate messages that we
    accept all responsibility for nondelivery and collateral damage if
    you choose to reject.

In the case of direct mail flows, the potential damage due to
rejection of legitimate mail is very low, and the potential damage
from accepting spoofed mail is extremely high.  If you know that a
mail flow is direct, as a receiver you'd be crazy not to reject, and
as a sender you'd be crazy not to accept the responsibility for
receivers rejecting.

In the case of indirect flows, receivers may (or may not) want to
prefer their judgment to that of the author domain, because often the
expected damage from accepting is much lower, and the expected damage
from rejecting much higher.

 > receivers would be pleased as punch to cooperate in a scheme that
 > gave solid proof of a message's illegitimacy in every case where it
 > was asserted.

Murray's point is that "proof of illegitimacy" is probably a pipe
dream, as shown by past experience with "policy frameworks".[1]
Legitimacy, on the other hand, is fairly easy to prove, as DMARC shows
in daily use by financial institutions and in other transactional mail
flows.

Footnotes: 
[1]  Hector is right that they haven't really been tried, but I don't
think the chance that they'll be tried in the future is high, because
the reasons they've been hard to implement in the past remain true.

The big problem is that policy frameworks proposed so far "work" only
if you define "legitimacy" tautologically: if it gets past the policy
framework, it's legit, else not.  That's not what my users want,
though.  They want to receive the mail they want to receive, and
otherwise not, and no policy framework so far has shown promise of
implementing that.

---

From: Franck Martin <[email-masked]>
Date: Fri, 27 Mar 2015 01:23:30 -0500 (CDT)

----- Original Message -----
> From: "Stephen J. Turnbull" <[email-masked]>
> To: "Franck Martin" <[email-masked]>
> Cc: [email-masked]
> Sent: Thursday, March 26, 2015 10:28:18 PM

There is:
Temporary Failure: SMTP Status code 4xx (mainly): try again in a few minutes or on a different MX/IP
Permanent Failure: SMTP Status code 5xx (mainly): don't try again, get the user to fix it
and:
Hard Bounce: "no such mailbox/user/email address here" (SMTP enhanced status code, like 5.1.1), usually a permanent failure
Soft Bounce: "there may be a valid mailbox/user/email address here, but we are not accepting this email" (SMTP enhanced status code like 5.7.1), a permanent or temporary failure

Before the SMTP enhanced error codes existed, you had to parse the text portion of the error message and tried to figure out what it meant. You still kind of do it today.

http://help.campaignmonitor.com/topic.aspx?t=26#soft-vs-hard
https://sendgrid.com/blog/email-bounce-management/
http://www.boogietools.com/Products/Linux/BounceStudioAPI/Email-Bounce-Boogie-Bounce-API-Categories.asp

I admit, it is a bit of rocket science here, and if you can't deliver email reliably after several repeated soft bounces, then you should mark the email address as bounced and get the user to re-confirm it. Your mileage may vary.

Also there is the notion of bouncing vs rejecting which I prefer to call asynchronous bounce vs synchronous bounce, because even when you reject, an email (bounce) is usually created to be placed in the mailbox of the sender to inform him/her the email was not sent.

as for DMARC:
http://tools.ietf.org/html/rfc7489#section-10.3
and AFAIK, the text portion of the current implementations I know of gives a hint, it is because of DMARC.

I know mailman 3.0 has a better bounce management system, and I think it will be a separate library, which would be awesome, because it can be included in other open source projects. So when the mailing list recognize the bounce is due to DMARC, then it could either ignore the bounce, or mark that against the original sender rather than the receiver. No more collateral damage.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 26 Mar 2015 23:59:02 -0700

> in daily use by financial institutions and in other transactional mail

Put another way, you only really know something when DMARC, DKIM, SPF, etc.
produce a passing result.  (Due credit to Dave for this observation.)  All
of them have false negatives with respect to anything that's not a direct
mail flow, so "fail" results don't tell you anything conclusive if you plan
to accept any sort of mail that isn't direct.  What Hector characterizes as
a watering down of SPF with the publication of RFC7208 was merely this fact
put into text, even though it's been true since RFC4408.

> the reasons they've been hard to implement in the past remain true.

I agree.  And although Hector likes to ascribe considerable power and
influence to me, I'm not the one standing in the way of their success.  I
would happily embrace any such solution that stood a chance of working.  I,
and others, simply ask some basic questions about scalability of such
solutions, their complexity, and their ability to be "gamed", and then they
never go anywhere because there simply aren't any good answers to those
questions.  Thinking I might be wrong, and since the same people insist I
am, I published RFC6541 (ATPS) as an experimental draft to try to tackle
the third-party problem, and made a free version of it available via open
source.  That was over three years ago.  There has been exactly one site
(one person, rather) that tried it besides me and reported back about its
effectiveness.  Though Doug will shortly claim that ATPS saw no uptake
because it is "flawed", I also had a grand total of zero operators report
that they were using it in any modified form or asking me to add this or
that to it before they would deploy it to production.  It wasn't just an
idea, it was a reality, but nobody came to play.

Policy and third-party solutions haven't failed because of some cabal
keeping them from seeing the light of day, unless by "cabal" you mean
"group of people who agree that this won't work."

These are hard problems, and the last thing any of us should want to do is
foist yet another blob onto the global email infrastructure that has not
been properly vetted.  If an idea doesn't stand up to scrutiny or gets no
uptake, or can't even get consensus in a small working group, what prayer
does it have for success on the greater Internet?  I want to make things
better, not worse.

There are those among you that disagree, I know.  Does anyone have actual
data (not theory, not passion, but data) that any of the policy or
third-party solutions we've discussed before can work, work just about
everywhere, and work at scale?  If the answer to that is "no" (or, as
usual, silence), then I suggest this (still!) isn't a productive use of our
precious time or energy.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 27 Mar 2015 00:02:08 -0700

> usual, silence), then I suggest this (still!) isn't a productive use of our

...by which I mean we should really not spend any more time re-hashing the
past, and instead focus on figuring out the future.  I'm all for learning
from our past mistakes, but I think we've gotten all the blood we're going
to get out of that particular stone.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 27 Mar 2015 16:40:23 +0900

Murray S. Kucherawy writes:

 > Does anyone have actual data (not theory, not passion, but data)
 > that any of the policy or third-party solutions we've discussed
 > before can work, work just about everywhere, and work at scale?

Speaking only for myself, at this stage I would accept *theory* that
it *can work*, with the caveat that it must be accompanied by an
analysis of all possible failure modes, and preferably with
(theoretical :-) mitigations for the failures.  I haven't seen
anything like that, just handwaving about "if we implement the policy
framework, spam will go away and the mailing lists will have to come
to heel (ie, register with the author domains for 3rd party auth)."

Again speaking for myself, I think it's inappropriate to ask for data
about working at scale at this point (although that's a bridge that
eentually needs to be crossed).

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 27 Mar 2015 16:30:25 +0900

Franck Martin writes:

 > Hard Bounce: "no such mailbox/user/email address here" (SMTP
 > enhanced status code, like 5.1.1), usually a permanent failure
 > Soft Bounce: "there may be a valid mailbox/user/email address here,
 > but we are not accepting this email" (SMTP enhanced status code
 > like 5.7.1), a permanent or temporary failure

That's not the terminology we use around Mailman: a "hard bounce" is
exactly a "permanent failure".  I'll keep it in mind that you at least
use the term differently here.

Nor is the "soft bounce" as you define it useful if it is permanent
(5.x.x).  Even if the site admits it's a policy bounce, you have to
parse the error text in hope of determining whether there's something
wrong with the message (the next message might go through, even from
the same author), or if the receiver doesn't like the mailing list
(messages aren't going to go through period) or doesn't like the
author (the next message might or might not go through, depending on
the author).  And usually it's useless for the purpose, so has to be
passed on to the site admin for forensic analysis.

And even that doesn't help with sites that deliberately don't use
appropriate codes.  I don't really see that (from a protocol
standpoint) we're any better off than we were before the enhanced
status codes for the purpose of determining whether to stop mail to or
unsubscribe a bouncing address.

---

From: Michael Jack Assels <[email-masked]>
Date: Fri, 27 Mar 2015 09:49:32 -0400

On Fri, 27 Mar 2015 15:22:04 +0900, 

> than the receiver's mailbox users should care what the receiver

Right, but that leaves DMARC as just another factor to consider when
calculating a spam score.  Actually, it's a little better than that;
it comes pretty close to the desired "really reliably reliable" for direct
mail flows. 

> messages to be delivered.

As I read it, that means AOL and Yahoo are taking the position that
DMARC's p=reject is The Right Thing To Do, while accepting that it's
going to give wrong answers for indirect mail flows, and that it's up
to MLM developers (and other producers of indirect flows) to deal with
it.

>     accept all responsibility for nondelivery and collateral damage if

I can accept that that may be what p=reject means, but I can't take
seriously the idea that domain owners with p=reject really do take
all responsibility for nondelivery of legitimate messages.  When
one of my users bangs on my door demanding to know why her message
message wasn't delivered, can I really refer her to a giant ESP for
an explanation?  I don't think so.

I'd be happier to interpret "p=reject" as meaning

    Spoofing is a serious problem.  With a very high degree of certainty,
    we assert that the message you're handling is not legitimate direct
    mail.  Please take this into account when deciding whether to accept
    or reject the message.

This is worth a lot, despite the fact that it leaves the receiver with
two tasks:  Determining the message is direct or indirect, and if indirect,
determining whether it's legitimate.

> in daily use by financial institutions and in other transactional mail

I agree that absolute proof of illegitimacy for arbitrary messages is
hopeless, but DMARC actually provides a decision procedure for legitimacy
of in the restricted area of direct mail flows (assuming that mail from
compromised accounts is "legitimate").  For DMARC participants, legitimacy
and illegitimacy are equally easy to prove for transactional mail flows,
and equally hard to prove for indirect flows.

MJA

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 28 Mar 2015 04:07:51 +0900

> to MLM developers (and other producers of indirect flows) to deal with

First, I don't think that interpretation is tenable, because their
explanations to us are along the lines of "we know that we're a little
out of line, but we have no choice."

Second, the relevant producers of indirect mail flows are not the
MLMs.  They generally produce a direct mail flow, albeit unaligned.
It's the mailbox provider's own users who produce indirect mail flows,
by posting to the mailing lists.

 > an explanation?  I don't think so.

No, of course you can't, because they'll tell her that's not what they
intended, and that it wouldn't be a problem if the third party behaved
well.  However, you can tell her that the giant provider told the
receiver not to accept her messages.  That's what DMARC actually says,
and that's why I phrase it "accept reponsibility".

 >     mail.  Please take this into account when deciding whether to accept

There's only one problem with that interpretation, and that is that
you don't need DMARC p=reject to make it: it's a logical deduction
from the mere fact of lack of From alignment.

 > For DMARC participants, legitimacy and illegitimacy are equally
 > easy to prove for transactional mail flows, and equally hard to
 > prove for indirect flows.

That's actually false.  There are many indirect flows that don't cause
signatures to be invalidated, such as Unix-style .forwards and GNU
Mailman mailing lists configured with no subject tag, no header, and
no footer.

And that's where the shoe pinches for mailing lists: the absolutist
advocates of sender policy blame the victim and say we should stop our
traditional value-added practices so that posters from p=reject
domains can have their posts delivered.

---

From: "J. Gomez" <[email-masked]>
Date: Fri, 27 Mar 2015 21:12:19 +0100

On Friday, March 27, 2015 12:12 AM [GMT+1=CET], Michael Jack Assels wrote:

> > > That is why, in my view, DMARC's p=reject has to either be
> > > reliable to be relied on, or be suppressed from DMARC's formal
> > > specification if it is going to mainly be equal to p=do-whatever.
> > 
> > Can anyone point to a single instance of a sender-receiver policy
> > protocol that was "reliable" by this definition, enough that
> > receivers would blindly agree to do whatever the sender
> > asked/suggested/demanded? 
> > 
> > I can't think of any.  Some, many, or most of them were supposed to
> > be, but it has never turned out that way.  I don't know why DMARC
> > is being held to a different standard.
> 
> supposed to do with unaligned mail whose "From:" domain specifies
> p=reject? Clearly, the domain owner is explicitly asking that the
> message be rejected.  If DMARC intends that this be merely one of
> many factors to consider, then doesn't it boil down to nothing more
> than p=do-whatever?

+1.

As it currently is, p=reject already means p=quarantine or p=none, so "do-whatever".

We could try to add some extra --and defaulted to be empty/none-- qualifier to the DMARC TXT record in order to optionally, at the Sender's will, upgrade the plain old p=reject to mean "reject-and-yes-i-mean-it-always-dammit-i-dont-indulge-in-indirect-email-flows", so that Receivers can get that extra info from the Sender and therefore be able to guess, with more certainty, that said Sender does indeed has all his ducks neatly in a row when he publishes p=reject; but the proposal to do so has already seen very negative reception, repeatedly, so I will not insist on it anymore.

> asserted.  The problem is that publishing p=reject effectively
> asserts that almost all submissions to mailing lists by users in the
> domain are illegitimate, and I'm afraid the real world doesn't
> believe that to be the case.

+1.

Some argue p=reject is fine as it stands and that the problem is just that Yahoo and AOL are abusing it. But the real world is as it is, and at the end of the day after all has been said it does not matter if the real world is abusive or not, we still have to interoperate with it.

Regards,
J.Gomez

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 27 Mar 2015 16:50:35 -0400

On Friday, March 27, 2015 09:12:19 PM J. Gomez wrote:
> We could try to add some extra --and defaulted to be empty/none-- qualifier
> to the DMARC TXT record in order to optionally, at the Sender's will,
> upgrade the plain old p=reject to mean
> "reject-and-yes-i-mean-it-always-dammit-i-dont-indulge-in-indirect-email-fl
> ows", so that Receivers can get that extra info from the Sender and
> therefore be able to guess, with more certainty, that said Sender does
> indeed has all his ducks neatly in a row when he publishes p=reject; but
> the proposal to do so has already seen very negative reception, repeatedly,
> so I will not insist on it anymore.

Looked into this once before for SPF (which despite the hand wringing here has 
been through a lot of these same policy considerations before).  There's no 
point in adding a "I really mean it" flag since nothing prevents a sender from 
adding it even if they don't.  

Eventually enough domains that perhaps shouldn't publish the "I really mean it 
flag" the receivers want a "NO, I REALLY, REALLY mean it" flag.  Pretty soon 
it's added flags all the way down.

In the data I see, I see some receivers overriding p=reject and using 
p=quarantine for some set of the mail they think is indirect.  Mostly though 
the policy applied is p=reject for a domain that publishes that policy.

Scott K

---

From: Michael Jack Assels <[email-masked]>
Date: Fri, 27 Mar 2015 20:49:42 -0400

On Sat, 28 Mar 2015 04:07:51 +0900, 

> out of line, but we have no choice."

So it's more like "p=reject is The Wrong Thing To Do, and it's up to
you to deal with it"? :-)

> by posting to the mailing lists.

You're right.  "Producers" was certainly the wrong word.  I should have
said "players" or "participants" -- entities involved in indirect flows.

> and that's why I phrase it "accept reponsibility".

Actually, there's some ambiguity of emphasis in Section 6.3 of RFC7489:

   p: Requested Mail Receiver policy (plain-text; REQUIRED for policy
      records).  Indicates the policy to be enacted by the Receiver at
      the request of the Domain Owner. [...] Possible values are as
      follows:

   [...]
      reject:  The Domain Owner wishes for Mail Receivers to reject
         email that fails the DMARC mechanism check.

A "policy to be enacted by the Receiver at the request of the Domain Owner"
sounds compulsory, while "[t]he Domain Owner wishes for Mail Receivers to
reject email" sounds optional.  I'm pretty sure my boss will go with
"optional" for mail that we receive.

> from the mere fact of lack of From alignment.

That's right.  The Domain Owner's policy becomes a consideration if, and
only if, there's a lack of From alignment.  Otherwise everybody's happy.
But notice that the hypothetical Domain Owner who makes me happy (a) is
only certain that the message is not legitimate *direct* mail, and (b) is
asking me to take that into account.  In an earlier message, you wrote
that a receiver would have to be crazy not to reject a direct message that
had no From alignment, and I'm just sane enough to agree.  What I don't
like is the idea that DMARC-failed *indirect* mail should be rejected
solely on the From Domain Owner's say-so.  I'm willing to consider
rejection as a default option if other factors don't indicate the message's
legitimacy, but please leave me the freedom to consider other factors
without falling into the "RFC-ignorant" category.  (Is this message a
mailing list post?  Is the SMTP client one of the SPF-authorized mailers
for the mailing list's domain?  Does the list appear in my database of
legitimate mailing lists?)

> Mailman mailing lists configured with no subject tag, no header, and

I didn't mean that you can't prove legitimacy or illegitimacy for any
indirect flows, only that there doesn't exist a reliable method of proving
either in all cases, the point being that there are plenty of cases of
DMARC-failing legitimate indirect mail to match the DMARC-failing
illegitimate indirect mail.

> domains can have their posts delivered.

Amen!

MJA

---

From: Hector Santos <[email-masked]>
Date: Mon, 30 Mar 2015 04:46:01 -0400

Murray,

Thanks for your comments. The key difference today is that we have 
finally achieved the long term engineering considerations of:

   1) Getting domains to publish DNS policy records,
   2) Receivers performing the DNS policy record lookup,
   3) Receivers honoring the mail handling.

We did not have this with ADSP when ATPS was first introduced as an 
extended ADSP add-on.  ADSP, the DKIM WG proposed standard track item, 
was in conflict with what we reestablished today as "indirect mail 
flows" and the key cogs of the DKIM WG was focused on eliminating the 
Author Domain Identity (ADID) from the specification and making 3rd 
party Trust Signers (SDID) the key focus identity for DKIM evaluation. 
  ADSP was being abandoned and you help kill it by eventually 
replacing it with DMARC.

If you redid ATPS as an add-on DMARC, I suspect we will have a higher 
interest in its exploration.   The marketing and need would be much 
higher than before.  It will certainly push forward our own update 
efforts (Replaced ADSP with DMARC and I would like believe other mail 
product and EPS vendors, including MLS developers would also would 
update DMARC to support a new SDID (Signer Domain Identity) optional 
parameter in the DNS policy record lookup:

       DMARC = DKIM_POLICY_DMARC(ADID [,SDID])

We are already doing the lookup as a function of ADID. We established 
that. Thats the difference today than yesteryears.  Now we just 
proposing to make it flexible for the 3rd party signature condition 
when the ADID != SDID.

We also long established, which I believe all the trust advocates 
agreed, that resigners are good.  They are needed when the original 
authenticity is lost, i.e MLM.

Will the vendors support it?    Who knows? But the market is different 
today and that is all I am saying, you can't judge the lack of 
interest before because ADSP was being abandoned.   DMARC is not being 
abandoned.  It now needs to be completed with that 3rd party component.

I suggest a simple update of ATPS to anchor off DMARC and see if we 
will get the exploration.  You will get two immediate packages to 
support it.  Yours and mine.

If in the mean time, you come up with something better, great. I don't 
see it because it will always need to be verifiable with the 1st party 
again, but now we will be able to explore all the scalability issues. 
  I personally don't think the the non-ESP domains will need to worry 
about that.   Perhaps the biggest challenge for the larger ESP is how 
to best register the domains.   But thats an implementation issue, 
perhaps using a Web site with other business decisions such as free or 
fee-based.   Let the each market vendor decide that. In the mean time, 
we need the 3rd party Authorization extension for DMARC.

Thanks

--
HLS

On 3/27/2015 2:59 AM, Murray S. Kucherawy wrote:
> On Thu, Mar 26, 2015 at 11:22 PM, Stephen J. Turnbull
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Put another way, you only really know something when DMARC, DKIM, SPF,
> etc. produce a passing result.  (Due credit to Dave for this
> observation.)  All of them have false negatives with respect to
> anything that's not a direct mail flow, so "fail" results don't tell
> you anything conclusive if you plan to accept any sort of mail that
> isn't direct.  What Hector characterizes as a watering down of SPF
> with the publication of RFC7208 was merely this fact put into text,
> even though it's been true since RFC4408.
>
>     Footnotes:
> influence to me, I'm not the one standing in the way of their
> success.  I would happily embrace any such solution that stood a
> chance of working.  I, and others, simply ask some basic questions
> about scalability of such solutions, their complexity, and their
> ability to be "gamed", and then they never go anywhere because there
> simply aren't any good answers to those questions.  Thinking I might
> be wrong, and since the same people insist I am, I published RFC6541
> (ATPS) as an experimental draft to try to tackle the third-party
> problem, and made a free version of it available via open source.
> That was over three years ago.  There has been exactly one site (one
> person, rather) that tried it besides me and reported back about its
> because it is "flawed", I also had a grand total of zero operators
> report that they were using it in any modified form or asking me to
> add this or that to it before they would deploy it to production.  It
> wasn't just an idea, it was a reality, but nobody came to play.
>
> These are hard problems, and the last thing any of us should want to
> do is foist yet another blob onto the global email infrastructure that
> has not been properly vetted.  If an idea doesn't stand up to scrutiny
> or gets no uptake, or can't even get consensus in a small working
> group, what prayer does it have for success on the greater Internet?
> I want to make things better, not worse.
>
> There are those among you that disagree, I know.  Does anyone have
> actual data (not theory, not passion, but data) that any of the policy
> or third-party solutions we've discussed before can work, work just
> about everywhere, and work at scale?  If the answer to that is "no"
> (or, as usual, silence), then I suggest this (still!) isn't a
> productive use of our precious time or energy.
>
> -MSK
>
>

-- 
HLS