Re: several messages
John C Klensin <john-ietf@jck.com> Fri, 14 November 2008 18:46 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B18F3A68A2; Fri, 14 Nov 2008 10:46:01 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D0023A68A2 for <ietf@core3.amsl.com>; Fri, 14 Nov 2008 10:46:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.628
X-Spam-Level:
X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=0.971, BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EW6VoNxP4RUx for <ietf@core3.amsl.com>; Fri, 14 Nov 2008 10:45:59 -0800 (PST)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 08BB63A67D8 for <ietf@ietf.org>; Fri, 14 Nov 2008 10:45:59 -0800 (PST)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1L13g0-0005lu-Kv; Fri, 14 Nov 2008 13:45:53 -0500
Date: Fri, 14 Nov 2008 13:45:51 -0500
From: John C Klensin <john-ietf@jck.com>
To: Rich Kulawiec <rsk@gsp.org>, ietf@ietf.org
Subject: Re: several messages
Message-ID: <B81943909B5DD6BFD3A486B3@p3.int.jck.com>
In-Reply-To: <20081113165601.GA2969@gsp.org>
References: <Pine.LNX.4.64.0811121117180.8743@toro.popovich.net> <008601c944fd$950335c0$6801a8c0@oemcomputer> <20081113165601.GA2969@gsp.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
--On Thursday, 13 November, 2008 11:56 -0500 Rich Kulawiec <rsk@gsp.org> wrote: > On Wed, Nov 12, 2008 at 11:33:46AM -0800, Randy Presuhn wrote: >> Huh? Concrete, real example: I send a message to an IETF >> mailing list. A list subscriber's ISP rejects the forwarded >> message. IETF's mailman drops the subscriber, because this >> has been happened multiple times. I can't notify the >> subscriber, because their ISP also rejects my email. > > This is not a DNSBL problem. This is a problem with the > subscriber's ISP, which is not operating their mail system per > de facto best practices -- which include making sure that > rejection notices provide an alternate-channel means of > contacting them in order to discuss apparently-erroneous > blocking. There are a sizable number of techniques for doing > this; I happen to think the best ones are quite simple, e.g.: >... Sigh. Rich, you can blame "someone else" all you like, but the reality here is that (1) If the system supporting the DNSBL is following the email protocols and decides to reject the message or bounce it, rather than, e.g., assigning a score and moving it into the user-related mail store, it replies back to the IETF list manager, not the original sender. That means that the original sender never finds out that the subscriber didn't get the message. Indeed, there are other standards and norms that suggest that telling the sender is a privacy problem. (2) If that IETF server gets back a reject (i.e., a reply code, not an NDN) and follow the letter of the SMTP protocol, all it knows is that it got a permanent message rejection (5yz code) for a particular address. If it has logic to count the number of rejections for a particular address and does so, you've got exactly the situation Randy posits. The sender doesn't find out; the subscriber is left to notice a reduction in mail received and to then try to figure out what happened in what may be a very hostile environment. (3) If that IETF server gets back an NDN -- either because the DNSBL system is organized to send NDNs rather than rejecting messages or because there are relays (including SMTP-handling firewalls) involved -- things are basically hopeless because the number of mailing list servers that are able to accept NDN messages, correlate them with particular addresses on particular mailing lists, and take action on that basis is, well, small. Of course, one could "solve" that problem by sending the NDN back to the original message submitter, but that both violates the email specs and may violate privacy constraints. Of course, that list manager could be set up to route the NDNs to a human list manager but, especially if there are a lot of them, expecting the list manager to start making phone calls or engage in an extended email dialogue to track things down is unrealistic (I just verified empirically that reporting this type of problem to one of the large email providers who has been vocal in this discussion requires a phone call (no online reporting mechanism could be found), a long time on hold, and then talking with someone who was distinctly uninterested in the problem and didn't know (or wasn't interested in revealing) who the customer should talk with. You may believe that indicates a poorly-run system; I assume you that the operator would claim theirs is one of the best (indeed, that claim has been made on this list). If the answer is that the email protocols are now "wrong" given the demonstrated need for blacklists, then propose changes and see if you can get consensus. If you believe that the problem is the absence of established best practices, then charter a WG and produce such a document after having realistically done the case analyses about who is getting notified and who is supposed to be responsible to whom. But please don't waste our time blaming the subscriber or the subscriber's ISP based on de facto best practices that haven't been through any consensus process that ISP can reasonably be expected to know about. And please don't conflate "score and deliver" systems (which, admittedly, have their own problems) with "reject, bounce, or discard mail" systems. john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Re: several messages der Mouse
- Re: several messages David Morris
- Re: several messages Dean Anderson
- Re: several messages Randy Presuhn
- Re: several messages David Morris
- Re: several messages Matthias Leisi
- Re: several messages Steve Linford
- Re: several messages Peter Dambier
- Re: several messages Steve Linford
- Re: several messages Keith Moore
- Re: several messages der Mouse
- Re: several messages Chris Lewis
- Re: several messages Mark Andrews
- Re: several messages der Mouse
- Re: several messages Chris Lewis
- Re: several messages David Romerstein
- Re: several messages Randy Presuhn
- Re: several messages Chris Lewis
- Re: several messages David Romerstein
- Re: several messages David Romerstein
- Re: several messages Keith Moore
- Re: several messages Chris Lewis
- Re: several messages Al Iverson
- More anti-spam (was: Re: several messages) John C Klensin
- RE: several messages michael.dillon
- Re: several messages Matthias Leisi
- Re: several messages Mark Andrews
- Re: several messages David Morris
- Re: several messages Al Iverson
- Re: uncooperative DNSBLs, was several messages John Levine
- Re: uncooperative DNSBLs, was several messages Jim Hill
- Re: several messages John C Klensin
- Re: several messages Al Iverson
- RE: several messages Hallam-Baker, Phillip
- Re: uncooperative DNSBLs, was several messages Matthias Leisi
- Re: uncooperative DNSBLs, was several messages Al Iverson
- RE: several messages Anthony Purcell
- Re: uncooperative DNSBLs, was several messages Dave CROCKER
- Re: several messages der Mouse
- Re: uncooperative DNSBLs, was several messages Andrew Sullivan
- Re: uncooperative DNSBLs, was several messages David Romerstein
- Re: uncooperative DNSBLs, was several messages Jim Hill
- Re: several messages Chris Lewis
- Re: uncooperative DNSBLs, was several messages Chris Lewis
- Re: uncooperative DNSBLs, was several messages John C Klensin
- Re: uncooperative DNSBLs, was several messages Dave CROCKER
- Re: uncooperative DNSBLs, was several messages Tony Finch
- Re: uncooperative DNSBLs, was several messages Andrew Sullivan
- Re: uncooperative DNSBLs, was several messages John C Klensin
- Re: uncooperative DNSBLs, was several messages Matthias Leisi
- Re: uncooperative DNSBLs, was several messages Al Iverson
- Re: uncooperative DNSBLs, was several messages Andrew Sullivan
- Re: uncooperative DNSBLs, was several messages John C Klensin
- Re: uncooperative DNSBLs, was several messages Ted Hardie
- Re: uncooperative DNSBLs, was several messages Matthias Leisi
- Re: uncooperative DNSBLs, was several messages Ted Hardie
- Re: uncooperative DNSBLs, was several messages Tony Finch
- Context specific semantics was Re: uncooperative … Ted Hardie
- Clarifying harm to DNS (was: uncooperative DNSBLs… Andrew Sullivan
- Re: Context specific semantics was Re: uncooperat… Ted Hardie
- Re: uncooperative DNSBLs, IETF misinformation (wa… Steve Linford
- RE: Context specific semantics was Re: uncooperat… Hallam-Baker, Phillip
- Re: uncooperative DNSBLs, was several messages Peter Dambier
- Re: uncooperative DNSBLs, was several messages David Romerstein
- Re: uncooperative DNSBLs, was several messages Peter Dambier
- Re: uncooperative DNSBLs, was several messages Keith Moore
- Re: uncooperative DNSBLs, was several messages Chris Lewis
- RE: uncooperative DNSBLs, IETF misinformation (wa… michael.dillon
- Re: uncooperative DNSBLs, IETF misinformation (wa… Steve Linford
- RE: uncooperative DNSBLs, IETF misinformation (wa… michael.dillon
- Re: Context specific semantics was Re: uncooperat… Tony Finch
- Re: Context specific semantics was Re: uncooperat… John Levine
- RE: Context specific semantics was Re: uncooperat… Hardie, Ted
- RE: Context specific semantics was Re: uncooperat… Tony Finch
- Re: several messages Rich Kulawiec
- Re: uncooperative DNSBLs, was several messages Rich Kulawiec
- Re: uncooperative DNSBLs, IETF misinformation (wa… Al Iverson
- Re: Context specific semantics was Re: uncooperat… Ted Hardie
- RE: Context specific semantics was Re: uncooperat… Ted Hardie
- Re: several messages John C Klensin
- Re: several messages Al Iverson
- Re: Context specific semantics was Re: uncooperat… John L
- RE: uncooperative DNSBLs, IETF misinformation (wa… michael.dillon
- Re: uncooperative DNSBLs, IETF misinformation (wa… Al Iverson
- RE: uncooperative DNSBLs, IETF misinformation (wa… michael.dillon
- Re: several messages John C Klensin
- Re: several messages Chris Lewis
- Re: uncooperative DNSBLs, IETF misinformation (wa… Keith Moore
- Re: several messages Al Iverson
- RE: several messages michael.dillon
- Re: uncooperative DNSBLs, IETF misinformation (wa… Al Iverson
- Re: Context specific semantics was Re: uncooperat… Ted Hardie
- Re: Context specific semantics was Re: uncooperat… Douglas Otis
- Re: uncooperative DNSBLs, IETF misinformation (wa… Theodore Tso
- Re: Context specific semantics was Re: uncooperat… Theodore Tso
- Re: uncooperative DNSBLs, IETF misinformation (wa… Chris Lewis
- Re: more bad ideas, was uncooperative DNSBLs, was… John Levine
- Re: more bad ideas, was uncooperative DNSBLs, was… Chris Lewis
- Re: Context specific semantics was Re: uncooperat… John L
- Detecting and disabling bad DNSBLs Peter Dambier
- Re: Detecting and disabling bad DNSBLs Steve Linford
- Re: several messages Pekka Savola
- Re: more bad ideas, was uncooperative DNSBLs, was… Keith Moore
- Re: several messages Rich Kulawiec
- Is USA qualified for 2.3 of draft-palet-ietf-meet… YAO
- RE: [73attendees] Is USA qualified for 2.3 ofdraf… Song Haibin
- Re: several messages Tom.Petch
- Re: [73attendees] Is USA qualified for 2.3 of dra… Phillip Hallam-Baker
- Re: [73attendees] Is USA qualified for 2.3 of dra… james woodyatt
- Re: several messages John C Klensin