--On Saturday, 08 November, 2008 13:46 -0700 Doug Ewell
<doug(_at_)ewellic(_dot_)org> 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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf