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