Subject: [dmarc-ietf] milestone 1 *almost* done

From: Tim Draegen <[email-masked]>
Date: Fri, 21 Nov 2014 12:56:30 -0500

WG,

The work found here:

  http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki <http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki>

..is almost complete.  However, there is a note (reinforced by feedback during the recent in-person meeting) to recast the collected issues in terms of RFC 5598.  Once this recasting is done, Milestone 1 will be officially met.

If you’re handy with the language found in RFC 5598, please consider helping out.  Getting the language correct now will only make everything better later on.

Co-chair,
=- Tim

PS.  A group of editors spontaneously formed during the in-person meeting.  The group will tackle Milestone 2 — which is to transform issues learned and documented in Milestone 1 + proposed solutions for each into a real reviewable draft.  This is not a closed group, so if you’d like to be actively involved, just say so.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 21 Nov 2014 10:50:54 -0800

> PS.  A group of editors spontaneously formed during the in-person meeting.  The group will tackle Milestone 2 — which is to transform issues learned and documented in Milestone 1 + proposed solutio…

Dear Tim,

Please include me in the solution discussions.

Regards,
Douglas Otis

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 21 Nov 2014 19:54:37 +0100

On 11/21/2014 06:56 PM, Tim Draegen wrote:
> WG,
>
> The work found here:
>
> http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki
>
> ..is almost complete.  However, there is a note (reinforced by 
> feedback during the recent in-person meeting) to recast the collected 
> issues in terms of RFC 5598.  Once this recasting is done, Milestone 1 
> will be officially met.
>
> If you’re handy with the language found in RFC 5598, please consider 
> helping out.  Getting the language correct now will only make 
> everything better later on.
>
> Co-chair,
> =- Tim
>
> PS.  A group of editors spontaneously formed during the in-person 
> meeting.  The group will tackle Milestone 2 — which is to transform 
> issues learned and documented in Milestone 1 + proposed solutions for 
> each into a real reviewable draft.  This is not a closed group, so if 
> you’d like to be actively involved, just say so.

does this mean that any work/solutions will not be discussed on this 
list, before a reviewable draft is ready? If so, please add me to the 
discussion group.

/rolf

---

From: Tim Draegen <[email-masked]>
Date: Fri, 21 Nov 2014 13:54:44 -0500

> Please include me in the solution discussions.

Hi Doug,

Discussion of solutions will happen on the mailing list -- I was referring to the act of cramming the good bits of the discussion (text, edits, making sure people aren't duplicating sections) into a draft.  

If you're NOT interested in editing, it will be business as usual on the WG list.

=- Tim

---

From: Tim Draegen <[email-masked]>
Date: Fri, 21 Nov 2014 13:56:44 -0500

> On Nov 21, 2014, at 1:54 PM, Rolf E. Sonneveld <[email-masked]> wrote:
> 
> does this mean that any work/solutions will not be discussed on this list, before a reviewable draft is ready? If so, please add me to the discussion group.

No, I was not clear.  Discussion of solutions will happen on the mailing list -- I was referring to the act of cramming the good bits of the discussion (text, edits, making sure people aren't duplicating sections) into a draft.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 21 Nov 2014 18:29:26 -0800

Dear Tim,

There are serious concerns being ignored regarding email captured in DMaRC feedback.  Things like Intuit invoices or mailing-list conversations are being misdirected simply because DMaRC incorrectly assumes a sender/recipient relationship when general use email providers assert restrictive DMaRC policies.  DMaRC policies that require From header field alignment with the sender inhibit the forwarding of email and dismiss Sender header field contents as being potentially deceptive to justify ignoring this field in the determination of direct "mail flows".  It is incorrect to suggest an RFC compliant message which accurately indicates the third-party sender somehow grants DMaRC protocol permission to misdirect these messages.  Even Microsoft enabled special provisions to handle Sender header fields in their MUA, and most MUAs can be configured to display Sender header fields when necessary.  SMTP's agility is afforded by its store-and-forward nature.  However this often relied upon agility is seriously damaged by DMaAC's short-cut of ignoring the defined role of the Sender header field.

While a provider is free to condition acceptance on any dubious characteristic, this does not include redirecting accepted messages to destinations neither specified by senders nor recipients. 

I have tools to construct drafts and am willing to generate text.

Regards,
Douglas Otis

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Sat, 22 Nov 2014 17:43:07 +0900

Douglas Otis writes:

 > There are serious concerns being ignored regarding email captured in
 > DMaRC feedback.  Things like Intuit invoices or mailing-list
 > conversations are being misdirected simply because DMaRC incorrectly
 > assumes a sender/recipient relationship when general use email
 > providers assert restrictive DMaRC policies.

So do you propose something like

    Author Domains which impose policies that can result in failure
    reports being sent MUST have Terms of Service in which mailbox
    users agree that content of messages which fail DMARC checks may
    be forwarded to the Author Domain as part of failure reports.
    This includes messages that they have originated which are
    unauthorized according to the definition of DMARC.

Or however you say that in IETF-ese?

 > DMaRC policies that require From header field alignment with the
 > sender inhibit the forwarding of email and dismiss Sender header
 > field contents as being potentially deceptive to justify ignoring
 > this field in the determination of direct "mail flows".

Isn't that backward?  DMARC focuses on From alignment *because* in
typical MUA configurations Sender is not visible to the receiving
user, and in any case would be unlikely to be useful in counteracting
phishing and recommended-by-a-friend spam.  That is, I don't see how
verifying Sender would be useful.  True, if you verify Intuit as the
sender of mail on behalf of a billing company, the user seeing Intuit
in Sender would likely come to an appropriate conclusion.  But if you
verify example.com as Sender, the user doesn't know who they are, and
in most cases I would expect them to simply ignore that information
and rely on From and any clues in the message content.

 > However this often relied upon agility is seriously damaged by
 > DMaAC's short-cut of ignoring the defined role of the Sender header
 > field.

It's not a shortcut.  Sender has the wrong semantics for combatting
phishing and recommended-by-friend spam.

 > this does not include redirecting accepted messages to destinations
 > neither specified by senders nor recipients.

This is not a problem restricted to DMARC.  Any protocol that involves
forwarding a message to a third party (eg, the Sender field or
Return-Path) raises this issue (eg, in the case of a typo in the
recipient mailbox name).  It's true that DMARC seems designed to cause
such problems.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 24 Nov 2014 17:42:03 -0800

>    unauthorized according to the definition of DMARC.

Dear Stephen,

Consider invoices sent by Intuit on behalf of users who have an email address obtained in conjunction with their Internet access who are seeking financially related services.  These messages are not spoofing the source accurately indicated by Sender header fields as defined by RFC5322.  Why assume these entities assigned an email address by their access provider intended their service related messages be insecurely mis-directed to access providers instead of the intended recipients?

In the case of legitimate third-party services, these messages are not the property of the access provider. They are owned by the author assigned the email address seeking these services.  Failing DMaRC with a message that has a valid and reputable domain aligned with the Sender header field domain is unlikely malicious or in violation of any recognized protocol standard.  DMaRC related redirection of these valid and legitimate messages disrupts vital services, such as forwarding and use of third-party services in common use for decades.  The disruption of these services clearly indicates DMaRC is incompatible with SMTP by neglecting consideration for sender agents not aligned with the email-address provider.

Rather than issuing click through agreements to in essence say "All your email must represent direct transactions from the provider." they could offer users a friendly SMTP compatible and safe solution that provides MUA configurations that expose aligned Sender header fields in lieu of aligned From header fields.  This could be coupled with DMaRC record that offers this exception.  With a simple change, their customers are protected and afforded the agility SMTP normally allows.  This could be signaled by making specific authorizations such as those proposed in TPA-Label or by defining an a DMaRC assertion which indicates TP=PSS or TP=PSR for Sender header field strict and relaxed, or defines an excepted group syntax which safely permits a highly visible exception made using group syntax indicated with DMaRC assertions TP=G and perhaps combined with TP=PSR,G.
 
> and rely on From and any clues in the message content.

DMaRC makes an erroneous assumption incompatible with SMTP in the case of user email accounts.  Besides, DMaRC can not prevent all spoofing and makes future improvement problematic.  It would be wrong to characterize Mailing-list traffic as being spam friendly or something most users are unable to recognize and properly handle.  Where the user sending a message is critical, they can be S/MIME or OpenPGP signed, but nevertheless these safer solutions are not recognized by DMaRC. 

> phishing and recommended-by-friend spam.

We have handled a fair amount of DKIM related malicious traffic exploiting trivial spoofing DKIM permits.  This was giving users a false sense of security where the problem was clearly noted in the Won't Fix DKIM ticket 24 in May of 2011.  It took until May of 2014 for a fix to be implemented by one of the world's largest providers.  Those following DKIM deployment documents along with those waiting to be published for DMaRC seem destine to ensure mistakes remain likely because logical processing errors are never admitted, given clear warning, or directly fixed without added overhead.  

A false sense of assurance remains a concern for SPF heavily exploited by Kelihos botnets, for example.  Neither SPF nor DKIM can be used to hold domains sending malicious email accountable because neither authenticates actual sources.  Authenticating the source by domain is the only practical way to combat phishing that remains impractical when using just DKIM or SPF.  Misguided DMaRC requirements are attempting to force standardization on weak protocols destined to prolong abuse and associated damage.  Lawsuits related to abuse blocking often involve substantial sums where evidence must be rock solid.

> recipient mailbox name).  It's true that DMARC seems designed to cause

DMaRC along with DKIM and SPF were carefully designed to avoid authenticating domains often well compensated for having sourced abuse.  Despite such an obvious defect in these plutocratic schemes, almost every related authorization reporting method erroneously includes Authentication in their title.  What is standing the the way of DANE deployment for both client and server?

Regards,
Douglas Otis

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 25 Nov 2014 19:49:25 +0900

Douglas Otis writes:

 > Rather than issuing click through agreements to in essence say "All
 > your email must represent direct transactions from the provider."
 > they could offer users a friendly SMTP compatible and safe solution
 > that provides MUA configurations that expose aligned Sender header
 > fields in lieu of aligned From header fields.

I think implementing this suggestion would a disservice to the users
at both ends.  The requisitioning author (a business) wants *her*
address, not the 3rd party's (Intuit's) address visible.  The
recipient *also* wants to see and has a trust relationship with the
requisitioning author, not with Intuit.  This is not about MUAs
AFAICS, it's about how an Author Domain can tell a recipient MTA
(DMARC verifier) that a particular sending MTA may use the Author
Domain in From.

This needs no help from the MUA (unless it's a DMARC verifier itself),
and need not be visible at all to the user.

 > What is standing the the way of DANE deployment for both client and
 > server?

Money and competent sysadmin time sound like candidates to me.

---

From: Hector Santos <[email-masked]>
Date: Tue, 25 Nov 2014 08:35:01 -0500

> everything better later on.

Hi Tim,

I did participate and was acknowledged in the production of RFC5598. 
Since I like to get my main points out of the way, here goes.

One of my very few concerns at the time I envisioned during RFC5598 
production is that its used SIEVE as its baseline "IETF" standard 
language for hooking in scripts.  Understood, the email architectural 
document wanted to cover IETF sanctioned protocols and documents.

Thats not the case in reality with different system using different 
server-side hooking language. In addition, it made an assumption that 
POST SMTP (after the mail is accepted) processing was the way things 
were done. See Figure 5: "Protocols and Services."  When RFC5598 was 
produced "SPF" was still a "TABOO" among the IETF key cogs. It was a 
new "experiment" so clearly it was not going to get the attention it 
needed for an example of SMTP dynamic processing (before acceptance). 
  It is a known fact, many of the key IETF folks were against SPF at 
the time.

So the idea of spawning a job, shim, hook, what have you off SMTP 
states was still something that was still not widely acceptable. You 
had to be an advanced package to do this, a more nimble 
package/vendor/service to explore the more modern stuff.   In fact, 
some folks was surprised to learn, dynamic SMTP filter processing was 
indeed increasing in practice when SPF was becoming more popular and 
DKIM itself began to be deployed at the DATA state hence raising 
issues about increasing SMTP session TIME delays.   Major discussions 
about this about delaying/scaling high throughout systems.  We have an 
very old RFC that raise that point about increasing sessions time that 
could cause SMTP client drops to occur, hence concerns about dupes, 
etc.  I felt that better hardware and speeds was changing all this 
which is why DKIM and DMARC are now possible at DATA today.

SIEVE, at the time, also didn't have DNS lookup capabilities so that 
would need to be added to the SIEVE language if it wants to be used as 
an example IETF sanction scripting tool for add-on protocols, like 
SPF, DKIM and DMARC, and even DNS RBL stuff.

In short, RFC5598, nearly a 10 year old document itself, does need 
updating itself to FIT the more modern DYNAMIC SMTP level and data 
filtering models in existence today.   The SIEVE description in 
section 4.1.0 added at the time, I considered "open-ended" enough to 
not be terribly locked down, but it does need updating.  RFC5595 needs 
to be more open-ended in this regard.

The whole idea of how any SMTP LEVEL FILTER and/or POST SMPT (POST 
ACCEPTANCE) FILTER is done should be talked about at length because 
that is how its going to be different among systems, including whether 
or not they can actually do the stuff we want to do with a multiple 
protocol add-on DMARC Policy layer.   Just consider what the 
programmers are using for the scripting tools.  You are seeing LUA out 
there now.  But you are not going to see that with other systems. It 
shouldn't matter what they use, all this needs to be generalized. But 
the key point, not all of them is going to be using SIEVE.

> you’d like to be actively involved, just say so.

I prefer to review the ideas before they are written and burned in 
stone, because if there is one thing I learn among the authors here, 
once its written, its very hard to correct at that point.  Too high a 
burden. Many of the key problems we have today with DKIM is because of 
exactly this point, the document were changed and it was now a higher 
burden to make the corrections, i.e. the importance and exclusion of 
the Author Domain Identity from the DKIM specification, getting that 
idea back into the equation was lost, hence the problem we have today.

DKIM is a TRUST document.  DMARC is about SELF-SIGNING POLICY 
document. I also consider SPF a DOMAIN POLICY specification.  DKIM 
excluded the self-signing part (when the IETF draft standard was ADSP) 
and was left only with TRUST model.   Ideally that fine, but think 
code.  If one is only looking at DKIM, SPF and not ADSP, oops, I mean 
DMARC, then passing the author to the filtering components is less 
important.  Designers need to know, the author identity is part of the 
software interfacing and that means DATA and/or POST SMTP processing. 
   DKIM itself SHOULD be updated (perhaps an errata) to get the model 
corrected for passing the one required binding header 5322.From passed 
into the assessment model.

-- 
HLS

---

From: Douglas Otis <[email-masked]>
Date: Tue, 25 Nov 2014 17:36:18 -0800

Dear Stephen,

Sorry for not being clear.  In the example given, this assumes a third-party service might be for a small outfit operating on a thin budget using an accounting firm to send messages on their behalf.  Messages being sent may include a small outfit's email address assigned by their Internet provider in the From header field as permitted by RFC5322.  Only by including known entities in the From header field will intended recipients be able to recognize their relationship with the author (the defined role of the From header field).  To permit third-party services, it is also absolutely essential to recognize the role of Sender header fields as a means to properly retain the role of the From header field.  

To be compliant with SMTP, policy must permit acceptance of Sender header fields representing the agent responsible for message transmission per RFC5322.  This scenario could apply in any number of situations, nor should this be dismissed with a suggestion there are From header field re-write work-arounds to deal with DMaRCs' disruption which defeats the explicit role of the From header field and ignores the role of the Sender header field.  Whether for mailing-lists such as this, financial services by an accounting firm, or the forwarding of messages from alumni accounts, the whole email address in the From header field plays a vital role and MUST NOT be considered to represent the property or the brand of the provider.  The email address represents the inbox of the individual author.

Only by allowing policy alignment acceptance based on the Sender header field, especially for domains providing general email service, the From header field containing the recognized entity would be displayed as it is now, in addition to an aligned Sender header field indicating that the message past through the third-party service.  Mailing-lists often ensure their role is clearly indicated by adding tags in the Subject header field, but this can also be done using Outlook's "on behalf of" which combines the Sender header field together with that of the From, or simply displaying the Sender header field which is often an option available in the MUA.

What was meant by "in lieu of aligned From header fields" was to permit acceptance based on the Sender header field as well. The TPA-Label scheme can also offer the mechanism you described.

> and need not be visible at all to the user.

Disagree.  Asserting policy that attempts to minimize successful spoofing of transactional domains is being misapplied when solely based on the From header field against domains that offer general purpose email services as defined by RFC5321/RFC5322 et al.  Displaying the Sender header field as an additional field, or in the form of "on behalf of", would make successful phishing far less likely.  TPA-Label can be used to ensure good actors are accepted while being less dependent on caution asserted by recipients.  This is a service we would be willing to offer a large provider to demonstrate the practicality and the scalability of this approach.  The goal is to retain the agility and utility that had been offered by email.

As it currently stands, the only quick fix for the abusive misuse of DMaRC policy has been to change "reject" to "quarantine".  Another remedy might be to systematically include the Sender header field in alignment assessments where the domains then need to ensure the proper display of the message source.

Regards,
Douglas Otis

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Wed, 26 Nov 2014 13:23:40 +0900

Douglas Otis writes:

 > Sorry for not being clear.  In the example given, this assumes a
 > third-party service might be for a small outfit operating on a thin
 > budget using an accounting firm to send messages on their behalf.

The use case is well-understood.  I wish you'd stop assuming people
have no clue.

 > To permit third-party services, it is also absolutely essential to
 > recognize the role of Sender header fields as a means to properly
 > retain the role of the From header field.

Nobody has ever suggested anything else.  In particular, DMARC does
not deprecate the Sender field in any way.  DMARC is based on the
hypothesis that phishing is most dangerous when the user believes that
the *author* of a message is a familiar entity.  That author is the
entity in the From field, not anywhere else.

That "From is author" (who may have delegated content creation to a
third party as in the use case above, but who remains responsible for
that content) is the RFC specification, my personal practice, and
strongly supported by years of experience on Mailman channels with
users confused by Outlook's "on behalf of" presentation.  These users
often understand "on behalf of" to mean that Sender is the author, and
believe that the author is no longer responsible for content.

That phishing is most facilitated by spoofing the From field seems
plausible to me, but as I see it your task is to convince Yahoo! and
AOL, not me and not the IETF.  Or perhaps you can sell third-party
sender auth to banks and government agencies who want to allow their
representatives to participate in mailing lists like this one with
their "official" addresses, and maybe Yahoo! and AOL will go along.

 > Whether for mailing-lists such as this, financial services by an
 > accounting firm, or the forwarding of messages from alumni
 > accounts, the whole email address in the From header field plays a
 > vital role and MUST NOT be considered to represent the property or
 > the brand of the provider.  The email address represents the inbox
 > of the individual author.

It does not.  It represents whatever the terms of service for the
inbox say.  This is a problem of contract law, not of the email
protocol.  DMARC does not take a stand on terms of service AFAICS, but
does warn that "p=reject" is inappropriate when those terms provide
that the email address denotes a personal inbox.

I agree with you that failure of DMARC to provide for cases where
authentication of Sender would provide information useful to the
recipient is a major issue.  However, I don't see how DMARC deprecates
such authentication in any way.

The reason it hasn't been developed, I believe, is that the banks
don't need it and AOL and Yahoo! are pretty sure it would entail large
on-going costs if it existed so they would not use it, either.  If you
have a protocol that can provide authentication for third-party
senders, go sell it to Yahoo! and AOL.

 > Disagree.  [...]  Displaying the Sender header field as an
 > additional field, or in the form of "on behalf of", would make
 > successful phishing far less likely.

Do you have evidence for that?  My experience says that displaying the
Sender field would probably confuse many users who clearly do not know
the difference between "From" and "Sender", while I *know for a fact*
that "on behalf of" engenders such confusion.  I see no reason to
suppose such confusion would reduce the effectiveness of phishing.

 > TPA-Label can be used to ensure good actors are accepted
 > while being less dependent on caution asserted by recipients.

I'm sure it can.  But nobody cares what I think, except a few of my
friends.  What matters is what "p=reject" abusers think.  Go forth and
sell to *them*!

Note well: they are not participating in this debate on this list.  I
know what conclusion I draw from that.

http://snoopyandthegang.weebly.com/page-14.html