ietf
[Top] [All Lists]

Re: several messages

2008-11-14 14:56:21
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf