MCI Boots Send-Safe
Criticism was apparently effective
TCP/IP co-creator Vint Cerf and his employer, MCI, have been under considerable pressure
from Spamhaus and other groups for hosting a number of spammers, and spam-software outfits like Send-Safe (from whom it's estimated they make $5 million yearly). The Send-Safe operation was apparently evicted over the weekend, found brief shelter with a Russian hosting company, then Tripod, but is now looking for a new home, a user e-mails us.
| |RR ConductorNWP RR Inc.,serving NW CAPremium
Redwood Valley, CA
Re: Public pressure works against prominent companies Sometimes.
| || Again, allow me to point out that the "zombie networks" would be completely ineffective if a DNS server refused all local MX record requests except from its own mail servers. Regular users have no need for MX lookups except for serving spam.|
MX requests from "the world" would be answered only for domains for which the server is authoritative. The only machines that could request any MX record would be those IPs listed in a conf file -- like your mail and web servers for example.
Think about it - it's much less restricting and inconvienent than a blanket filter on port 25.
Re: Public pressure works against prominent compan Errrm I'm no DNS expert but AIUI, if a SMTP server asks a DNS server for an MX record for which it is non-authoritative, the only way for the DNS server to find the MX record is to request it from a DNS server which *is* authoritative for the domain.
So if this is correct, you HAVE to continue to allow DNS requests for MX records from outside a small ACL of IPs.
And then how can the authoritative DNS server easily tell the difference between a legitimate request from a non-authoritative DNS server and a request direct from a zombied PC ?
| |pcscdmaChocobo Chocobo Random BattlePremium
| I thought that MX records were for telling SMTP servers where to send the mail.|
I'll send a mail to someone at dslreports.com using my ISP
My email client is configured to send stuff to mail.mchsi.com
My email client looks up mail.mchsi.com using my ISP's DNS lookup servers 22.214.171.124 or 126.96.36.199
It either finds it in the cache or tells me to go the dns server for that domain or does it itself (confused on how this part works)
My email client connects to 188.8.131.52 and sends the message
mail.mchsi.com (184.108.40.206) sees that I'm sending something to dslreports.com
mail.mchsi.com (220.127.116.11) looks up the DNS server of dslreports.com or finds it in cache using it's DNS server (probably the same as mine)
It looks to see if there is an MX record and if it finds one it uses it and looks up the IP address of them using DNS because the addresses are URLs
It tries the lowest priority number and goes up until it connects to one
If it doesn't find an MX record it just uses the web server (18.104.22.168)
It connects using one of the methods above and sends it on it's way
This is at least how I understand it.
"The bad news is that we are told that Michael Powell, one of Washington's better bureaucrats, is calling it quits today after four years at the helm of the Federal Communications Commission." - WSJ 2005/01/21
| a) compiling and maintaining the required whitelist is not some trivial task. I'd think it's cumbersome/tedious/problematic enough that that alone would deter anyone from going for it.|
b) what about the case where an ISP's caching DNS server is used by more than one class of user (ie residential, business users, their own mail servers, etc). How will you decide which request you will honor and which you won't? Perhaps you're thinking to force each mail server into running their own local DNS?
c) this doesn't seem much different than existing firewalling/blocklisting except that your protection is indirect... it wouldn't take much for an attacker to learn the IP address of the intended victim and then feed it manually to the zombies and then... what? The path is clear?
So... no... your approach would be far more ineffective, restrictive and inconvenient than an outbound/off-net block of port 25 traffic which does a better job of destroying a zombie's SMTP abilities. Of course, we don't need to rehash the pros/cons of port 25 blocking here... that's another topic altogether.
Perhaps, the following should be required reading
Re: Public pressure works against prominent compan That rhyolite link is great! I agree...it should definitely be required reading.
I'd say lurking in NANAE (»groups-beta.google.com/group/new···se.email) for a month should be considered required as well, but that'd fall into the category of "cruel and unusual punishment".
| || Ha ha ha - I don't think it's even near the final solution against spam. I do think it's one that hasn't been tried yet.|
Matchstick - You *do* allow your mail server to look up outside MXs. You just don't allow any other IP range(s) to do the same. And, your DNS server would allow anyone to request its own records. For example, if you are bob.com, anyone can pull the bob.com MX records. However, if a bob.com user's IP wants joe.com's MX address, the request is denied. If bob.com's email server wants joe.com's MX, it's allowed.
pcscdma - Your description is correct. However, the spambots do that entire process on your machine; they're their own mail server. That's why they shouldn't have access to MX records in the first place.
pog - There would be no true "whitelist" to manage and actually not much "management" at all. Simply block MX records from all except a few subnets or IP ranges.
I don't think anyone is thinking far enough into it before instantly deeming it useless. You're not blocking *your* MX records from ouside sources. You're preventing your users' PCs from obtaining ouside MX's and hoping others will do the same in return.
| |pcscdmaChocobo Chocobo Random BattlePremium
Re: Public pressure works against prominent compan
said by Mr Pilkington:That's the hard part.
... and hoping others will do the same in return.
| || Just for the sake of argument, I think you'd have to also block any direct outbound DNS queries from the zombies (client PCs) to outside DNS servers in order to make this at all feasible. Otherwise, the zombies could just skip the local DNS server and do an end-run around the whole system by querying the remote DNS servers directly.|
But isn't the point here that the referenced spam software is sending via the zombie ISP's SMTP server? In that case, there's no MX DNS query involved. I don't even see how you can really differentiate the zombie software from the legitimate user. The zombie just sends to the ISPs SMTP server and that server takes care of all the forwarding for it.
Maybe if all ISPs forced authentication for sending even from within their own network it would put a dent in Send Safe type systems. Does this Send Safe stuff steal auth info from the user's local legit email software? If so, I guess that'd be a dead end as well. Otherwise, going to a system that requires authentication over a secure channel for sending email might at least curb the effectiveness of this particular method.
not in ohio
So what's this got to do with Vint Cerf? I saw no mention of him in the article, and according to the DSLR writeup, his only offence seems to be to be employed by MCI.
He may well be involved in all this, but nothing you've written here indicates one way or another. Simply name dropping?
not in ohio
Re: So what's this got to do with Vint Cerf? Thanks, Karl - that's a useful part of the story.
| |fantomposterPhantom PosterPremium
| |said by Karl Bode:Not debating or giving you a hard time. Just explaining 'our' position on this issue.
No, though I'm not sure it makes sense, anti-spammers have been slamming Cerf as well.
MCI has been hosting Send-Safe for about two years. Playing nice was not working. Anything and anyone at MCI are fair game after 2 years, imho. Their paycheck was, in part, paid for by Send-Safe. Always keep in mind we are talking about the number one spam producing network in the world.