On May 31, 2014, at 8:49 AM, Stephen J. Turnbull <turnb...@sk.tsukuba.ac.jp> wrote:
> Douglas Otis writes: > >> https://community.intuit.com/questions/899989-please-make-quickbooks-pass-the-dmarc-evaluation-please-do-this-quickly > > Grr. Doesn't describe the problem! Is it that a QuickBooks client > using a mailbox at a "p=reject" domain is having QuickBooks send > invoices on their behalf? > > If that's it, I have a great deal for them. Register a domain and get > their company name, instead of Yahoo!'s, in From:. > > Or (cheaper), Quickbooks just checks for "p=<not none>", and if so > overrides any company-specific config, and puts QuickBooks in From: > (with a working "p=reject" policy, even!), "Your <month> invoice from > <company>" in subject, and the company address in Reply-To. > > Even supposing the company doesn't like either of those options, it's > not clear to me that the "p=reject" domain is going to necessarily be > happy trusting QuickBooks, even once TPA-Labels gets implemented. Placing the original From and Subject in the message body would be cleaner, but people will wonder what to believe with few tools to help them sort through the confusion. After having large numbers change providers, spoofing their prior recipients from anywhere can now accompany very believable reasons, such as "DMARC caused me to change to this provider...". Once TPA-Label is implemented by both sender and receivers applying requested DMARC policy, nothing in between would need to change. No one would be confused, and malefactors can be reliably blocked. >> I know of many small operations with similar services and >> previously working strategies. > > Much less so the effort required to vette a million small operations > (who could actually be the Yahoo! customer requesting a TPA-label for > a vendor they use -- how does TPA-label deal with collusion between > authors and relays?) The number of Sender use cases would likely be in the thousands. There would be no free lunch which is why our company has a large and trained abuse staff. :^) Cases reported by DMARC feedback should be reviewed in the same manner as any possible abuse would. In this case, the source domain will have been validated. If there is any evidence of abuse, they don't get authorized. I should have added scopes to indicate a decision has been made to squelch further processing. 'x' for See Abuse Desk. After that, blocked domains would need to contact the abuse desk. I'll add that feature. > So, yeah, I sympathize with the Mom & Pop shops whose kids go hungry > this month because the bills didn't go out, and with the small > operations tearing their hair out because they've got a thousand > paying customers at Yahoo! whose content isn't arriving at > destination, but I really don't see TPA-Labels as a solution to this > problem yet. In the case of Intuit, likely one TPA-Label would have solved the problem once DMARC evaluation confirms with the _smtp._tpa zone. With TPA-Label, kids won't go to sleep hungry. :^) >>> 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. > > We already have such a channel (the _dmarc subdomain). What is this > new channel for? A single TXT record is hardly a reverse channel since it is unable to communicate the necessary range of exceptions DMARC really needs. In the case of PayPal and others, most initially made the mistake of posting to various mailing lists. They should have responded to these early signs a better scheme was needed to encompass actual use even when devised for only transactional email. That was not always the case then, and it clearly is not the case now. The TPA-Label, unlike SPF does not chain together a sequence of TXT resource records. All information is contained in a single small resource record at a single unique label which would represent a negligible overhead in comparison. Use of http would be much slower by adding a connection setup delay without any caching. We need to find an expedient and quick to implement solution where most of the burden is handled by the sender requesting the DMARC policy. That is only fair. Regards, Douglas Otis _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
