-----Original Message-----
From: ietf [mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Hector
Santos
Sent: Tuesday, April 15, 2014 4:57 PM
To: Alessandro Vesely
Cc: ietf(_at_)ietf(_dot_)org
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