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