IETF Logo Mail Archive

Re: Mailing list membership.

Carsten Bormann <cabo@tzi.org> Thu, 02 March 2017 00:35 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AF9129447 for <ietf@ietfa.amsl.com>; Wed, 1 Mar 2017 16:35:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 zT9BeHDWidf0 for <ietf@ietfa.amsl.com>; Wed, 1 Mar 2017 16:35:33 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A279B129478 for <ietf@ietf.org>; Wed, 1 Mar 2017 16:35:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v220ZRMY000466; Thu, 2 Mar 2017 01:35:27 +0100 (CET)
Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vYYHy6HWSzDHHx; Thu, 2 Mar 2017 01:35:26 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Mailing list membership.
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <alpine.LRH.2.01.1703011132580.3764@egate.xpasc.com>
Date: Thu, 02 Mar 2017 01:35:25 +0100
X-Mao-Original-Outgoing-Id: 510107725.361913-e980b30861daa40482ae1a8257e7a051
Content-Transfer-Encoding: quoted-printable
Message-Id: <ADF97FF4-F62E-4A2D-A538-84DC69F0DCD0@tzi.org>
References: <6.2.5.6.2.20170226124145.0b7b38c0@elandnews.com> <20f0d769-1937-3256-e37b-9583399c11d3@riseup.net> <20170227011852.GA5403@mx4.yitter.info> <5850e685-2f97-2bdb-87e2-0c11830e1d1c@riseup.net> <HE1PR04MB14490315646CDD5CC7DC2DBCBD570@HE1PR04MB1449.eurprd04.prod.outlook.com> <ae531393-b622-a8b3-2cdd-65a4e99c6e9f@riseup.net> <HE1PR04MB14490DE8834559F6D9D05F7EBD570@HE1PR04MB1449.eurprd04.prod.outlook.com> <60cc8784-2815-32df-0cae-7adfffd0b549@riseup.net> <20170228051843.wkh5skthuyrs5pwz@thunk.org> <bea06868-c7b9-29ec-4f63-1adcca3b9698@riseup.net> <20170301044937.v3vhw3eqgqkxpoup@thunk.org> <cfb52458-8bb9-58fe-d80a-f1b17a6da6cc@comcast.net> <947BCD81-7F9C-4C2E-ADDE-D68DD2BF513A@gmail.com> <70ebe3f4-bae5-7b65-a8ba-b90fdc38dbb8@comcast.net> <C796CA13-8D43-4423-9559-B1B494AB50BE@tzi.org> <alpine.LRH.2.01.1703011132580.3764@egate.xpasc.com>
To: David Morris <dwm@xpasc.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/_R1G5pH_Cwt-gnxBbleEczP3x3Q>
Cc: IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 02 Mar 2017 00:35:36 -0000

> On 1 Mar 2017, at 20:34, David Morris <dwm@xpasc.com> wrote:
> 
> 
> 
> On Wed, 1 Mar 2017, Carsten Bormann wrote:
> 
>> On 1 Mar 2017, at 20:18, Michael StJohns <mstjohns@comcast.net> wrote:
>>> 
>>> eventually customize the confirm message based on provider
>> 
>> Better: Send the subscription confirmation message with attributes that cause a DMARC-honoring provider to discard it :-)
>> (No programming required :-)
> 
> No, that is worse as it insures support costs and more noise on this list.

I apologize for trying to inject some humor into this serious matter.

Silently dropping subscription requests isn’t very nice.  So there probably should be a second (DMARC-unencumbered) message telling people to expect the confirmation request message and to use a different mail system if it does not arrive.

I do not agree that actively preventing DMARC-honoring addresses from subscribing would be worse than the current situation, where the subscriber thinks they are on, only to be kicked off after a short while (or, worse, simply not receiving some of the messages).

Grüße, Carsten

v2.23.0 | Report a Bug | By Email