--On Thursday, 13 November, 2008 11:56 -0500 Rich Kulawiec
<rsk@xxxxxxx> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf