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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 16 April 2014 12:58 UTC

Return-Path: <mcr@sandelman.ca>
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 6F8EC1A0156 for <ietf@ietfa.amsl.com>; Wed, 16 Apr 2014 05:58:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.163
X-Spam-Level:
X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] 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 il40KdXt8I-y for <ietf@ietfa.amsl.com>; Wed, 16 Apr 2014 05:58:28 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD881A0178 for <ietf@ietf.org>; Wed, 16 Apr 2014 05:58:26 -0700 (PDT)
Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id DF5AE2002C for <ietf@ietf.org>; Wed, 16 Apr 2014 08:58:40 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id DD22A63ABD; Wed, 16 Apr 2014 08:58:16 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C91F763AA2 for <ietf@ietf.org>; Wed, 16 Apr 2014 08:58:16 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: ietf@ietf.org
Subject: Re: DMARC: perspectives from a listadmin of large open-source lists
In-Reply-To: <534E6AC1.7030709@qti.qualcomm.com>
References: <534B524F.4050206@dcrocker.net> <alpine.BSF.2.00.1404132327560.26258@joyce.lan> <E0B7196CB2603B80BBEC21AF@JcK-HP8200.jck.com> <alpine.BSF.2.00.1404132346420.26386@joyce.lan> <1EBDF5239EEE5202D3837D25@JcK-HP8200.jck.com> <534B9760.90301@dougbarton.us> <6C80882F19CCEDFE15E987CA@JcK-HP8200.jck.com> <534BEF75.5060804@bbiw.net> <534DB093.5020507@qti.qualcomm.com> <534DBA0F.2050507@gmail.com> <20140415231720.GQ4456@thunk.org> <534E6AC1.7030709@qti.qualcomm.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Wed, 16 Apr 2014 08:58:16 -0400
Message-ID: <18443.1397653096@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/EXmIOMYF6UYQZ3F8hG3iUNFlki8
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: Wed, 16 Apr 2014 12:58:33 -0000

It's clear to me that we need at least a non-WG mailing list for this
*technical* discussion.  Fixing the mailing list problem may require
fundamental changes in how things work; and I think that is okay.
Maybe we could try this NNTP thinkg I've heard about :-)

Pete Resnick <presnick@qti.qualcomm.com> wrote:
    > a decision on which lists to send to, that's a different thing.) If the
    > originator's site is going to allow that, you could create a mechanism
    > where
    > the originator's site gets some sort of cryptographic data from the
    > mailing list site and include that in its signed message, such that
    > when the eventual

so, what you are saying is that based upon the (SMTP) To: address, the sender
needs a signal that this is a mailing list, and some way to react.
Maybe this could be combined with various SMTP DANE mechanisms, or at least,
maybe "Additional RR" could return that kind of information.

I think that there are a whole bunch of architectually important things
here.  The signal has to come early enough to either modify the DKIM process,
or if the signal comes rather late (such as during SMTP delivery), then it
needs to be possible to redo the DKIM process.  I think that this will be
challenging for many large installations where there are multiple layers of
outgoing SMTP delivery machines, and DKIM is just a stage in the process.

But, I don't think it is impossible.
Consider all the other meta info that could be stored along with the "I am a
list" signal... things like how to subscribe, unsubscribe, location of
archive, etc.

Imagine if that signal also changed the protocol from SMTP to NNRP POST?

    > And again, this is only if the originator indicates that it *wants* to
    > allow its users to have their mail redistributed. The site is well
    > within rights to ndicate that it doesn't want that to happen, and a
    > friendly mailing list would bounce the mail in that case.

Running code.  we need someone to fund and participate in an experiment.
 (cf: other thread about not participating in SDOs anymore)


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-