On May 29, 2014, at 7:07 AM, Stephen J. Turnbull <[email protected]> wrote:
> Douglas Otis writes: > >> There are many cases that are never originally signed by the DMARC >> domain. Such as an accounting package that sends out invoices on >> behalf of some company that wants their email address in the From >> header since this is what their customers will recognize. > > I don't understand this example. This use case seems quite compatible > with DMARC as it is. > > That is, company and accountant should have a substantial and > expensive to maintain trust relationship already. I would think that > the company could (a) provide an alias (subdomain) in its own domain > for the accountant's host, and advertise the accountant's policy via > _dmarc.invoices.example.com, or (b) maintain an authenticated channel > (ie, special purpose VPN) direct to a special host under its own > control in its own domain for the accountant to relay through, and the > company signs there. Sure, there'd be some additional cost, but not > prohibitive. Note that in either case the client can fire the > accountant in an instant by changing the DNS or shutting down the > authenticated channel. Dear Stephen, https://community.intuit.com/questions/899989-please-make-quickbooks-pass-the-dmarc-evaluation-please-do-this-quickly I know of many small operations with similar services and previously working strategies. With a low profit margin, no one wants to then be dealing with DNS or VPN configurations or deciding who is allowed to have access to their networks or their DKIM private keys. Think of the heating and air conditioning outfit given VPN access for the purpose of submitting invoices. That error in judgement cost hundreds of millions for a well known retailing outfit. There are also similar types of risks when anyone opens any MS Office document given to them by a spoofed party. http://krebsonsecurity.com/2014/05/the-target-breach-by-the-numbers/ The intent behind TPA-Label is to permit a secure scheme without ever asking anyone to share credentials. Not ever! Instead, everyone uses what they already have, perhaps even stronger schemes than what is offered by DKIM or SPF. Large ESPs that have had a major security breach should set aside a budget related to restoring order. A TPA-Label setup could be part of that effort. Two DNS servers (for redundancy) and some DMARC and MTA log processing scripts should offer a comprehensive and fairly complete starting point. Yes, even for a large ESP. Of course there will be ongoing support issues, but this should also pale in comparison to unsolvable email complaints of affected legitimate email use. For this, there should be web-based forms to supplement DMARC feedback. By setting up a TPA-Label extension, it would also allow their users to know when they have themselves been compromised, while also preventing unauthorized use by rogue servers. This added feature seems like a nice way of saying "Sorry, but we are now doing more to improve security." >>> I suspect that many parties that implement DMARC are "cheating" >>> by allowing things that look like mailing list or forwarded mail >>> through even if they fail auth and the domain is p=REJECT. >>> Providing a higher bar for when to "cheat" may be useful, then. > >> The hurdle that seems to be in everyone's mind is how to go about >> facilitating feedback that is not a lot of work. Again, TPA-Label also permits a way to squelch DMARC feedback already evaluated. Perhaps a flag could even be added that basically says. "Yes we know about this domain, and we think it cannot be trusted." This would be a change to the current draft. > Again, I seem to require an additional clue. DMARC feedback is > working fine AFAICS. It may be costly, and we want to reduce those > costs, of course. But "p=reject" OTOH is a more or less legitimate > denial of service, a completely different issue. Are you talking > about a different kind of feedback? Rather than having a channel only between receiver-to-sender, there should also be a channel between sender-to-receiver. The channel can represent a single DNS resource record. Such a single resource record would offer low latency, low cost, and cacheable near the receiver for even lower latency. I know that John and Tim would have little trouble setting up such a service. The real challenge is to have an ESP do this that really needs such a solution. Once in place, this opens up a range of services others could easily offer on behalf of those who simply desire greater email security. Regards, Douglas Otis
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
