Yahoo DMARC breakage
mike at mtcc.com
Thu Apr 10 14:56:16 UTC 2014
On 04/09/2014 09:54 PM, Jimmy Hess wrote:
> Basic functionality is seriously and utterly broken --- that DMARC doesn't
> have a good answer for such situations, is a major indicator of its
> immaturity, in the sense that it is "Too specific" a solution and cannot
> apply to e-mail in general.
DMARC is nothing more than warmed over ADSP which itself didn't have
a pat answer for mailing list traversal. For transactional mail ADSP was
just fine, but for regular mail the signing policy was meant to be a
other heuristics. It says nothing more than "i sign my mail outgoing", so
what do you do if the signature is broken? If you want to take a hard line,
then you are going to get all kinds of false positives... this has been
for 10 years at least. I'd be surprised to hear that Y! of all people
that, but it's their pissed off users' problem. Vote with your feet.
> If it were mature: a mechanism would be provided that would allow mailing
> lists to function without breaking changes such as substituting From:.
> An example of a solution would be the use of a DKIM alternative with not
> a single signature for the entire message, but only partial signing of
> parts of the message: specifically identified headers and/or specific
> body elements, to validate that the message was really sent and certain
> elements are genuine ---- and certain elements were modified by the
> mailing list.
You can more or less do this with DKIM already, and get about 90%
of mailing list traffic to pass verification. The question is whether that's
enough. I have no idea whether Y! is doing the things I did to get that
> The technical issue, is that the immaturity of the related specs. limits
> the decisions are available for a particular domain ---- so,
> essentially, if you have certain kind of user traffic: you have to incur
> technical issues with mailing lists, or forego using DMARC.
> In other words: much as you would like to dismiss as purely a managerial
> decision ---- the decisions available to be made are entangled with
> the limitations of the technical options that are available for
> mitigating spoofing,
> AND the public's understanding thereof.
Crocker may have some further insight that we're not privy to, but using
signing policy on the general population as a raw instrument is well known
to be a bad idea for DKIM and SPF's policy mechanisms as well. SPF in
had a huge amount of blowback by punitive mail operators who didn't
the implications, at least in the early days. It may indeed be
but I can't see what the point is in defending the idiocy as being some
More information about the NANOG