Re: DMARC methods in mailman

Hector Santos <> Wed, 21 December 2016 10:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CC0A129D2A for <>; Wed, 21 Dec 2016 02:11:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=XwSbylO6; dkim=pass (1024-bit key) header.b=jhrBCf9X
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VsMvlEyWtE_g for <>; Wed, 21 Dec 2016 02:11:13 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 934DF129D3A for <>; Wed, 21 Dec 2016 02:10:55 -0800 (PST)
DKIM-Signature: v=1;; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1961; t=1482315054;; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=tcSvXXVuRNslnNkTQaWX2MD9/No=; b=XwSbylO6ls78fkAgOSa6Gsq5aCAzckpglsazXGbTtpjfaDmj0/48boT1Jko5kM 2cH8R9M6tHFN4FjVo0l+He/Tqk7TvpcOcB1KUuPmdwjounYJtpSIBadTc+FsHJUs wiIPM1jH5k0i7pa4ssCYjBK7lRDAMyReFDJIFvYDpMabY=
Received: by (Wildcat! SMTP Router v7.0.454.5) for; Wed, 21 Dec 2016 05:10:54 -0500
Authentication-Results:; dkim=pass header.s=tms1; adsp=pass policy=all;
Received: from ([]) by (Wildcat! SMTP v7.0.454.5) with ESMTP id 3853980785.1.4148; Wed, 21 Dec 2016 05:10:52 -0500
DKIM-Signature: v=1;; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1961; t=1482314947; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Oe4Hz2q snvRN7kRfNkdliUFD8U3rUcVlXhzzA7++2Jw=; b=jhrBCf9Xpc0J1YFf4jdoiTd /2punBbidAfkxx+3PawC1GOfx9x4BiRZbUXjM+dbvadv5cO3YvEMdqhm+ratWwFW ppaIZ9UL0qyVUdYa2S3i08ScpBtXlZvNl5U25vzDXQbu/tZQDznCX41/diY3gzju ZF+nzf3bDp0PTUIsAHm4=
Received: by (Wildcat! SMTP Router v7.0.454.5) for; Wed, 21 Dec 2016 05:09:07 -0500
Received: from [] ([]) by (Wildcat! SMTP v7.0.454.5) with ESMTP id 3850410718.10.638860; Wed, 21 Dec 2016 05:09:05 -0500
Message-ID: <>
Date: Wed, 21 Dec 2016 05:10:52 -0500
From: Hector Santos <>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
Subject: Re: DMARC methods in mailman
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Dec 2016 10:11:15 -0000

On 12/19/2016 3:12 AM, Harald Alvestrand wrote:
> The ISE mechanism exists to get things published that matter to the
> Internet.
> It was clear at the time DMARC was published that it would be used
> whether it was published as an RFC or not. Publishing the document at
> least gave us a stable reference to be angry at.
> It would actually be harder to publish a document saying "DMARC is bad,
> don't use it, use that other thing instead" if there was no stable
> reference for what we mean by DMARC.
> I'd describe the so-far inaction more as "shut your eyes and hope it
> will go away when others figure out that the solution is bad" than as
> "sitting on the fence". Didn't work any better, though.

Lets keep in mind the proposed standard ADSP was officially abandoned 
by the same group that pushed the informational status "Super ADSP" 
DMARC replacement protocol.  This replacement did absolutely nothing 
to resolve the long time fundamental problem of addressing "middle 
ware" (list servers) breaking DKIM signed electronics messages nor the 
authorization of 3rd party signers.

We should perhaps recognize it is time to also abandoned DMARC as well 
or fix it with the many suggested improvements, including 3rd party 
authorization DNS lookups which is far simpler and "cheaper" than 
adding additional complexed headers and overhead to the mail system. 
Its not even a "proposed standard" document

We wanted list systems to change but we don't want the change to 
include DNS lookup protocols. Instead, we pushed very complex mail 
altering algorithms and that just isn't working -- obviously.

In my opinion, the IETF has failed the small to mid size 
implementators by catering to the "super large scale" mail providers. 
  That also needs to change within the IETF.  A protocol that is 
written correctly fits all. Size shouldn't matter.   That philosophy 
has been lost, unfortunately.

Happy Holidays