Re: several messages
"Chris Lewis" <clewis@nortel.com> Fri, 14 November 2008 19:55 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 C67843A67F0; Fri, 14 Nov 2008 11:55:53 -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 1A5533A67F0 for <ietf@core3.amsl.com>; Fri, 14 Nov 2008 11:55:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.659
X-Spam-Level:
X-Spam-Status: No, score=-6.659 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_00=-2.599, GB_I_LETTER=-2, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4]
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 T7o+IZj8Ztxo for <ietf@core3.amsl.com>; Fri, 14 Nov 2008 11:55:52 -0800 (PST)
Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id B48C93A635F for <ietf@ietf.org>; Fri, 14 Nov 2008 11:55:51 -0800 (PST)
Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id mAEJtmG05710 for <ietf@ietf.org>; Fri, 14 Nov 2008 19:55:49 GMT
Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Nov 2008 14:55:33 -0500
Received: from [47.129.150.171] (47.129.150.171) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.311.2; Fri, 14 Nov 2008 14:55:33 -0500
Message-ID: <491DD7B4.2080402@nortel.com>
Date: Fri, 14 Nov 2008 14:55:32 -0500
From: Chris Lewis <clewis@nortel.com>
Organization: Nortel
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
CC: "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: several messages
References: <Pine.LNX.4.64.0811121117180.8743@toro.popovich.net> <008601c944fd$950335c0$6801a8c0@oemcomputer> <20081113165601.GA2969@gsp.org> <B81943909B5DD6BFD3A486B3@p3.int.jck.com>
In-Reply-To: <B81943909B5DD6BFD3A486B3@p3.int.jck.com>
X-OriginalArrivalTime: 14 Nov 2008 19:55:33.0741 (UTC) FILETIME=[F47779D0:01C94692]
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
John C Klensin wrote: > 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. Whoa. You have this almost precisely backwards. In virtually all cases if the recipient's mail server is using a DNSBL, and it rejects an IETF-forwarded list item, it's because ietf.org's _own_ mail server is listed, and the ietf.org list admin is the person most properly informed of that fact. Which they will be by existing standard. In fact, if the DNSBL was widely used and you expected the IETF list to violate email standards and reply to the From:, the IETF list would be mailbombing everyone who submitted an article to it with almost as many copies of their email as there are IETF subscribers, few if any would be able to do anything about it, and the admins (who are most likely to be able to address the DNSBL listing) wouldn't know until someone complained directly to them. >From a different angle, in the use-case at hand (IETF items bouncing for whatever reason), if my email to the list gets bounced by, say, Joe's (any Joe ;-) mail server, who suffers? Not me. Who can fix it? Not me. What's the point of telling me? There isn't one. Not to mention privacy etc. Bouncing to From:/Reply-to is precisely the WRONG thing to do. You won't get argument about that from anyone that I can think of. [Partially because I remember when a MTA's propensity to bounce to the From: blew up the first incarnation of the Usenet Moderator's Mailing list. 15,000 bounces in the first couple hours via dialup. Ouch. It was over a week before the list came back up. I've caught Exchange 2007 doing it under some circumstances (at one of our own customer lists). Had 'em disconnected at their ISP until they fixed their server.] Experience seems to indicate that list owners when presented with persistent/intractable/difficult-to-handle bounces (other than DNSBL listings of their own server) simply consider it to be a problem with the recipient's mail server, unsub, and move on. Many list packages are instrumented for just that. The email standards are quite correct in this space. The reality is that this "problem" is a MUCH bigger issue with non-DNSBL filters that do content analysis. So again: this is NOT a DNSBL/reputation issue, but a filter implementation issue. > (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. Trying to impart better meaning to SMTP protocol returns in terms of filtering is a filter implementation and SMTP standard issue, not DNSBL. Secondly, as I'm sure Al Iverson and others can echo, there's significant amounts of intelligence that can and is be applied to the errors as they exist today, ESPs do it all the time. MAAWG has been trying to work this area and produce some sort of SMTP extension standardish thing (so ESPs can figure out how "permanent" a "permanent" SMTP error is supposed to be and what they should do about it), but has self-barred itself from some of the more obvious and convenient ways of doing this (eg: extensions to the 5.x.x extended SMTP return codes) by a perceived inability to get such suggestions past the IETF. They're probably not wrong for the same reasons that the very notion of DNSBLs is getting the reception here that it is. > 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. Rejects (by DNSBL or any other filter) in no way prevent the recipient also finding out (by quarantine, junk folder, email notification or otherwise) that that email was rejected. Again, this is a filter implementation BCP issue, not an issue specific to a technique (DNSBL or content filter or ...). > (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. I don't agree. In fact, most ESPs, Yahoo, and many common list implementations (eg: mailman and I believe LISTSERV) have and use this capability now. With ESPs, for list pruning. At times, I've become quite familiar with Yahoo's "your subscription bounced too often, I've unsubscribed you, here's how to resubscribe, and <here> is your missed messages". Annoying, but no great harm. Hasn't caused me to change how the filters that caused those bounces work. > 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. It would be precisely the wrong thing to do as outlined above. > And please don't conflate "score and deliver" systems (which, > admittedly, have their own problems) with "reject, bounce, or > discard mail" systems. Please don't conflate "reject, bounce or discard" uniquely with DNSBLs either. The former is a general filtering issue. The latter is merely one filtering decision technique of many. DNSBLs (true with most other techniques) in no way preclude the use of score/junk folder/quarantine/recipient notify at the same time or in place of reject/bounce. Most large implementations do a combination of both on the same email. We certainly do. _______________________________________________ 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