Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection

From: Douglas Otis <[email-masked]>
Date: Sun, 1 Jun 2014 19:56:42 -0700

Dear Hector,

See comments inline:
On May 30, 2014, at 4:44 PM, Hector Santos <[email-masked]> wrote:

> On 5/30/2014 5:49 PM, J. Gomez wrote:
> 
>>> Ah, but "just like" is a complete misstatement of the situation.
>>> There's a big difference.  Users on a mailing list think of the
>>> poster, not the mailing list, as responsible for the content.  So
>>> according to RFC 5322, the poster's mailbox belongs in From:.
>>> Remailed or not, the author belongs there.
>> 
>> That is debatable. As long as the mailing list program tampers with the message's content, rendering its DKIM signature invalid, it can be argued that the mailing list program is rewriting the message's content, and therefore that the mailing list program now becomes "the system responsible for the writing of the message" (as per RFC 5322 parlance, section 3.6.2), and thus the mailing list address would earn its legitimate place in the Header-From field, making interoperability with rogue DMARC Senders a solved problem.
> 
> In my book, this is mail tampering. It will be hard to justify adding support for this radical behavior in our mail list server product which puts customers at risk.  You are putting yourself at product liability risk but intentionally defying a security protocol against the wishes of the publishing restrictive domain.  Of course, its only becomes a problem when its used as a loophole to further spread harmful mail and someone actually gets harmed.  Thats all you have to prove in a courtroom.   If you had all the tools before you to tell you definitively, "This is unauthorized mail"  and you intentionally, deliberately and neglectfully ignore it, do nothing about it but further distribute to end points, well, who knows what a young punk, tech savvy, high tech, new age lawyer will think about suing you.  If you got deep pockets, well, don't think it can't happen.
> 
> It is this sort of mentality that completely makes this old game no more fun to work with. Seriously.
> 
> We can do it right.  All we have to do is LOOKUP the policy and follow it.  Give the YAHOOs the tools to authorize the resigners and you and I won't have these new ethical problems to content with.

It seems wrong to describe a mailing-list adding Subject Tags, List Footers, while retaining the From header field so people have an easer task of knowing who is talking and at reviewing past conversations as putting recipients in grave risk.  Causing a massive number of people to find different email providers so they can retain their effectiveness at using a mailing list is far more likely to create risk simply due to the resulting confusion.

There is also the case of Intuit sending "From" invoices on behalf of various individuals and using their customer's email address given to them by their Internet provider, only to find someone now thinks DKIM can't possibly be considered valid when signing the Sender header field. That is exactly the intended purpose for this field. This is essentially the same issue with mailing-lists.  In both cases, there is a valid reason for the From header field to contain that of their client or the speaker, because that is what the recipient is able to recognize.  There are also MUAs that will create a synthetic From <sender> on behalf of <from>.  Most MUAs can also optionally display both headers. 

The real effort involved in the sequence of these messages is establishing trust anchors. While there is going to be a massive number of individuals involved, there are several orders of magnitude fewer trust anchors.  For any domain wanting to assert strict alignment for their messages, it is only fair for them to work out relationships between their users messages and the non-aligned third-party services (trusted domain --> worthy third-party service).  Their out-bound logs and DMARC/User feedback should arrive at a reasonable estimate about which domains are being trusted.  Rogue services will be excluded and any mistakes can be quickly corrected.

Rather than describing this as a permission to sign, think of this as a type of server federation aimed at protecting the federated identity much like single-user-sign-on.  In this case, it would be which of these services are normally used and maintain practices that protect the federated identifiers.  The TPA-Label scheme allows this type of federation to be centralized or handled separately by each trusted domain (senders) as described in http://tools.ietf.org/html/draft-otis-tpa-label.

Regards,
Douglas Otis

---

From: Brandon Long <[email-masked]>
Date: Mon, 2 Jun 2014 14:22:40 -0700

On Sun, Jun 1, 2014 at 7:56 PM, Douglas Otis <[email-masked]> wrote:

> That is debatable. As long as the mailing list program tampers with the
> message's content, rendering its DKIM signature invalid, it can be argued
> that the mailing list program is rewriting the message's content, and
> therefore that the mailing list program now becomes "the system responsible
> for the writing of the message" (as per RFC 5322 parlance, section 3.6.2),
> and thus the mailing list address would earn its legitimate place in the
> Header-From field, making interoperability with rogue DMARC Senders a
> solved problem.
>
>
> In my book, this is mail tampering. It will be hard to justify adding
> support for this radical behavior in our mail list server product which
> puts customers at risk.  You are putting yourself at product liability risk
> but intentionally defying a security protocol against the wishes of the
> publishing restrictive domain.  Of course, its only becomes a problem when
> its used as a loophole to further spread harmful mail and someone actually
> gets harmed.  Thats all you have to prove in a courtroom.   If you had all
> the tools before you to tell you definitively, "This is unauthorized mail"
>  and you intentionally, deliberately and neglectfully ignore it, do nothing
> about it but further distribute to end points, well, who knows what a young
> punk, tech savvy, high tech, new age lawyer will think about suing you.  If
> you got deep pockets, well, don't think it can't happen.
>
>
> We can do it right.  All we have to do is LOOKUP the policy and follow it.
>  Give the YAHOOs the tools to authorize the resigners and you and I won't
> have these new ethical problems to content with.
>
>
> It seems wrong to describe a mailing-list adding Subject Tags, List
> Footers, while retaining the From header field so people have an easer task
> of knowing who is talking and at reviewing past conversations as putting
> recipients in grave risk.  Causing a massive number of people to find
> different email providers so they can retain their effectiveness at using a
> mailing list is far more likely to create risk simply due to the resulting
> confusion.
>
> There is also the case of Intuit sending "From" invoices on behalf of
> various individuals and using their customer's email address given to them
> by their Internet provider, only to find someone now thinks DKIM can't
> possibly be considered valid when signing the Sender header field. That is
> exactly the intended purpose for this field. This is essentially the same
> issue with mailing-lists.  In both cases, there is a valid reason for the
> From header field to contain that of their client or the speaker, because
> that is what the recipient is able to recognize.  There are also MUAs that
> will create a synthetic From <sender> on behalf of <from>.  Most MUAs can
> also optionally display both headers.
>
> The real effort involved in the sequence of these messages is establishing
> trust anchors. While there is going to be a massive number of individuals
> involved, there are several orders of magnitude fewer trust anchors.  For
> any domain wanting to assert strict alignment for their messages, it is
> only fair for them to work out relationships between their users messages
> and the non-aligned third-party services (trusted domain --> worthy
> third-party service).  Their out-bound logs and DMARC/User feedback should
> arrive at a reasonable estimate about which domains are being trusted.
>  Rogue services will be excluded and any mistakes can be quickly corrected.
>
> Rather than describing this as a permission to sign, think of this as a
> type of server federation aimed at protecting the federated identity much
> like single-user-sign-on.  In this case, it would be which of these
> services are normally used and maintain practices that protect the
> federated identifiers.  The TPA-Label scheme allows this type of federation
> to be centralized or handled separately by each trusted domain (senders) as
> described in http://tools.ietf.org/html/draft-otis-tpa-label.
>

Why should I, or my users, trust Intuit?

Perhaps I do because I have friends who have worked there and I use their
software.  What about the next payments start-up?  Or the Russian or
Chinese equivalent of Intuit that I know nothing about and at best rely on
the google translate version of their home page?

Do you expect that we would pass 30k domains through some sort of human
vetting process, and that even if we were willing to do that, we would be
capable of actually vetting them all?

Third parties that Google uses in this manner need to go through a vendor
security audit.  I can certainly say that we don't have the resources for
doing that for 30k services.  Even if we did, I'm betting a good portion of
them wouldn't pass.

There's nothing preventing the Intuit case from having the mail sent From:
"Intuit Billing Services" or even "My Company Billing Services" <
[email-masked]>.  Or, if you really want to send from your gmail.com
account, give Intuit permission to send using your account with OAUTH2.
 That seems pretty acceptable for a billing arrangement.

Brandon

---

From: Douglas Otis <[email-masked]>
Date: Mon, 2 Jun 2014 16:39:10 -0700

Dear Brandon;

See comments inline:

> Why should I, or my users, trust Intuit?

Why is From domain alignment the only header trusted for user accounts?  For those you need to trust, ask them to use OAR.  This can be a stipulation included in the Authorization.  Users may wish to correspond with more than just transactional messaging after all.  At least allow TPA-Labels to permit exceptions.

Be less dogmatic and consider a TPA-Label exception for Sender.  There are many MUAs able to display both Sender and From.   Some MUAs even create a synthesis of From <sender> on behalf of <from>.  A configuration script can be provided to users to ensure they are aware of this option.  One might even suspect there is a reasonable number of users making use of these headers as well. :^)

> Perhaps I do because I have friends who have worked there and I use their software.  What about the next payments start-up?  Or the Russian or Chinese equivalent of Intuit that I know nothing about and at best rely on the google translate version of their home page?

IMHO, it is wrong to say WE have decided that messages aligned with the Sender header field will now be rejected, when for decades this represented proper use.  Yes, it means an email provider will be making decisions.  Welcome to email. :^)

We have been making these types of decisions for about two decades without the valuable resource of outbound domain logs and DMARC feedback.  Much of the information needed to do this properly will be found in the feedback and logs.  Once digested, what has been determined to be an informally federated domain needs to be shared with recipients so they can make better decisions without disrupting venerated services.   Since doing this better ensures recipients will be less confused or upset when things needless change.   

> Do you expect that we would pass 30k domains through some sort of human vetting process, and that even if we were willing to do that, we would be capable of actually vetting them all?

Yes. Start with the easy stuff.  Eventually, this will catch up.  Ignore newly created domains or have them contact your abuse desk for escalation.  There are far fewer systems identified by domain. There should be enough redundant confirmations to the point not much human vetting should be needed.  These numbers should not be overwhelming.  Start with sources offering the most compliance information in their messages.  We did our best with much less for the entire address space.  In the long run your users will benefit by establishing these domain-to-domain relationships.

> Third parties that Google uses in this manner need to go through a vendor security audit.  I can certainly say that we don't have the resources for doing that for 30k services.  Even if we did, I'm betting a good portion of them wouldn't pass.

That is why the draft calls this informal federation because it is not Google, but your users making informal use of services by establishing their own credentials.  Most are very happy with these services.

> There's nothing preventing the Intuit case from having the mail sent From: "Intuit Billing Services" or even "My Company Billing Services" <[email-masked]>.  Or, if you really want to send from your gmail.com account, give Intuit permission to send using your account with OAUTH2.  That seems pretty acceptable for a billing arrangement.

Vet message domains based on prior histories.  Judy.c makes this process very easy and quick.  Please don't advocate companies become fast and loose with their credentials.  Especially in places like China and Japan.  Losses are adding up quickly, where each domain needs to stand on its own.  A provider willing to request a stringent DMARC domain alignment should also be willing to offer the likely exceptions needed to prevent tens of thousands of services from being disrupted.  This is especially true when the underlying reason for the request is compromised user accounts. This then becomes about what is needed to establish cooperation between sender and receiver.

Regards,
Douglas Otis