Subject: Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

From: John C Klensin <[email-masked]>
Date: Sat, 08 Nov 2008 19:55:09 -0500

--On Saturday, 08 November, 2008 13:46 -0700 Doug Ewell
<[email-masked]> wrote:

> Several years ago, my employer's e-mail spam filter blocked
> the Unicode mailing list as a "suspect site."  Earlier this
> year, GoDaddy (registrar of my domain name) did the same, and
> it took months to figure out what was going on.  It's
> conceivable that someone might have used this high-profile
> mailing list as part of a spam, at some point, but to block
> the entire domain is complete overkill.  I'm no expert on
> e-mail security, and I detest spam, but there is such a thing
> as a cure that is worse than the disease.

I've got two separate and unrelated incidents in the last 10
days in which RBL lists have decided to block some (but not all)
of Comcast's outbound mail servers.   Note that these are not
messages being sent from the desktop of a Comcast cable modem
customer direct to a destination but messages sent from the
customer to Comcast's mail servers acting as submission servers,
to a destination... and blocked at the last step.   That class
of thing has become an epidemic.

What I don't know is whether Comcast is moving servers in and
out of address pools that are used to service residential users
(so that the RBL lists can't keep up) or whether "bad guy by
rumor" tactics are being used to punish Comcast for aggressive
use of RBLs, or whether this is just random nonsense.    I do
know an increasing number of Comcast customers who are switching
their primary mailboxes to other services because of
seemingly-unpredictable blocks to their incoming and outgoing
messages.  Perhaps Comcast likes that -- lowers expenses without
lowering revenues -- but I hope that motivation has not been
considered.

Two additional comments to avoid sending more messages in this
thread, parts of which have started to resemble a religious war.

* The "reject at SMTP time, rather than generate NDNs, all there
will be no blowback problems" is bogus unless one managed to
design one's mail environment to completely eliminate relaying
or one has some other highly secure and reliable way to
authenticate senders (not just sending servers or permission of
identities to send from those servers).  A change to get rid of
relaying would be, IMO, another significant change in the
architecture, whether one believes it is feasible or not.

* Regardless of the particulars of the email environment and
what people (I think temporarily) have been able to get away
with on the Internet, the business of being a third-party who
evaluates and/or certifies the reputations of others is
traditionally a very serious one in the real world.
Organizations that do it traditionally assume huge liabilities
that they may, or may not, be able to constrain depending on
what people use the reputations to do.  Libel laws often apply,
especially if ones procedures are lax enough (or depend enough
on unsubstantiated rumors) to constitute reckless disregard of
the truth.   Many years ago, when the IETF and others still
believed in general-purpose cert issuers and we weren't far away
from the "one true root" model, Jeff Schiller famously commented
that an organization would have to be insane to take on that
general purpose role without sovereign immunity.

If IP addresses weren't such a lousy instrument, I could find
myself believing in RBL databases if the parties taking
responsibility for the entries would identify themselves in
clear and authenticatable ways and post bonds against
accidentally damaging the reputations of people and enterprises
by accusing them of being spammers.  That is unlikely in the
present environment because the current environment gets one
blacklisted by inference and anonymous rumor, with some list
maintainers bragging about how they can't be found or affected
by legal processes.  It is not clear to me that such
arrangements would have much to do with the DNS, for reasons
that we should probably all understand by now.   It it also not
clear to me that facilitating interoperation among that class of
operators is a good thing, although I could be convinced that it
might be a step toward more maturity and responsibility in the
business.

As a thought experiment, if Nortel or Comcast are developing
these lists and like them, are they willing to assume liability?
If not, what does that say about the model?

      john

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John Levine <[email-masked]>
Date: 9 Nov 2008 01:24:07 -0000

> I've got two separate and unrelated incidents in the last 10 days in
> which RBL lists have decided to block some (but not all) of
> Comcast's outbound mail servers. ...

I remain baffled by this line of argument.  

If anecdotes about DNSBLs not run the way you like disqualify even
describing the technology in a standards track document, how could you
in good concience allow the publication of RFC 5321, which describes
the technology used to send several billion phishes, 419 scams, and
penis pill ads every day?  The vast majority of SMTP usage, over 95%
of all transactions, is for mail that is unwanted, fraudulent, and
probably illegal.  I dare say that considerably less than 95% (heck,
less than 1%) of DNSBL lookups produce a problematic result.

R's,
John

---

From: "Livingood, Jason" <[email-masked]>
Date: Sat, 8 Nov 2008 20:58:08 -0500

John C Klensin wrote:

> of Comcast's outbound mail servers.   

Interestingly, this draft is about both blacklists and whitelists.  Many large domains maintain whitelists of other large mail domains.  For example, our comcast.net outbound servers are all listed here at http://postmaster.comcast.net/outbound-mail-servers.aspx and you can get an RSS feed of the addresses so that you can get updates.  But every large sender tends to do this in an entirely different way.

And, here is how we list our dynamic IP address space, at http://postmaster.comcast.net/dynamic-IP-ranges.aspx and in RSS feed at http://postmaster.comcast.net/dynamic-ip-ranges.xml.  In the case of dynamic space, several DNSxBLs exist that aggregate ISP dynamic IP space to make it easier on large domains to put all of those together.

Jason

---

From: "Chris Lewis" <[email-masked]>
Date: Sat, 08 Nov 2008 22:40:26 -0500

> these lists and like them, are they willing to assume liability?

One would _assume_ you mean "assume liability if we lost a lawsuit",
rather than fork out money to anybody who sticks their hand out.

Well, of course we do.  We wouldn't be doing it if we didn't - we can't
wave a magic wand and escape the law.

We have MUCH bigger worries than legal liability like you're talking
about here.  Losing an important sale because of a filter mistake is a
far more likely risk than getting sued.  So, no lost legitimate email is
the absolute overriding priority.

Or, are you thinking that a whole new set of law needs to be created to
cover the source IP-based version of filtering, and holds DNSBL
operators to a higher standard than anyone else?

Why?  There have been many legal actions already.  A few losses, but
mostly wins.

Note also: e360 vs Comcast.  e360 sues Comcast for source-IP blocking
them.  Case thrown out on summary judgement.  Comcast has absolute right
to do it explicitly enshrined in the DMCA "hold harmless for good faith
blocking of objectionable email" clause.

This is probably extensible to the suppliers that ISPs use to do that
blocking.  Hence, DNSBLs are also immune as long as the plaintiff can't
prove bad faith.

That case is not entirely over yet, but the final result isn't going to
be any different.  Comcast's counter to the initial complaint is amazing
reading.

> If not, what does that say about the model?

Legal theory around DNSBLs has already been partially established in
case law.

Your questions have already had their answers demonstrated in a way that
only enhances the model.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf