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

Hector Santos <hsantos@isdg.net> Tue, 15 April 2014 20:57 UTC

Return-Path: <hsantos@isdg.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198C11A07D7 for <ietf@ietfa.amsl.com>; Tue, 15 Apr 2014 13:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.701
X-Spam-Level:
X-Spam-Status: No, score=-98.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqB7SI92PjBq for <ietf@ietfa.amsl.com>; Tue, 15 Apr 2014 13:56:59 -0700 (PDT)
Received: from ntbbs.santronics.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBF61A06B8 for <ietf@ietf.org>; Tue, 15 Apr 2014 13:56:59 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2832; t=1397595411; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=eh0ejrCUZjkwll1Bmhm3Ar3CTjc=; b=KfgxPaFWR9uRHmkWI8W+ w9L3jfcIZDi+TJHthvccU7Z+PZ9lpmSnzcZMRRfVPixZRWUa6lISYfTTcYOXaEm6 Tu9/jG7gJP2QCD4LwRqDArqtPGHB6NpZR7MwlN8BR6itR0aa+lwP/DqEGIzhkMSK 1pktHjmwTNYu5j7Eiw8qGM4=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Tue, 15 Apr 2014 16:56:51 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 703987583.3.2836; Tue, 15 Apr 2014 16:56:50 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2832; t=1397595345; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Egqwvi1 vk41BaScRP1otalKBwZAisK7kpsshLnRYIMU=; b=eFaLPjm8CGCnWxilmGuPoZD 40ssSrcz4mmcAPK3xj3bV2ZNeeZW2TE6A+GEsAqUzMcs1fJ6+1afH1eHeOFmOW3A F6f8PCUJAZ+mrkWi590QqueG6tfgMG8Lx6EyC6X15Ew4Xjyg+bf8xjvO7WtPs0zi jQdhpeKGxDcXsi7tpJ90=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf@ietf.org; Tue, 15 Apr 2014 16:55:45 -0400
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 723521078.9.8728; Tue, 15 Apr 2014 16:55:44 -0400
Message-ID: <534D9D12.4080602@isdg.net>
Date: Tue, 15 Apr 2014 16:56:50 -0400
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Alessandro Vesely <vesely@tana.it>
Subject: Re: DMARC: perspectives from a listadmin of large open-source lists
References: <robbat2-20140408T031810-279861577Z@orbis-terrarum.net> <alpine.BSF.2.00.1404072357400.73388@joyce.lan> <01P6EEIPML6600004W@mauve.mrochek.com> <6.2.5.6.2.20140408101346.0ccb5e88@resistor.net> <alpine.BSF.2.00.1404081325130.76892@joyce.lan> <5347C698.6040108@tana.it> <534ACB5F.7060400@isdg.net> <534CE53A.7090000@tana.it>
In-Reply-To: <534CE53A.7090000@tana.it>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/at_G4DbiZGLtVZXAKWFRNyOGVhE
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Apr 2014 20:57:04 -0000

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