RE: DMARC: perspectives from a listadmin of large open-source lists

["MH Michael Hammer (5304)" <[e-mail]>]

> -----Original Message-----
> From: ietf [mailto:[e-mail]] On Behalf Of Hector Santos
> Sent: Tuesday, April 15, 2014 4:57 PM
> To: Alessandro Vesely
> Cc: [e-mail]
> Subject: Re: DMARC: perspectives from a listadmin of large open-source lists
> 
> 
> >> It may be the "quickest" way, but I would consider this the most
> >> intrusive and even email damaging, extremely harmful suggestion to
> >> electronic mail communications.
> >
> > Ok, I added "temporarily", so it now reads:
> >
> >     Various workarounds have been proposed to cope with domains that
> >     publish strict policies unwittingly. For example, a mailing list
> >     manager should reject posts from authors who use problematic email
> >     domains. The latter behavior is the most respectful the
> >     communication protocols as well as the domain owner's will.
> >     However, it might cause inconveniences in the face of sudden
> >     policy changes. According to John Levine, a well known mail
> >     expert, the least intrusive way to temporarily mitigate the damage
> >     would be to rewrite the From: address in a predictable,
> >     comprehensible manner, such as the following:
> >
> > In the preceding "History" section, I appended:
> >
> >     In April 2014, Yahoo changed its DMARC policy to p=reject, thereby
> >     causing misbehavior in several mailing lists.[6] DMARC is not yet
> >     a standard protocol, and currently misses a provision for such
> >     sudden changes.
> >
> > Is that more acceptable?
> 

Many protocols do not address sudden individual implementer changes to their implementation. I do believe that there were various issues involving DNSSEC trust chains when upstream participants (including CC TLDs) implemented "sudden" changes. Are you expecting something like "MUST provide x days notice of intended change" to make it non-sudden or require a rollback if more than x mailing lists have problems? Are there any other IETF standards that would be a reference point for such a provision? I'm not trying to be cute or argumentative - I'm just not familiar with something like this in any standards I can think of.

> I think adding temporarily helps and the additional text about DMARC
> certainly helps.
> 
> But the problem is YAHOO doesn't want you to do this (rewrite).
> 
> Just consider what you are essentially doing:
> 
>     Degrading a secured message to a non-secured message.
> 
> The whole point of Yahoo moving to a restrictive policy is to force a cleanup
> of their domain usage, to increase its security quality, even if it hurts the
> innocent users who were using their domains in public mail list areas.
> 
> So I would personally refrain from any product liability risk that its ok to
> "tamper" with their DKIM secured author domain submissions.
> 
> Case in point, lets say a real bad message got into the list, unsigned,
> purported from Yahoo, the 5322.From was rewritten and distributed to other
> list users and some of those users were "harmed"
> in some fashion that it worth the effort to sue.   Guess who would be
> at legal fault here?  Not YAHOO. They are legally protected.  The MLM, who
> wistfully and intentionally ignored policy and even went as far to break the
> security, is now at risk.
> 
> No, its not silly, and just because I am not a lawyer, doesn't mean we don't
> think about these things in our product development.  In fact, it is generally
> the engineer, us, that has to ask the our lawyers if this is ok.  He isn't going to
> generally tell you, it is not something he will pick up unless you pointed it out
> to him. Then he will give you his legal advise and in my strong opinion, you
> don't tamper with a security protocol which is what being suggested here.
> 
> Don't let me stop you from the wiki work.  It is just how I work.
> 
> Thanks
> 
> --
> HLS
>