.mail Domain To Eliminate Spam? 472
steve.m writes "The BBC are reporting on a new batch of top level domain names being submitted to ICANN for approval. By far the most interesting proposal is for a .mail TLD to register legitimate mail servers. Could this eventually be the end of spam ?" *yawn* The same old discussion, with no implementation in sight.
Ok.. (Score:2, Interesting)
However, (Score:2, Interesting)
IFFOR sponsored by .xxx (Score:3, Interesting)
IFFOR brought to you by nastygirls.xxx
Re:Obligatory spam solution rejection form (Score:5, Interesting)
Requires immediate total cooperation from everybody at once
Does it? Couldn't it be a "soft whitelist" until widely adopted? E.g., Everything coming from .mail gets a bonus in my e-mail filtering.
Re:Silly silly silly (Score:3, Interesting)
It's just now that some ISP's are starting to manage their own open relays, and now to suggest that we give them another system to manage/muddle while the never got it right the first time just reeks of a mess waiting to happen. And I have to purchase a new domain name?
For email to really work we need to continue with the Keys or other authentication methods, like in the old Heinlein books; or now the emerging technology of telephone number authentication before the call is allowed to be routed. If the lowest level of technology can figure this out, why not the top?
What am I missing? (Score:5, Interesting)
After reading this article and the one a few days ago about AOL and spam, I came up with this idea
I despise spam as much as most of you. My company is actually about to start a spam campaign against my recommendations. The day they start I will quit. Slashdot, here is my idea on blocking spam. What am I missing?
We all know what IP addresses belong to which countries. At work, we only deal with customers that carry professional certifications within the US. Of our client base, less than 1% of 1% of these customers and potential customers live outside the US or Canada. Therefore, I have blocked most networks outside of the US and Canada. The only exception is .mil. This has reduced my spam problem considerably. Add to this a Bayesian filter and my spam problem is essentially eliminated. This got me thinking...
ISPs should filter e-mail according to the user's requests. When you sign up for an account, by default, you can only receive e-mail originating/relaying from the US. Now, the user can go to their email configuration and pick which countries they wish to receive e-mail from. Most users only receive email from within the US and one or two other countries. If they only receive email from a few people outside the US, then just whitelist those address. If they want, Mexico, for instance opened, then let the user check the box next to allow e-mail from Mexico. Once this is setup, let the user decide if the e-mail failing to meet these conditions should be blocked or just moved to a separate folder for review. Another possibility is that if an e-mail originates from a blocked country and the spam filter thinks it's legitimate or just doesn't get a high spam score, send an NDR that says "Your e-mail looks like spam, but this could be a false positive. In order to deliver your email, please visit this site....." On that site, put one of the many methods to verify a human is actually visiting that site and then deal with the email accordingly.
For most users, the only noticeable impact would be less spam. This would also force spammers to send and/or relay from within the US. Now if they are operating from within the US, we have an IP address within the US's jurisdiction. Granted these may be zombie machines, so if your e-mail server does a reverse lookup before allowing e-mail, these would be denied. Also, we need to get ISPs to block most ports by default. If you want a port opened, you simply request it from your ISP. Add a clause like "by opening these ports, you are taking responsibility for any traffic on these ports. If we find your computer is sending viruses or spam or DOSing, then your service will be terminated." Again, most users would never notice a difference. Those that do notice can have the ports opened.
So now, for the average user, they would only receive e-mail originating or relaying from the US from a registered e-mail server. Now we can track this back to an ISP and shut down the account, seek legal action against the ISP for supporting spam, or black list that ISP. Since the spammer would have to have an MX record, you can get the registration info. This is probably bogus, so if we force registrars to verify the identity of the person, then we could actually track this back to a person. The spammer could probably falsify this too, but every step you add slows them down.
The spammer is going to now have to purchase an account with an ISP in the US and a registrar. Both of these entities should require a method of traceable payment. This means no cash. Now, we should have a means of finding who wrote the check or who the credit card belongs to. We now either have the spammer, the spammer's company (which should lead back to the spammer), or the spammer has now committed fraud. If he commits fraud, we now have the FBI after him and potential of longer jail sentences.
Not that I have to solicit criticism here on slashdot, but I'll ask anyways. What am I missing and why wouldn't this work?
change to SMTP over SSL (Score:5, Interesting)
Then you could have a distributed revocation authority where people could send copies of spams (still over the SSL network to eliminate fake spam for DDoS purposes). You don't want to get your certificate revoked, so maintain your server!
This makes the system more or less secure, and puts the burden onto mail server admins. You want your regular users to be able to send mail? Then don't let random people send spam.
Individual servers could then implement whatever authentication they liked for their users to be able to send. Maybe a C/R system or authenticated logins. Whatever.
Muerte
ps. i keep posting this idea. ha!
Re:I'm curious... (Score:3, Interesting)
Good luck (Score:5, Interesting)
Re:How? (Score:5, Interesting)
Just a few points
1. Who would verify the requests (worldwide)?
2. How do you REALLY verify an account is never going to be abused?
3. Where do you draw the line? Is a company of 20 allowed email? How about 4? How about just me?
4. How do you persuade EVERYONE who currently uses email to change?
5. How much do you think it would cost to make the switch globally?
Lemme get this straight... (Score:5, Interesting)
Exactly when is this supposed to happen???
For right now, the best solution is to...
1) Block IPs that are causing problems...this can acutally be automated...I'm working on a script at our site that passes all spam identified by spamassassin as a level 20 or higher into a blocklist for our MTA.
2) SpamAssassin...run SA as a service for all users and give them info on how to tailor it to their own preferences...
3) ClamAV...this catches some of the really nasty stuff...the ones that use exploits to "phone home" or run code on the user's machine...
These ARE and will be the only way to stop spam into the forseeable future. The only real way to stop it all would be a redesign of the protocol from the ground-up and that is just not going to happen...SMTP is already too entrenched into the backbone of the internet...it just won't happen...
You want a new goddamned standard? (Score:5, Interesting)
For your domain, put out a text file. In that text file, put the IP addresses or range of your server.
Name the file: mailservers.txt
For example... I would have (for DracoSoftware.com) a page called mailservers.txt. It would contain:
206.67.56.202
If I had a range, it could be either individual IPs:
206.67.56.202 206.67.56.203 206.67.56.204
OR, a range delimited by a dash:
206.67.56.202-206.67.56.204
Once we get sites to publish their legit mail servers, the rest is easy... Setting up servers who do DNS-like caching at your local ISP is easy. Your individual e-mail program can then do WHATEVER IT WANTS with the e-mail... Whitelist/blacklist/take into consideration for baysian filtering... whatever. The important thing is to get the legit mail servers published.
If a mail comes from legit mail-server... Easy.
If a mail spoofs a publicized server... easy.
If a mail comes from an unknown server, mark it as suspicious.
If people want, I'll start posting names of domains that were cool enough to create a mailservers.txt file.
Ready??? GO!
~D
Re:Only a way to extract more money from people (Score:5, Interesting)
say i have abracadabra.com and you have abracadabra.net - which one of us gets abracadabra.mail? Or are we talking abracadabra.com.mail and abracadabra.org.mail?
No need. (Score:2, Interesting)
A better requirement, though probably almost impossible to pull off due to negligence in the past, is to make sure that domains are registered to true, legal entities, and yank them if they are not.
Re:Good luck (Score:4, Interesting)
At the same time I was going through all this frustration, my colleagues back in in California actually configured our incoming mail server to use just the kind of dynamic-IP blacklist that was giving me a headache! Not too funny. Well, they've removed the blacklist now, which is good.
Still, I do wonder what the incentive is for the ISPs to use dynamic addresses. Are they oversubscribing their IP ranges? That seems stupid. Otherwise, why not give all customers their own, single, static address? Some of them are reserving this for a higher-cost "business DSL" service, but it would be up to the customers to put pressure on them to remedy this situation.
Deutsche Telekom, for example, makes it very expensive to get a static IP address. My ISP in the Netherlands, on the other hand, XS4ALL [xs4all.nl] (an outstanding outfit, IMHO) on the other hand, provides me with a static IP address for my business-class connection at work, but also for my entry-level connection at home. Customers should flock to the savvy XS4ALLs of the world and force the change.
Maybe I'm too hard on Telekom and their likes. Maybe they have a good reason. I'd like to hear it.
Re:Good luck (Score:5, Interesting)
I don't buy that excuse. Cable and DSL are always on. That means the customer always has an IP address. Even if the customer turns their PC off chances are the IP address is still reserved for some time (DHCP doesn't instantly time-out ya know?).
I think it has more to do with blocking servers and preventing people from using their home DSL account to host a Counterstrike server.
As a random side note I've held the same (supposedly dynamic) IP address on Roadrunner for seven months now. Explain to me the value of them using dynamic addresses again?
Holy cow, someone with their head screwed on right (Score:3, Interesting)
However, you have one point absolutely dead-on accurate. If you want to do any kind of server-side filtering, if there is any proposal to do so, *users* should have the ability to set this filter. Server-side filtering (as opposed to client-side) has a lot of benefits -- it means that clients don't have to be maintained, that users can easily switch clients, server-to-client bandwidth is saved, etc. However, it's *tremendously* frusterating when a server operator chooses to block something that a user specifically knows he needs.
Even if a good antispam system is put in place, it makes a *lot* of sense to let users have some kind of protocol, some set of extensions to SMTP, that let them alter server-side filtering associated with their mailbox. Maybe even expose a series of complex presets that the server can provide (SpamAssassin, block Asian-originating email, etc), and let the client enable them on his account. Provide an idiot-proof GUI to interoperate with this, and you're gold.
The main issues would be added server complexity and processing load.
Re:change to SMTP over SSL (Score:3, Interesting)
Because I can't think of one single entity that I'd trust to manage such a thing at a global level. Verisign? ICANN? Hah!
Verisign signs J. Random Spamfriend's certificate. JRS signs a spammer's certificate. See the problem? Maintaining a global PKI with near-real-time revocation is a non-trivial problem.
Yes, but also, what about freedom? (Score:2, Interesting)
Even if that weren't the case, I'm not comfortable with the idea that only certain entities have the power to decide who may or may not use a protocol publicly. The policy would have to be enforced to be useful, and enforcement would be a huge impingement on people's rights.
If you give certs away, there's no trust.
If you restrict them there's no freedom.
lose-lose situation.
Re:Good luck (Score:3, Interesting)
hell, I even remember a customers who had called to get his connection setup...he was paying extra for the "super speed super bandwith" package that was almost 100$ (canadian, mind you) a month, for 3 years and never even had a network adaptor of any kind to use it until then... And its a common story... And cable to some extent yes...but a lot of xDSL, on pppoe, are definately not always on, even if the physical link is always there.
And its pretty close to instant...in huge ISP, have 2 connections (a dialup or whatsnot?) at the same time...disconnect from PPPOE, and wait about 5 seconds, then ping your old IP of your xDSL...Chances are good it has already been reasigned... Messed me up once when our company's router had reseted without me knowing, and tried to access the router from outside by IP, and ended up on the -exact same router model, but from a different person-, cuz the IP had been reasigned...how long did it take me to realise why my password wasn't working...I felt so dumb.
For your roadrunner...yes, many cables ISPs are like that...and rarely change the IPs...you have a point. Might as well give you a static. Though the fact that a huge portion of their customers dont use their connection at all, is still a fact.
Re:Good luck (Score:3, Interesting)
Except for the fact that your proposed solution solves very little and causes major inconvenience.
In other words, it is a bad solution.
Why?
Now you know that whatever the mailserver suggests its hostname is, actually resolves to its IP.
It fails to verify in any way if that machien should actually be deliverign mail, and if the mail it delivers should be delivered by that specific server.
So, you ensure that people match the configured hostname with the one from a reverse lookup, and they can still spam you just as easily.
The one thing that does help is adding a specific record type for outgoing smtp servers to the DNS spec and verifying machines against that.
That verification can be done by taking the ip of the conencting server and comparing it to the forward lookups of any outgoign mailservers as reported by dns.
This actually addresses part of the header forging and does make it a lot more difficult to send spam, unlike what you suggest.
Re:change to SMTP over SSL (Score:3, Interesting)
1. The message is what the sender sent
2. The sender has the private key
Form here, you can go two ways. You can switch the whole world over to using PGP and implement networks of trust, revoking keys used for spamming, etc, etc. Or you can apply the solution to yourself only, require everyone to use PGP for mailing you, and reject all unsigned mail, assuming it's spam.
A few more ideas are accepting unsigned mail from known good addresses (so that your contacts don't have to start using PGP all of a sudden), and setting up a contact form on a web page to allow random people to contact you.
Personally, I don't get a lot of spam. Since I registered my domain, I use a new address for each organization I deal with. If I start getting spam on one of these addresses, I simply block that address, and as a bonus I know who gave me away. Unfortunately, I made a few posts on mailing lists with my real email address, which accounts for the few pieces of spam per week I do get.
Re:Good luck (Score:2, Interesting)
And no...we do NOT oversubscribe our IP address ranges. That would be lunacy, as 90% of the residential users out there have a router or leave their PC on constantly. I can't count on there being a certain percentage that won't be utilizing their connection...there needs to be an IP for each.
Why TLD? (Score:3, Interesting)
If this really was a good idea, then there's no reason you couldn't do it under a second or even lower tier domain.
I'd certainly trust randomdomain.approved-mailservers.spamhaus.org a lot more than randomdomain.mail
They should have spent the $45,000 fee on something useful - like legos.
-- this is not a
Typical (Score:3, Interesting)
Instead of starting with core infrastructure, they start with... registering domain names. Yeah.
Re:Obligatory spam solution rejection form (Score:3, Interesting)
Due to the exponential growth of the "tragedy of the commons" with respect to email, email will soon become so unusable that even a solution which "won't work" will work better than email as it exists today.
The only solution which makes sense from an economic point-of-view must attack the ( ) Sending email should be free premise for unsigned non-whitelisted email (except to maybe police tip-lines and rape crisis centers, et. al. who want to get anonymous email). Once someone figures out a protocol which does this half-decently and which can overlay the existing system of internet protocols and email addresses, normal Darwinian competition among mail agents and transports will push current insecure SMTP into a fringe niche (which smart providers should then charge extra for the use of, to help pay the network costs of carrying the garbage).
Long-Term Cyclic Effects (Score:3, Interesting)
Let's assume we implement some Bayesian filtering on a widespread basis. Let's then assume that most spammers go out of business, and that the amount of spam sent drops drastically. Sounds great! But after a year or two (or five) of this, it seems to me things will be ripe for new spam action. Some spammer will get a message past the filters, which ironically may be less effective due to the lower incidence of spam. Users who haven't seen a spam message in a year will open it, and all of a sudden this particular spammer is immensely profitable. Other spammers see his success and jump on the bandwagon, and pretty soon we're back where we were before.
Of course this is all conjecture, but I do wonder if we need a better fix, one that can guarantee results long-term.