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

[Hector Santos <[e-mail]>]

>> 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?

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