Dear Brandon; See comments inline: On Jun 2, 2014, at 2:22 PM, Brandon Long <[email protected]> wrote:
> On Sun, Jun 1, 2014 at 7:56 PM, Douglas Otis <[email protected]> wrote: > 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? 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 protected]>. 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
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
