On May 28, 2014, at 8:48 PM, Douglas Otis <[email protected]> wrote:
> Dear Tim,
>
> All that is needed is a few bandaids?
Hi Doug, I don't see the problem space as allowing bandaid approaches. The
widespread ability to build controls on top of stable domain level identifiers
is relatively new. In my view, people that want to use these controls are
stuck in one of two ways:
1. They're trying to modify how their email is structured so that controls can
safely be put into place, and there is some sort of relationship that allows
change to happen. Franck Martin wrote previously about this here:
http://www.ietf.org/mail-archive/web/dmarc/current/msg00878.html
2. They're trying to address "legitimate-but-unauthorizable" email. In this
bucket I'd put everything that is mostly beyond the ability for individual
domain owners to change: mailing lists, forward-to-friend, services that send
on behalf of users. Scott Kitterman wrote about this and asked about the scope
of IETF work in this bucket:
http://www.ietf.org/mail-archive/web/dmarc/current/msg00872.html
Pain due to inaccurate deployment of controls is the domain owner's problem (#1
above). There (should be!) plenty of feedback available for domain owners to
recognize their own problems.
Pain due to everything else (#2 above) is something domain owners can't expect
to solve on their own. It's in this area that "bandaids" might work in the
short term (like publishing lists of exceptions), but long term I'd personally
prefer not to see a codified model of exceptions.
I think it would be better to specify how impacted email in bucket #2 can be
dealt with, but not with a goal of preserving all existing email use cases.
IMO a better goal would be to specify how specific categories of email should
be presented. For example, codify how mailing lists go about their business
(maybe: adhere to relevant RFCs + DKIM sign with ML's domain + perform OAR-like
checks). A different example: analyze the use of "Reply-to:", determine what
is preferable behavior, and codify what should be expected. The resulting
specifications would at least tell developers (across the spectrum from MTA
through MUA) what they need to do to interoperate.
>
> The motivation behind TPA-Label was to ensure both quick and efficient
> methods to offer necessary feedback to receivers. DMARC already expects
> receivers to offer failure feedback to DMARC domains. Unfortunately, once
> the DMARC domain has decided which third-parties need to be granted
> exceptions, there is no way to do so. It seems dangerous to suggest this
> can be hard-coded in the form of informal lists indicating which DMARC
> domains should be ignored.
I think I understand the motivation. I guess I'm in the horrible position of
viewing TPA-Label as a bandaid, given my own view of the scope and amount of
work involved in making email suck less. I don't mean to disparage TPA-Label
-- I just mean that given a finite amount of focus and fuel, I'd prefer to work
out what I wrote about above: "specifying how impacted email in bucket #2 can
be dealt with".
>
> In the case of Yahoo, there is a real issue they are attempting to mitigate.
> It would be nice to have a solution able to deal with massively compromised
> user accounts, as ugly as that is. This is an issue that is not going away
> any time soon. The issue is much worse in China, for example. Please don't
> decide being helpful in such situations is simply too hard. Is it really
> better to create lists about which domains get ignored? It seems this quickly
> degrades DMARC's initial intent, which was to offer results receivers felt
> safe to act on. Is this still a worthy goal?
One facet of the problem that Yahoo & AOL are addressing via DMARC-based
controls goes beyond "compromised user accounts". A malware-infected PC's
local address book gets scraped, and the infected PC emits spam/malware that
spoofs the owner of the PC's email address (because fraud appearing to be from
a known friend/colleague is pretty effective fraud). This fraud does not flow
through Yahoo or AOL.
I hope the above shows that the size and scope of difficult problems is not
something I'm looking to work around. IMO bandaids are exception-lists and
mechanisms like TPA-Label, and the difficult (but necessary) work remains in
proposing, researching, specifying, implementing, and advocating for how well
established mailing practices can interoperate in an email environment where
stable domain-level identifiers are the norm.
-= Tim
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
