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

Alessandro Vesely <vesely@tana.it> Tue, 15 April 2014 07:52 UTC

Return-Path: <vesely@tana.it>
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 C264E1A0681 for <ietf@ietfa.amsl.com>; Tue, 15 Apr 2014 00:52:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.606
X-Spam-Level:
X-Spam-Status: No, score=0.606 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 sqOAIWockQs7 for <ietf@ietfa.amsl.com>; Tue, 15 Apr 2014 00:52:32 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 14A1B1A031D for <ietf@ietf.org>; Tue, 15 Apr 2014 00:52:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1397548348; bh=U9U2/C+8TxEx3yYxy1Gb0gr5U4Rr7xXscNUIkCRq9PM=; l=2924; h=Date:From:To:CC:References:In-Reply-To; b=UB1gJSQdUpwc1VZupDig0RJiSJt+OO4HKyLIGx6iaBYVpe9fhlKaEXujQKBZs5N80 3QA26jZT2IuFaOFWk8NWmOHTetb103DdgjIZ4zvu39/DFeUPH1gqGCYTWjZ9yPRWCy wKouccZjz36dVGFinFaceQ+MKBfjfGjJQvt+YUp4=
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 15 Apr 2014 09:52:28 +0200 id 00000000005DC035.00000000534CE53C.000012C2
Message-ID: <534CE53A.7090000@tana.it>
Date: Tue, 15 Apr 2014 09:52:26 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10
MIME-Version: 1.0
To: Hector Santos <hsantos@isdg.net>
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>
In-Reply-To: <534ACB5F.7060400@isdg.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/LnEdzBPJBCaafi5ZWLjQIh4YlOg
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 07:52:36 -0000

On Sun 13/Apr/2014 19:37:35 +0200 Hector Santos wrote:
> On 4/11/2014 6:40 AM, Alessandro Vesely wrote:> On Tue 08/Apr/2014
> 19:34:35 +0200 John R Levine wrote:
>>>
>>> Just today I did modify it so that any list mail with a From: address
>>> @yahoo.com is re written to @yahoo.com.INVALID.  That's the least
>>> intrusive way I've been able to come up with to mitigate the damage.
>>
>> Fair enough.  I've copied that suggestion to
>> http://en.wikipedia.org/wiki/DMARC#Human_policy
>> Please feel free to amend that page at your leisure.
>>
> 
> Hi Alessandro,
> 
> You added (I presume):
> 
>    According to John Levine, a well known mail expert, the least
>    intrusive way to mitigate the damage would be to rewrite the
>    From: address in a predictable, comprehensible manner, such as
>    the following:
> 
> 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?

> [...]
> So this is a "integration" issue.  Honestly, the changes are not too
> difficult and IMO, it is far less intrusive than changing the 5322.From.
> 
> 1) When a new subscriber applies to a list, check for restrictive
> domain policies. Deny subscribers and explain why in the notification
> message.
> 
> 2) Check for restrictive domains in list mail submissions.
> 
> The first one is the piece a cake.

Yes

> The 2nd one can be more complex
> due to the wider number of software things to do here.
> 
> 2a) Dynamic SMTP check, reject (55x) the message with policy reason.
> 
> 2b) Accept message and send a "no access" notification message.
> Explain why.
> 
> 2c) During the redesign software change, write a one time membership
> scanner to remove restrictive domain members. Send email notification
> explaining why.

I think (2c) has to be done politely, in order to allow people the
time to react adequately.

Ale