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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf