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