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

Hector Santos <> Sun, 13 April 2014 17:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A68501A0202 for <>; Sun, 13 Apr 2014 10:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -98.702
X-Spam-Status: No, score=-98.702 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_46=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gb9CwD6hG4xp for <>; Sun, 13 Apr 2014 10:37:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 39FF01A01FF for <>; Sun, 13 Apr 2014 10:37:52 -0700 (PDT)
DKIM-Signature: v=1;; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4293; t=1397410661; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=22QZ0PBkRgO/03+9M6FklJRGVnM=; b=abbF3li4JG0Z9TOEDB2/ UgM0zhXZgeT1rlh6TV9pv6FAaazCQThH/cpo2bHg5H85lqKbVVPVMkwmhbCObvdi K3aJER3KvZDBecegEF9GHhQvQbj6oDX7Sg6V8mpzPt44Y0nnpll26OlWtcKlS9Oc NwLT59/WjUy0U5f3o+yIu9I=
Received: by (Wildcat! SMTP Router v7.0.454.4) for; Sun, 13 Apr 2014 13:37:41 -0400
Authentication-Results:; dkim=pass header.s=tms1; adsp=pass policy=all;
Received: from ( []) by (Wildcat! SMTP v7.0.454.4) with ESMTP id 519239905.12247.1620; Sun, 13 Apr 2014 13:37:40 -0400
DKIM-Signature: v=1;; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4293; t=1397410597; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=JRxK+zb MXqXTqYTNJDwhVjv8ztO0Xynr34+VROZ9tlA=; b=iU0cB6q4uCQ7Ed/8fgx57Vo lI/+31G5ziboPUOQk+67y8//zbci+2uSHhmq+jl/KDoRdZvcFqasX2vuXgu+3xpm 1zgsuTyaZP+5RbgZJRMxQSUJ8MVGGvioEsANNZHdcCNk2BhrtjJRY5F4OSk9o2mq TK0cOdc/qkoSZqHJrkgA=
Received: by (Wildcat! SMTP Router v7.0.454.4) for; Sun, 13 Apr 2014 13:36:37 -0400
Received: from [] ([]) by (Wildcat! SMTP v7.0.454.4) with ESMTP id 538773031.9.9520; Sun, 13 Apr 2014 13:36:36 -0400
Message-ID: <>
Date: Sun, 13 Apr 2014 13:37:35 -0400
From: Hector Santos <>
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 <>,
Subject: Re: DMARC: perspectives from a listadmin of large open-source lists
References: <> <alpine.BSF.2.00.1404072357400.73388@joyce.lan> <> <> <alpine.BSF.2.00.1404081325130.76892@joyce.lan> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 13 Apr 2014 17:37:56 -0000

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
>> is re written to  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
> 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.

It opens a can of worms, Pandora's box, so to speak, to begin 
suggesting one can modifying and tampering with one the key x822/5322 
mail headers, From:, for any local reason.

In my ethical engineering book, it would just be major TABOO to do 
this. The 5322.From one is the anchor for fundamental electronic mail 
I/O for both networking and non-networking and for other technologies. 
To tamper with it,  it is bound to break other things.

Keep in mind, ADSP also proposed a "radical" DISCARD concept for mail. 
  But because of the ADSP standard track work and synergism at the 
time, we did get RFC2821BIS (RFC5322) to recognize the new reality 
that there are new reasons to ACCEPT and DISCARD rather than ACCEPT 
and BOUNCE without referring to the ADSP work (it was still a draft).

     side note:

     There was also a new modern reality where the SMTP DATA state point
     would be used more as a CALL OUT, SHIM, HOOK to handle new RFC5322
     based Payload technology such as DKIM verification where a ADSP
     policy check would also apply.  One main goal was dynamic processing
     with instant non-bounce notifications.  But with ADSP, there was
     suggestions for an implementation to set a ADSP fail that allows
     the acceptance of mail so it can be quietly discarded. IOW, no
     dynamic 55x rejection at the SMTP level for ADSP fail policies 
     that caused problems for the blind mailing list servers.

Yes, it is all complex, but here, the real solution is for John Levine 
and other large list operators to update their mail listing software 
to follow the suggestions in RFC6377:

    RFC6377 DomainKeys Identified Mail (DKIM) and Mailing List

Its not a new problem, its been known since 2006. There are secondary 
DKIM security "wrapper" layers that augment DKIM.  DMARC may be the 
focus, but the issue existed since SSP and ADSP.  If the list service 
is going to resign mail with DKIM, it needs to recognize that DKIM 
does comes with signature security baggage that the not covered by the 
trust model.

So this is a "integration" issue.  Honestly, the changes are not too 
difficult and IMO, it is far less intrusive than changing the 

1) When a new subscriber applies to a list, check for restrictive 
domain policies. Deny subscribers and explain why in the notification 

2) Check for restrictive domains in list mail submissions.

The first one is the piece a cake.  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.

Etc.  My main point is that we been doing this for 9+ years.  We knew 
the problems and we have the ideas for solutions.  Whether it was all 
practical and could scale, well, everyone had different opinions here.

But we got a different issue here when list operations don't want to 
change to add policy protocol support but change enough to support a 
pure DKIM-BASE but nothing else.  I fail to see how it can work that way.

This is a "integration" issue and can only be solved using an 
integrated DKIM+POLICY framework and mentality.