--On Saturday, 08 November, 2008 13:46 -0700 Doug Ewell <[EMAIL PROTECTED]> 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@ietf.org https://www.ietf.org/mailman/listinfo/ietf