Spam Slows AT&T Email 272
jonerik writes: "MSNBC has this article about AT&T's frustration with the increasing quantity and sophistication of spam traffic. As has been noted here already, much of it these days is originating from Asia and, according to the article, 'now represents 20 percent of all e-mail floating around the Internet.'"
Spam from Asia? (Score:3, Funny)
War on Spam (Score:4, Insightful)
The War on Spam must be fought on several fronts, not just one. These evildoers can be defeated by striking them in American courts and fixing the open-relay problem in Asia.
Re:War on Spam (Score:2)
Are you telling me that those spams actually originate in the West?
Riiiiiight. Move along folks, nothing to see here.
Re:Spam from Asia? (Score:3, Insightful)
Re:Spam from Asia? (Score:2, Interesting)
Can we classify spammers as terrorists? How about the Church of $cientology?
email for the DMA: mailto:wboell@dma.net [mailto] sign them up for some porn ads. =P
Re:Spam from Asia? (Score:2)
Re:Spam from Asia? (Score:3, Informative)
What the rest of the world needs is legislation (not only!) in the US against those trying to sell via this irritating system.
Re:Spam from Asia? (Score:2)
So don't stress out about not being able to buy the products. Be glad.
It is already illegal to sell using fraud. The problem is trying to track down and prosecute every spammer.
Re:Spam from Asia? (Score:4, Funny)
.
Re:Spam from Asia? (Score:2)
Re:Spam from Asia? (Score:5, Funny)
Friend, are you having trouble reading your mail? Did you know that Chinese is spoken by over 1.3 billion people?! Take our quick and easy class today! Just call 800-555-1212 and start learning Chinese, Korean or other Asian languages.
This post is not spam! You received this because you joined the opt-in Slashdot and agreed to receive from other list members. This message is sent in compliance of the proposed bill SECTION 301, paragraph (a)(2)(C) of S. 1618. If you wish to be removed please click on the remove link below - Thank you again for giving permission for us to send you offers we believe will help you succeed. Click here if you no longer want to receive gifts or special offers: http://www.sendmemorespam.com [sendmemorespam.com]
498731497
Re:Spam from Asia? (Score:2, Insightful)
Add to that the number of purely malicious individuals taking their spammy little affairs to servers outside the US to keep bulletproof status, and of course they're going to blame Asia!
He who does nothing to aid us is our enemy, or I think President Shrub said something like that.
Re:Spam from Asia? (Score:4, Insightful)
Just goes to show the level of technical (in)comprehension among suits and reporters. Both groups seem to have a difficult time using simple words like "originate" properly.
Most of the spam I get comes *via* asia (with a rising amount coming from Spain and Portugal lately too) because there are a lot of abusable relays in those areas. But the actual *origin* for most of it seems to be some guy with a cable modem in Arizona.
Oh, btw, it's just as annoying getting spam for it when you are here in the USA, spam is just annoying period. The most annoying spam I think is when it's for something I might actually be interested in - because there is no way I'd buy ANYTHING that's spamvertised, so a spammer could actually cause me not to get something I want. That's pretty rare though. I think the last time that happened was probably when I got spammed by a BeOS distributor a year or more back.
The enemy is obvious. (Score:2, Interesting)
Re:Spam from Asia? (Score:2)
Here's a header of one such email that gets through their open relay:
Received: from lo (61-216-36-158.HINET-IP.hinet.net [61.216.36.158])
by chmls21.cp.ipsvc.net (8.11.6/8.11.6) with SMTP id g1ENgSp04151;
Thu, 14 Feb 2002 18:42:30 -0500 (EST)
Date: Thu, 14 Feb 2002 18:42:30 -0500 (EST)
Received: from yahoo
by yahoo.com with SMTP id jKPDvKWyIdxNwan;
Fri, 15 Feb 2002 07:37:42 +0800
Message-ID:
From: mark@sayhi.com.tw
To: 0125ok.txt@chmls21.cp.ipsvc.net, 0102ok.txt@chmls21.cp.ipsvc.net, 0103ok.txt@chmls21.cp.ipsvc.net, 0104ok.txt@chmls21.cp.ipsvc.net,
0105ok.txt@chml
0107ok.txt@chml
0109ok.txt@chml
0111ok.txt@chml
0113ok.txt@chml
0115ok.txt@chml
0117ok.txt@chml
0119ok.txt@chml
0101ok.txt@
Now, thankfully I use spamassassin and I can modify the filter, but AT&T better work on their own mail servers, too.
Re:Spam from Asia? (Score:2)
However, I hope i am translating the above properly, but I'm glad I have a spamassassin rule to flag ALL email from hinet.net and seed.net as spam which goes directly to my catchall folder for spam.
Even if the above relay wasn't AT&T's own relay, then AT&T should express some pressure on ipsvc.net and get that relay secured where header spoofing is not allowed.
Re:Spam from Asia? (Score:2)
duh, challenge response! (Score:2, Informative)
1. Close all open relays. That way the route of email is from your ISP to their ISP. [well at least as far as SMTP is concerned]
2. Use a HashCash [cypherspace.org] like system.
3. Actively deny connection from IPs that try to connect more than N times in L seconds.
Duh...
Re:duh, challenge response! (Score:3, Interesting)
So I should shut my mailserver off because YOU get too much spam, I think not.
and oh, my ISP made the mistake of having the web server release the
IPs that try to connect more than N times in L seconds.
gosh I'm sure the spammers will never notice that one
I cant get to the hash cash but if it's the old "generate a hash key for each email" it's equally flawed. Spammers have plenty of time
TMDA is one way, to prevent you from seeing spam
Re:duh, challenge response! (Score:2, Funny)
Just be glad you're not in jail for knowing that and telling them.
Re:duh, challenge response! (Score:2)
For example, my workstation is able to test 27,000 hashes per second. A 19 bit hash collision takes on average 20 seconds to produce at this rate. If I am charged by recipients a 19 bit hash for each email I send, I can only usefully send 4320 mails per day.
I send a weekly newsletter to our registered members. It's not unsolicited. We have over 50,000 registered members and our two year target is 100,000.
My current server is nicely specced. 800Mz P3 256mb ram, 20gb HD. It easily serves the website and the newsletter. It's going to be 5 years before it needs any sort of upgrade. I like this.
With HashCash suddenly I'm going have have to consume 23 days of CPU time per 7 days. So I'm going to need another 3 machines JUST TO SEND THE NEWSLETTER. And in 5 years time maybe I'll need at least another 2. So with a mtbf for HD's of about 5 years suddenly my co-lo is going to see me once every year instead of once every 5.
And all because YOU couldn't look after your email address properly.
thanks.
Re:duh, challenge response! (Score:2)
To use your own example against you, consider this -
First, there is no single yahoo.com mail server. They host millions of email accounts, and probably have several back-end servers handling the volume of received mail. You couldn't sent mail directly to the mail server if you wanted to. Even at the front-end side, a quick mx lookup shows three servers which will accept mail for the yahoo.com domain. There are multiple paths that email can take en route to its destination, and they are each just as valid as the others.
Secondly, most home users don't even operate an SMTP service. Their messages necessarily have to go through one or more relays, to be queued, and resent if there are delivery problems the first time. The alternative to this is to require everyone to operate a full-blown SMTP service on every machine from which mail might originate, so that they can handle things like delivery delays, bounced messages, and the like.
The reason that email works like this is that the Internet is a collection of Inter-connected networks, which don't necessarily pass all traffic freely between each other. Companies have border routers and firewalls, or use Novell or other non-ip-based networks internally, but the email still has to end up at the recipient's machine. This is fundamentally different than the way that the World Wide Web works. On the web, you can assume that every HTTP server has an IP address, and you can contact it directly. With email, you can make no such assumptions. Not everyone uses POP to get their mail from publically accessable mail servers.
Of course, that being said, I agree that closing open routers is generally a good thing. There really is no reason for mail to have to pass through more than one relay to cross the public portions of the Internet, and mail that does should at least be forced to be honest about its origin. This would do a lot to discourage spam.
Anyway, I'm sure you knew most of this already, but I am dismayed by the number of people who think that stopping spam is a simple matter of 'fixing' the routing, and that email is essentialy the same thing as HTTP, only on port 25.
Re:duh, challenge response! (Score:2, Insightful)
Then I think to myself, "this isn't working. there needs to be a fundamental change to how we receive email."
And the first thing that pops into my mind, is white list email. Well, there goes 100% of the spam problem, unless you have sleazy friends.
What happens when someone not on your list sends you an email that you actually need to get? *sigh* It then falls back to us fighting the loosing battle.
Re:duh, challenge response! (Score:2, Interesting)
Then you can setup some form of payment scheme based on the scheme. Like if an IP has a score of -5 they must do the equivalent of 5 seconds of work [say find a 24-bit hash collision given a challenge from the server] before the email is even processed. That way if a server keeps abusing your server they will not get much through quickly. You can even perform one sided signatures to verify they didn't make up the challenges.
For example,
your server has a random key [fixed] say 128-bits call it K
When I want to send a message you send me a timestamp T, a challenge string R and the result of V = hash(T || R || K) where || means concatenation.
I then have to find a k-bit collision for hash(T || R) which I send back with V, T and R. The server can then verify that the packet is legit since it can check that hash(T || R || K) == V [these are the values sent back except K which only the server knows]. The server can then check that the collision is valid.
Some basic rules for scoring [e.g. demerits]
1. Sent from any type of relay
2. Sender matches a known abuser [i.e ORBS list or something]
3. reply-to does not point to the address of the sender [e.g. fake reply address] or otherwise invalid return path.
4. message matches some known heuristics [e.g. virus, worm, spam]
5. Sender has tried to open a port L times in the past N seconds.
[etc]
That won't stop people from openning a zillion connections but it will stop spam from reaching the end consumer as quickly [not entirely] as before.
This is also less user oriented. This system is intended to punish the ISP not the end users. So an ISP which has low ratings will have to clean up their act on their own [e.g. its in their own interest].
You're thinking "so you want my server todo work?" here's the beauty of the scheme though. If you have a >= 0 rating then the other server will not make you do any work. So as long as your system is clean there is no pain.
Tom
Re:duh, challenge response! (Score:2)
From tomstdenis.home.dhs.org/ [dhs.org]
<Page Cut>
Pro MS?
Yeah you heard right I am pro-MS. Why? Because nobody else is.
As you read this Perl processed Apache served page please keep an open
mind why I think MS is not such a bad company.
The monopoly
Ok so you guys think because MS packs IE and MSN stuff with Windows it
is a monopoly right? Well monopolies only exist where alternatives are
removed from the playing field. Goto msn.com and type in Mozilla into
the search box.
</Page Cut>
Oh well even the smart ones can be misguided :^)
Designated email deliverer. (Score:3, Interesting)
Your P.O box, however, can only be given mail from the actual Post Office. (I'm making an open-relay analogy) Nobody can walk in from the street and legally place mail into your mailbox. Although using a Post Office type deliverer for mail won't filter any spam, it will keep messages that are sent from outside the "post office" deliverer.
So, we need to decide that email doesn't work for private internet messages and come up with a different tool for getting personal messages online, otherwise we will continue to get spam.
Re:Designated email deliverer. (Score:2)
I don't think this would help any. I jsut just as much crap in my meatspace mail box as I do spam. The only thing you would end up with is people bidding to pay off the "post office" so they could send you crap.
The only was I can think of to make something like this work is setting up an allowed sender list. Of course that won't work either, I'm sure you can think of 100 resons why in a minute.
Until spam is absolutely useless to the sender it will continue to be a problem
Whitelists are the only way to fly (Score:2)
I still keep an AOL account, and it was YEARS ago when it hit the point where it became more convenient to block all mail and have to add someone's address to my whitelist before they could send me anything, than to delete all the spam that hit that account without the whitelist.
I do much the same thing with my regular e-mail client. The last rule enacted on messages that aren't filtered out by the rules before it, basically puts everything into Deleted Mail, and it gets trashed automatically after 3 days. I peek in there once per day and almost never have to adjust any rules because non-spam accidentally was marked as spam.
~Philly
Spam ... (Score:5, Insightful)
1 Sysadmins living in a 'clue fee zone' must be wised up. This means, amoung other things, more education for sysadmins, better products and documentation, better or more translations of documentation, etc. It should be easy to obtain documentation in your local language. Every HOWTO has to have an accurate, up to date translation readily available. As should documentation for proprietory products.
I don't like viruses nor encourage illegal break-and-enter of another person's computer, but a 'whitehat' virus that shuts down the relay component of an email server would be damn handy.
2 The economics of SPAM must be altered, literally turned on their head. It costs to receive bandwidth, but (generally) little, or none at all. (The obvious exception is when you have a bandwidth intensive site that requires nice fat outward pipes). It costs so little to send, just electricity, enough money for a bulk sender (off the shelf or home brewed) and a net connection. Pay the real cost of outgoing mail and watch the volume of spam decrease to an approximation of zero.
Don't know how this last one will be achieved except via a totally new version of 'the net' (or at least a new set of RFC's).
Re:Spam ... (Score:2, Insightful)
Re:Spam ... (Score:2)
Sysadmins who can't read english documentation can't read english spam complaints either.
Surely, they don't have to know much english to know that a message sent to abuse with the subject SPAM is a spam. There's not really much need to read the message itself at that point.
Re:Spam ... (Score:2)
In researching this question, I came across sites that sell software that will do the above. See
Even worse, they will test email addresses against servers they find, locating the valid ones. And, some sell services that will do use this sort of software to send the spam.
Finally, where are most customers located? How about hotmail.com, aol.com and a few others. How hard is it to simply use THEM as the server for all the addresses going to those domains? Then you are not relaying at all. Of course, they may have filters that cut off an SMTP sender after N messages, unless it is a trusted address.
Re:Spam ... (Score:2)
Use the PREVIEW BUTTON, Luke!
The site selling spam software is: [marketing-2000.net]
http://www.marketing-2000.net/
Re:Spam ... (Score:2)
Don't know how this last one will be achieved except via a totally new version of 'the net' (or at least a new set of RFC's).
No need to make everyone pay because of a few spammers. Just a manditory fine of $10 (or equivilent) per spam when caught. If an ISP chooses to look the other way (spamhaus), they either get to pay the fine themselves, or have the plug pulled.
The real challenge is to keep the rules tight enough to stop the spammers, but loose enough to avoid punishing innocent providers and users who are victomized by a spammer.
Economics of Spam (Score:2)
Perhaps we need to educate the sysadmnins who keep relays open that the spammers are stealing their bandwidth and system resources, not just those of the people who get spammed.
Re:Spam ... (Score:2)
The economics are screwed up somewhere. And I know where it's screwed up. Internet users do not pay for internet usage. They do pay for hookup, maintenance and service, but they don't pay for use. Someone who sends out one email a day pays exactly the same as someone who spams out ten thousand a day.
Bandwidth isn't free. But no one is charging for bandwidth. So here's my very radical solution: start charging for bandwidth. Your ISP charges you according to the bandwidth you use. And the ISPs in turn pay for the use of resources owned by other providers, services and institutions. Forget about information wanting to be free, because I'm not talking about information. I'm talking about routers, servers, cables and lines. Someone owns that router two hops away that has to route ten million pieces of spam a day. The owner of that router needs to start charging for its use. That owner may not know the ultimate origin of a peice of spam, but they do know which in which direction it came from.
Then to top it all off, start suing spammers for where appropriate. Sue them for hacking your server. Sue them for spoofing your address. Sue them if your penis doesn't grow four inches after smoking temple kiff. It may be difficult now to sue them for much of this stuff, but when bandwidth actually costs money, you're able to walk into court with a detailed list of monetary damages.
This won't stop spam. Nothing will. But it will do wonders for reducing it. Just start treating the internet as owned property instead of some mythical village commons.
Re:Spam ... (Score:2)
Eventually those millions of spams translate into millions of individual emails, all clogging up the works. Those few megabtytes eventually become several gigabytes. Those gigabytes use limited resources. By charging for those resources, the fees eventually filter there way back to the spammer.
Like I said before, I'm not a networking expert, but here is a possible scenario. Spammer sends out an individual email addressed to one thousand recipient. The spammer's ISP sees 1K of bandwidth. So far the charges to the spammer is one one cent. But suddenly the message hits a node that routes that single message off in ten different directions. The ISP gets charged ten cents, which he passes on to the spammer. And those ten split them off again ten different ways. And once more. Those charges filter back to the spammer for ten dollars.
Re:Spam ... (Score:2)
While I agree that education is a good thing (tm) as is documentation in lots of languages,
in the end I think this is a hopeless task. It's always September somewhere on the net, and if it only requires a tiny percentage to be clueless to screw things up, then things are going to be screwed up perpetually.
In 2001, bandwidth could be bought by the end consumer for less than $5 a gigabyte, (a lot less if you knew what you were doing). A typical spam is less than 10K. (Based on a semi-random sampling, 5.2K per spam.) That makes the cost, under 1/200 of a cent. If you don't send 1 to 1, and you're efficient about sending it, it's about 50 times better, or under 1/10,000 of a cent per spam. (We could revoke that bit in RFC 821 that says you have to accept at least 100 RCPT commands for each email, but that would hurt legitimate mailing lists and ISPs a lot more than spammers)
The problem isn't that spammers aren't paying for bandwidth. They do. They even offer to pay extra if they can keep spamming. If you want to make a change through economics, you need to make spam cost a lot more. For example, if sending an email to a recipient was a dollar, which was refunded if the recipient agreed it wasn't spam, then you might reduce spam.
-- Is a no soliciting sign spam?
(Very) Slowly self-healing (Score:3)
No way (Score:2)
No way... It's come from brand new machines with dual processors and half a gig of ram that are ready to process a LOT of email.
These people aren't being exploited with open relays... Some are but most aren't. They're being paid to place open relays out there.
What do they care, American businesses want to pay them to spam Americans. Many of them don't even like Americans anyway.
Asian ISPs don't care or we would have heard from them by now.
Blacklisting Asia is not such a bad idea. The biggest problem with blacklisting asia is all the people that won't unblacklist them if they get their problem fixed.
Any open relay honey traps? (Score:5, Insightful)
Re:Any open relay honey traps? (Score:3, Informative)
http://www.iks-jena.de/mitarb/lutz/usenet/teergru
Re:Any open relay honey traps? (Score:2)
Re:Any open relay honey traps? (Score:5, Insightful)
Then I thought about it for minute, and said to myself -- that just means the spammers will learn to test for honeypotness, and the technology based war just has another exchange, but the war is still ongoing.
My father was a businessman, and he first exposed to the Internetet email concept about 6 years ago when I explained it all to him. His first non-technical question was, "Who pays for the email?" I should have listened to him. Instead, I said that it was basically too cheap to meter, whereas he saw it as a potential for abusive business practices because he remembered history where the first postal service made the recipient of the mail pay for the delivery, but was changed to the sender fairly quicker because of the abuse.
The war on spam is the good war of our generation, but I'm afraid it may be the war of our kids generation too unless we get serious about nuking the spammers.
Re:Any open relay honey traps? (Score:2)
Re:Any open relay honey traps? (Score:2)
Re:Any open relay honey traps? (Score:3, Insightful)
Interesting thought, anyway.
Re:Any open relay honey traps? (Score:2)
1) You can just go ahead and notify all of the proper folks - ISP, blackhole lists, &etc. in advance. Not only will this server never legitimately send mail, so filtering everything that appears to come from it is desired anyway, putting your self on the open relay lists is a great way to attract low end spammers.
2) The code is provably not an email server, and will never be used as such. Of course, one should always check with one's uplevel provider to make sure of their policies, but running a daemon that responds like a relay but never actually sends a single email anywhere is unlikely to be illegal.
3) It doesn't matter. The simple act of the spammer checking to see if mail is delivered to a known location is enough to ID the source as an abuser - it isn't necessary for them to do anything else. The server is not advertised as being a mail server and will therefore attract not one single legitimate access. Any source that sends the trap server anything at all on port 25 beyond portscan traffic should be logged, filtered, and reported. (I don't like portscans, either, but this is to be specific against spammers.) Sure, it would be nice if the spammer spent more time with the server so that more of his operating habits could be revealed, from his test methods to the fingerprints of his outbound messages, but by touching the system at all he has already been caught. That's the beauty of running a honeytrap that is narrowly targeted and isn't advertised - there is no valid traffic to be ignored, no innocent use that needs to be permitted while sifting traffic logs for attacks. Barring use of psychic abilities, the only way for a spammer to know that the box in question is a trap is to access it in a way that will already catch them out. It might not be enough to get them TOSsed off their ISP, but it will be enough to get them known as a spammer and possibly added to the filter lists.
How about Universities (Score:2)
Spam Assassin, netblock ORBS (Score:5, Informative)
The other possibility is a net-block equivalent of ORBS. Some on the Sec-Focus Incidents list (and other fora, over the years) have bounced around the idea of blocking netoblocks who'#s POCs don't work, or who don't have or respond to mail to the RFC-mandated abuse@, security@, hostmaster@,.. standard mail accounts. I'm all in favour. Automate probes, the way ORBS did for anonymous relays. I think this would be a Good Thing. People do have a legitimate need to communicate between Asia, America and Europe: simply dropping everything from .kr is evil and wrong, IMHO.
Finally - y'all know that anonymous HTTP proxies are just as bad, if not worse, than traditional open mail relays? Just testing ;)
Re:Spam Assassin, netblock ORBS (Score:2)
So I consider my problems as an end user of email basically solved. The only drawback is I'm still paying for the bandwidth to download all this crud... Now if only the major ISPs ran SpamAssassin themselves...*
*Note: there's probably a big commercial opportunity here for SpamAssassin or a similarly sophisticated "fuzzy logic" spam detector!
Re:Spam Assassin, netblock ORBS (Score:2)
SpamAssassin has only let one spam through with no false positives yet (though I'm told that it does give false positives from time to time, mostly based on people who are unfortunate enough to have a source address or mail software associated with spammers.) The one that got through was a pretty unobtrusive spam, too.
All in all, the effort to pull those few false positives out of the spam bucket is pretty minor compared with seeing the massive spam flow every day.
Optionally publish valid mail servers for domains (Score:5, Interesting)
In the same way that RBLs are published via DNS records, it could be useful to have a scheme whereby for your email domain you can advertise (via dns) what hosts are authorised to send email for that domain.
So a mail comes in from a yahoo.com address, you do a dns lookup on the incoming connections ip address appended to validservers.yahoo.com or whatever the convention decided upon is, and the result would tell you if it's valid. You'd also need a way to check that yahoo.com is actually advertising the valid mail servers (and if it isn't, you failsafe and accept the mail).
This scheme wouldn't be compulsory, and would probably be suited mainly to free email providers, large corporates. The downside of it is that if you have a yahoo.com address, but want to run your own smtp server to deliver your mails, then you'd fall foul of such a system. I don't think that's a biggy though - if you could run your own smtp server, you'd probably not use a yahoo.com address you'd have your own domain
While I'm rambling, another system which could be done is a protocol for verifying email addresses (you could also do this via dns too, I guess, but dns is getting cluttered enough as it is). For a given email domain it has an entry (in dns) for an email address verification server. When an email comes in, you check if there's a verification server for the source domain of the email, and if so try connect to it, and then submit the email address for verification. Depending on whether it says yay or nay, you accept or reject the mail. If they're not running a verification service, you just failsafe. I know SMTP vrfy exists, but sites often turn it off, or it doesn't do anything useful as the external server is just forwarding mail, etc etc.
These systems wouldn't be so useful until they got adopted by hotmail.com, yahoo.com, eudoramail.com, aol.com etc, and I'm sure people have toyed with these ideas before and maybe there are downsides which outweight the benefits or maybe someone knows of implementations of such a thing.
Re:Optionally publish valid mail servers for domai (Score:2)
Re:Optionally publish valid mail servers for domai (Score:2)
Which, of course, drops some valid mail, like mine, which has a from: okstate.edu and IP of x8b....dhcp.okstate.edu.
Re:Optionally publish valid mail servers for domai (Score:2)
Re:Optionally publish valid mail servers for domai (Score:2)
Hi!
This would be a problem for notebook users. If you're running a POP3 server in a corporate environment, one of the problems you have to contend with is traveling users (sales people, etc.) who want access to mail, and want to be able to send mail at the same time. One solution (for Windows NT users) is to implement the SMTP server that's built into NT. Have the road warrior send from his local SMTP server, but retrieve his mail from the corporate POP3 server.
One could, I suppose, simply add all those road-warrior notebooks to the list of authorized MTAs. But in a large-ish corporation it might be a record-keeping nightmare.
Re:Optionally publish valid mail servers for domai (Score:2)
One could, I suppose, simply add all those road-warrior notebooks to the list of authorized MTAs. But in a large-ish corporation it might be a record-keeping nightmare.
Just use authentication for them. Surely, it wouldn't be any harder than keeping user accounts on the intranet servers up to date. It could even use the same authentication database.
Re:Optionally publish valid mail servers for domai (Score:2)
What accounts? What authentication database? Presently, the existence of a mailing address does not imply the existence of a user account. Consider forwarding-only addresses. Should all the volunteers behind bugs@opensourceproject.example.org require accounts? Maybe the sysadmin is a volunteer, too.
What about those of us who use webmail addresses as spam traps? Now we have to use crappy web interfaces to send (or those webmail companies have to set up SMTP AUTH, with which they very well may not want to bother).
...and so on, and so on...
Re:Optionally publish valid mail servers for domai (Score:2)
The context was corperate users on the road with laptops. That implies some sort of user account on the intranet.
In other cases, there is a simple Free software. Look into the cyrus with SASL. It integrates with sendmail, and provides IMAP services. The SASL feature allows it to have a seperate user database so that a login need not be provided.
What about those of us who use webmail addresses as spam traps? Now we have to use crappy web interfaces to send (or those webmail companies have to set up SMTP AUTH, with which they very well may not want to bother).
They can either set up SMTP AUTH (no problem), or they can stay as they are (O.K. for you) and risk becoming a spam relay. Once abused sufficiently, they will either get AUTH, shut down, or be blocked so widely that it's useless for you anyway.
Re:Optionally publish valid mail servers for domai (Score:2)
But the broader context is about changing the way that email works for everyone. There are lots of suggestions that might work for a small subset of users, but fail to satisfy the breadth of needs fulfilled by our current email system.
The SASL feature allows it to have a seperate user database so that a login need not be provided.
Shell accounts are not the point (by "login" I assume you mean shell, since any provision of a username and password is "logging in"). Forwarding addresses now are just entries in the aliases map, without any sort of account at all. (And, before you say it, no server need be an open relay). Now you're asking the sysadmin to maintain a set of SMTP accounts with usernames and passwords, and probably to write a password-changing mechanism (the sysadmin running "saslpasswd" is not acceptable). One might also need a mechanism for locking accounts after a certain number of failed login and presenting the last successful and last failed login attempt to the user. The point is, authentication can be complicated, and "just give them all accounts" can be quite a hefty proposition.
They can either set up SMTP AUTH (no problem), or they can stay as they are (O.K. for you) and risk becoming a spam relay.
OR, as things stand now, without the valid servers published for each domain, users can use their ISP's mail servers. There's nothing that indicates that the webmail companies need to be open relays or that they are now. My point is that they are unlikely to bother setting up SMTP AUTH or to become an open relay, so users who want to send mail as their webmail addresses will be forced to use the web interface.
The other problem with all of this is that every mail client would need to be re-written to make the outgoing SMTP server dependent on the From address. Talk about a user support nightmare...
The real question is: would this stop spam? Much of the spam I get comes from open relays and have faked From addreses (and refers me to a web site or telephone number). What's to stop someone from using as the From? (Remember that if example.com is running an open relay, they can't be relied upon to do anything responsible or not to do anything irresponsible.) The rest of it comes with a "From" on some fly-by-night domain that can set its DNS records however it likes. Some of it sets both the "From" and recipient addresses to my address (and it seems that could be blocked in other ways without a significant change in behavior).
There is some portion that uses a "From" of yahoo.com or hotmail.com, but given all the pain through which this proposal would put non-spamming users and that the spammers would quickly adapt, I'm not sure that it's worth it to block this particular avenue of spamming.
Re:Optionally publish valid mail servers for domai (Score:2)
I think I see the confusion now! I was talking about measures to restrict people from originating mail with a fake from address. You're talking about recieving mail.
The case of a simple mail forwarder is no problem. The final recieving MTA would be able to see that the From address and the originating server match and that the relaying server is a designated mail server in it's domain. Meanwhile, the relay server will presumably have performed similar checks.
None of this will necessarily kill spam, a willing ISP can set up whatever they want in their DNS just as you said. It WILL prevent abuses of innocent ISPs (as originators of spam). With that accomplished, spam servers can be blackholed with confidence and certainty without ISPs having to block outgoing connections to outside SMTP servers.
Problematic for many users (Score:3, Insightful)
Actually, this is a pretty big downside for many users. Every once in a while, someone proposes a similar scheme that makes it hard or impossible to "forge" From addresses. This is not exactly that, but it's close enough. The problem is that this is a perfectly legitimate and necessary use of email, and is, in fact, discussed in RFC 822.
The basic problem is that many of us wear quite a few different hats, each of which has one or more email addresses. Suppose I want to send an email using my personal address while I'm at work, or my work address while I'm at home. Suppose I need to reply to some email sent to an official address using that official address as the header From, and that I also want bounces to go to that address so that others at that address can see if my reply was not sufficient (requiring a change in the envelope From). Maybe I do run my own smtp server and domain, but I want to use my spam-trapping yahoo address to reply to yahoo mail (for privacy reasons), and I want to use mutt instead of some stupid web interface. Maybe I'm a sysadmin who wants to set up a number of forwarding addresses (perhaps official addresses for some project on some domain). Now my one-way service has to be a two-way service; instead of just editing the aliases file, I have to set up an account for each of the people who needs to send mail. These are just some of the things that I happen to do on a daily basis and that adoption of your system might make impossible or more of a pain.
Sure, a lot of times this can be solved by some sort of remote access or SMTP auth, but it would certainly be less convenient (especially because some sites are difficult to access remotely). The bigger problems are social: many of the users I know who do these sorts of things aren't the most technically-savvy; many domains are unlikely to introduce the features necessary for full remote access (so then it becomes less of an inconvenience and more of a loss of service).
The good thing about your proposal is that it's opt-in for the sender's domain (whereas most others are opt-in for the recipient's domain), and it therefore gives a domain more control over its email addresses (as opposed to less with other schemes). It allows example.com to say "we want mail from addresses in our domain sent out via only our servers." Presently, anti-relaying provisions in servers make it possible to say "we want only mail from addresses in our domain sent out via our servers." This just completes things.
I guess it depends on your perspective. As a sysadmin, I'd be happy to have the power to turn this on for my domain (though I probably wouldn't, and other domains might not use it -- look at how terrible people are with MX records). As a user, I'd be unhappy if one of my sysadmins turned it on, but happy if some of the domains spammers use and I don't use turned it on. I guess it might be sort of a "not in my backyard" issue, which might limit its adoption. Another problem might be sysadmins that block domains which don't have these records, thus taking the power away from the sender's domain again.
While I'm rambling
While I'm ramblingly replying:
When an email comes in, you check if there's a verification server for the source domain of the email, and if so try connect to it, and then submit the email address for verification. [...] I know SMTP vrfy exists, but sites often turn it off
They turn it off because it can be abused by spammers looking for valid addresses or is in some other way a privacy concern. What you propose is functionally equivalent to VRFY (except that it can run on a different server), so I doubt it would be turned on either. However, it might not be a bad thing for servers to *try* to VRFY an address, and only block if VRFY returns "no such user" (not "permission denied"). If a separate protocol and server is desirable, there is always good old finger (though it's maybe a little too free-form), but VRFY makes more sense, as the primary mail servers should know to whom they can deliver mail.
spam from asia, content from usa (Score:2, Informative)
20 percent...? (Score:2, Interesting)
So I guess since they know what 20% of Internet e-mail traffic is... they must be monitoring 100% of it... Hey AT&T, can you give us a pie chart that categorizes all e-mail sent throughout the Internet...? I'd like to see the data points; and even more interestingly, how you got them.
--- END PARANOID RANT ---
Re:20 percent...? (Score:2)
I know this is slashdot, but read the article. They use BrightMail. Brightmail is reporting 20% of e-mail filtered is spam, up from 10% last year.
AT&T, other ISPs should take advantage of this (Score:5, Informative)
I agree with the other posters who note that the economics of Spamming need to be reversed in order to stop it, but I think that, even before that, public opinion needs to be swayed such that it is perceived as a significant problem worth addressing all over the place, not just at one ISP or for one open relay. A lot of people have just gotten used to ignoring/deleting 5, 20, 100 spam messages per day. "It's just part of using the Internet, right?" This needs to change. When things like the AT&T congestion happen, they should be used to get the public a little more outraged.
AT&T mentioned this in the internal support gr (Score:2)
The old "factor a noumber to send" idea... (Score:2)
Also, include the following: Address verification *after* factoring. So people scanning will have to factor on every attempt (and people who made a typo will also factor once for no result, but they do it once, not a hundred times).
Naturally, you should be able to add a group of trusted addresses and domains that don't need to do this. Also, mailing-lists and similar should have the possibility to request this. This would not be a regular mail and so can't contain spam. It'll only contain the who and what, no body. "subscribe@somewhere.com requests authorization to send you 'Somewhere.com newsletter'". If authorization is granted, your server would get back to the originating server and tell it's ok. This would be the normal opt-in message you recieve today, only now put into a system.
As the factoring should occur upon delivery of the mail, it'd have to reside serverside, so I guess there would be some privacy issues about the server knowing who you trust, but I don't see that as a big problem.
Techincally, it shouldn't be any problem:
Server: 2x pseudoprime generation, multiply, send.
Client: Factoring algorithm, return.
Server: Verify through division or comparison with original.
The problem? As long as spammers can just fall back to the old protocol, it doesn't improve anything. But if it starts somewhere, others might catch on, and in the end people might just fish out non-spam messages out of their conventional mails, encouraging them too to use the new system, and in the end just block conventional email altogether. It's a long term solution, but the end result is a lot more promising than most other suggestions I hear.
Kjella
Re:The old "factor a noumber to send" idea... (Score:2)
Our four old single-CPU mail servers handle half a million legititmate messages per day with very little load (there are four for crazy levels of redundancy). Most of what they do is to just shuffle data around or do DNS lookups. Now you're asking them to do computationally-intesive tasks that take 5 seconds per message, so to handle the load averaged over a day, I'd now need 29 mail servers running at full CPU utilization all day [(500000 mails/day) * (5 CPU*secs/mail) / (86400 secs/day) =~ 29 CPU]. However, the load is not even over the course of the day; at peak times (mid-afternoon) the rate is easily more than five times the average. To handle peak loads of exactly five times the average, I'd need 145 servers working full-blast.
Even so, I still wouldn't have the comfortable margin I have now. For that, I'd need even more servers. Even if I could justify the outlay for the machines, I'd have to get a new machine room to house them and supply the power, UPS, and A/C. Then I'd have to set up all those machines, keep them patched, and so on. To say that would be highly unlikely for such a plan to be approved would be an understatement. Sure, spam sucks and costs legitimate people money, but is stopping it worth increasing by nearly two orders of magnitude the costs associated with running legitimate mail servers?
Granted, those esitmates are not accurate because not every mail would require CPU-intensive verification, but some of them would, possibly a good portion of them if your proposal were widely accepted. The worst part is I would entirely dependent on some remote sysadmin putting my servers on his list of "trusted" servers. Do you realize with how many other sites and unique email addresses we exchange mail? Don't sysadmins have enough to do without spending their time maintaining such a list? Even in the highly-unlikely best case, where the system operates perfectly, every mail we send out is magically a hit on the remote site's list, and entries are added to the list on our site automagically, you're still talking a *huge* and growing database, and that's going to cost something (computer time doing the lookups, sysadmin time maintaining the database). In the real world, however, it would porbably be worse.
Bottom line: this may work fine on your little pentium Linux box at home running a vanity domain, but it'll go over like a lead balloon with sysadmins in the big leagues and the people who control their purse-strings. You'll have to prove to them that the absolutely certain benefits outweigh the remotely possible costs, and that implementing such a system won't disrupt or slow mail delivery in any way. Good luck on that.
I'm not saying that I couldn't be convinced that such a scheme would be a good idea, but I remain extremely skeptical. The answer to this proposal seems to be that given to so many proposals: "DOES NOT SCALE". I really need to get a rubber stamp that says that. What makes this proposal actually irksome is that the lack of scalability is deliberate.
It needs to hit the client not the server... (Score:2)
Maybe the mail server should start acting like a proxy instead of a relay, how would that work? Instead of Sender -> Local mail server, Local mail server -> Remote mail server, it'd go directly Sender -> Local -> Remote. The cost would be lack of redundancy if the remote server doesn't respond, the local server won't take the responsibility of trying later. There's still a point of going through the local server though, of course to get verification that the email address really belongs to you. With a running connection the feedback link is established and the client can do the factoring, not the server. Likewise any webinterface (yahoo etc.) could offload it to the client through a java applet or similar.
Of course the message itself can be cached on the server as usual, so it won't matter what speed the connection is, as long as the factoring noumbers get transfered properly. Perhaps having the server do the factoring as a "back-up" solution in case of temporary connection failure would work. It'd work with a few remote sites being offline, on the other hand if the connection to the outside goes down and the mail server gets filled, there's trouble in paradise...
I haven't got any idea how much real mail servers do "behind the lines". How often can't it connect at all? How realistic is it really to replace the mail server with something that would be practicly an IM to the remote mail server) + caching proxy? Damned if I know, I just know my bandwidth is being stolen by people sending me advertisements I pay for. And I'm tired of it.
Kjella
Re:The old "factor a noumber to send" idea... (Score:2)
Consider these possibilities when a remote host tries to send us mail:
It is recognized as a 'good' host, so we accept its connection and mail unchallenged.
It is recognized as a 'bad' host, so we challenge it and tell it we don't accept mail from spammers.
The third option is more complicated: The connecting host is unknown. We ask who the mail is destined for, and attempt to do a lookup. If the user doesn't exist, we challenge the host, then after getting a response reply that the user 'either does not exist or is not accepting mail from you.' If the user does exist, we open ~user/.somemailrcfile and take actions based on that: The sender might be known good, in which case we accept the mail without challenge. It might be known bad, in which case we deny with the same 'does not exist' reply as above. Otherwise, we just challenge and accept the mail.
This gives system administrators the ability to form the mail networks they need, but it also puts the power of white and black lists in the hands of the users, where it is needed. If I, as a user, don't want to ever receive mail from *.tw, I should be able to tell the system mailer that. Filtering after the fact (with tools like procmail) means the mail still got delivered and consumed bandwidth.
In some ways, this also solves the opt-in/opt-out mailing list problem. If you have a mailing list and you send to a lot of people, you'll have to deny sending to any users/hosts that challenge you. If the user really wanted to be on your list, the user would have to add your list to his personal 'do not challenge' list.
This would also make it easy to unsubscribe - simply remove the list from your 'do not challenge' list, and you would be automatically dropped from the list.
I also don't see any insurmountable problems with forwarding. What do the rest of you think?
-dentin
On spam (Score:2)
This week I recieved my first ever unsolicited email from my own country - a real world business {thats choiceco@aol.com , choicewatford@aol.com and info@choiceofficefurniture.com for any spambots reading!! Fight fire with fire
As far as the spam from US people using open relays in asia, sure shut them out/down - unfortunately the spammers wont give up quite as easily as that, i'm sure they will find some other way to send their crap.
Korean Spam is the Worst (Score:3, Informative)
Kornet.net (the biggest offender)
abuse@kornet.net, ip@ns.kornet.net, ip@ns.kornet21.net, domain@NS.KORNET.NET, donghk@soback.kornet.net, ever@kt.co.kr, jeonnam3@soback.kornet.net, jeon@kornet.net, jeonbuk3@kornet.net, koreatelecom@KORNET.NET, gfd5246@soback.kornet.net, gspark@kornet.net, help@KORNET.NET, helpdesk@KORNET.NET, haewha1@soback.kornet.net, heyeunmi@kornet.net, kmhno1@soback.kornet.net, hopewon3@soback.kornet.net, kgromc@soback.kornet21.net, kmhno1@soback.kornet.net, legal@KORNET.NET, network@kornet.net, packet@soback.kornet.net, postmaster@kornet.net, postmaster@soback.kornet.net, postmaster@ns.kornet.net, postmaster@soback.kornet.net, pusanpub@soback.kornet.net, root@soback.kornet.net, root@kt.co.kr, service@kornet.net, support@kornet.net, system@kornet.net, yjjeon61@kornet.net, abuse@ns.kornet21.net, domain@ns.kornet21.net, network@ns.kornet21.net, postmaster@ns.kornet21.net, resume@kornet.net, root@ns.kornet21.net, service@ns.kornet21.net, support@ns.kornet21.net, system@ns.kornet21.net, wong@kornet.net, abuse@ASADAL.NET, postmaster@ASADAL.NET,
Itnsoft.com (the #1 spamvertised Korean domain)
abuse@itnsoft.com, help@itnsoft.com, ip@ns.kornet.net, hostmaster@nic.or.kr, marom@itnsoft.com, postmaster@itnsoft.com, root@itnsoft.com, eglee@yesnic.com, info@yesnic.com, hostmaster@yesnic.com, postmaster@yesnic.com, eglee@whois.co.kr, postmaster@whois.co.kr, whois@whois.co.kr, brkim@INWANG.NOWCOM.CO.KR, domain@NOWNURI.NET, busisik@nownuri.net, kbr@nownuri.net, memory@nownuri.net, abuse@nownuri.net, postmaster@nownuri.net,
DreamX.net (Korean porn spam, mostly)
abuse@dreamx.net, abuse@cjdream.net, abuse@todream.net, admin@dreamx.net, admin@cjdream.net, administration@dreamx.net, administration@cjdream.net, billing@DREAMX.NET, billing@cjdream.net, brkim@cjdream.com, dns@dreamx.net, dns@cjdream.net, dnsadmin@dreamx.net, dnsadmin@cjdream.net, domain@DREAMX.NET, domain@todream.net, domains@DREAMX.NET, domain@todream.net, feedback@DREAMX.NET, feedback@cjdream.net, help@DREAMX.NET, help@cjdream.net, helpdesk@DREAMX.NET, helpdesk@cjdream.net, hostmaster@dreamx.net, hostmaster@cjdream.net, inhanna@cjdream.net, info@dreamx.net, info@cjdream.net, jyan@dreamx.net, jyan@cjdream.net, ley319@dreamx.net, loveabuse@dreamx.net, loveabuse@cjdream.net, mail@dreamx.net, mail@cjdream.net, mgr@cjdream.com, news@dreamx.net, news@cjdream.net, newsabuse@dreamx.net, newsabuse@cjdream.net, postmaster@dreamx.net, postmaster@todream.net, raven3@dreamx.net, raven3@empal.com, root@dreamx.net, root@cjdream.net, soip@cjdream.com, sales@dreamx.net, sales@cjdream.net, sbkim091@dreamx.net, sbkim091@cjdream.net, service@DREAMX.NET, service@cjdream.net, solhan@cjdream.net, spam@DREAMX.NET, spam@cjdream.net, support@cjdream.net, support@dreamx.net, sysop@DREAMX.NET, sysop@cjdream.net, sysop@todream.net, tech@dreamx.net, tech@cjdream.net, technical@dreamx.net, technical@cjdream.net, technicalsupport@dreamx.net, technicalsupport@cjdream.net, system@cjdream.net, system@dreamx.net, sysop@todream.net, ykshin@cjdream.net, ykshin@dreamx.net, eglee@yesnic.com, info@yesnic.com, hostmaster@yesnic.com, eglee@whois.co.kr, brkim@INWANG.NOWCOM.CO.KR, domain@NOWNURI.NET, kbr@nownuri.net, memory@nownuri.net, busisik@nownuri.net, abuse@nownuri.net, postmaster@nownuri.net, inhanna@sysone.co.kr,
Thrunet.com
abuse@thrunet.com, abuse@korea.com, admin@thrunet.com, admin@korea.com, administration@thrunet.com, dns@thrunet.com, dns@korea.com, dnsadmin@thrunet.com, domain@thrunet.com, feedback@thrunet.com, feedback@korea.com, help@thrunet.com, helpdesk@thrunet.com, hostmaster@thrunet.com, mail@thrunet.com, mail@korea.com, news@thrunet.com, news@korea.com, newsabuse@thrunet.com, postmaster@thrunet.com, postmaster@korea.com, root@thrunet.com, service@thrunet.com, support@thrunet.com, sysop@thrunet.com, tech@thrunet.com, tech@korea.com, technical@thrunet.com, technical@korea.com, technicalsupport@thrunet.com, youngkim@thrunet.com, youngkim@korea.com, hostmaster@nic.or.kr,
hananet.net
abuse@hananet.net, bluelinux@hananet.net, domain@hananet.net, domains@hananet.net, feedback@hananet.net, help@hananet.net, helpdesk@hananet.net, info@hananet.net, hostmaster@hananet.net, lee@hananet.net, linux@hananet.net, news@hananet.net, postmaster@hananet.net, root@hananet.net, service@hananet.net, spam@hananet.net, support@hananet.net, system@hananet.net, sysop@hananet.net, tech@hananet.net, technical@hananet.net, webmaster@hananet.net, WooJooLee@hananet.net, WJLee@hananet.net, ysjeon7@hananet.net, bspark@kci.co.kr, bluelinux@YAHOO.CO.KR, abuse@YAHOO.CO.KR, postmaster@YAHOO.CO.KR,
KIDC.NET
abuse@KIDC.NET, billing@KIDC.NET, dnsadm@KIDC.NET, domain@KIDC.NET, guard@kidc.net, helpdesk@KIDC.NET, hostmaster@KIDC.NET, hostmast@KIDC.NET, hjryu@kidc.net, ishan96@kidc.net, postmaster@KIDC.NET, root@KIDC.NET, security@kidc.net, support@KIDC.NET, abuse@BORA.NET, anti1473@bora.net, b4012391@users.bora.net, badmail@bora.net, billing@BORA.NET, dnsadm@BORA.NET, domain@BORA.NET, help@BORA.NET, ipadm@bora.net, ipadm@nic.bora.net, hostmast@BORA.NET, lyt082@bora.net, news@BORA.NET, postmaster@BORA.NET, root@BORA.NET, security@BORA.NET, sysop@BORA.NET, ysjeon7@bora.net, sexxkorea@hanmail.net, abuse@hanmail.net, postmaster@hanmail.net, hostmaster@hanmail.net, abuse@chollian.net, muscle73@chollian.net, zcedomain@chollian.net, znotice5@chollian.net, abuse@kr.iasiaworks.com, postmaster@kr.iasiaworks.com, webmaster@kr.iasiaworks.com, 1004@domain1004.com, I@i1004.com,
No, Korean Spam is the *Best*! (Score:2)
Spam effects a good thing? (Score:2)
Maybe this is a good thing. First, it provides a graphic rebuttal to the people who say "Why worry about spam, just hit the Delete key and it's not a problem anymore.". A slowdown like this is a big problem, and hitting the Delete key won't solve it because the servers are still bogged down delivering it so you can delete it.
Second, if the majors like AT&T start getting affected like this, maybe they'll start taking it seriously as a "this is going to cost us customers" problem. The spamhauses have hidden behing the fact that it doesn't cost their providers much to keep them around and they do pay their bills. If this kind of realization sinks in, the majors may start looking for the ultimate source of the spam (not just the relay they used, but the person/company actually responsible for the spam) and punting them from their networks completely to avoid ticking off the other major players. If I call UUnet and complain about a paying customer they're not likely to listen. If AT&T calls UUnet, they've a slightly bigger club to wave.
It's not all from Asia... (Score:2)
Now, I'm a registered Libertarian, and have never given the DNC my email, or any indication that I want to hear from them...
Go figure.
20% of all emails... (Score:3, Interesting)
We have a common target on which we'd love to see some LEGISTLATION against it, for once.
And what is the Gov. doing? Passing laws left and right to protect big corporation, to reduce your rights as consumers, to be a complete pain in the ass and give themselves the right to sue the planet, but what is being done for the VOTERS, the USERS, the people paying the tax dollars?
Well this is one case of an EASY win of public opinion, heck, they could even pass a few bad things without people noticing it because we'd be so impressed that our elected people actually did something for the PEOPLE.
Ok this sounds like I am frustrated against the system but you get the idea... of course a global spam law and action will be taken one day... when all the big corporations will be really pissed. Or major ISP be fed up paying bandwidth for SPAM, Look now AT&T is starting the run, shouldn't take long now before we get something out of this.
I think blocking ASIA would be a good thing, a pain in the start, obviously, but for a good cause, when they'll see they can't conduct buisness properly, they'll move and close those open relays and hey, screw human rights on spammer, you can KILL the biggest of them and I don't see anyone here who'll be really upset, for once
Spam is doing 20% of the global traffic, the numbers are about right with what I see in my mailbox, as for my hotmail mailbox though, it's more like 95%.
Demonstrable Damage and A License to Drive (Score:2)
Proof of damages clearly removes the age-old argument "just delete it! don't be such a whiner!"
The "Asian" spam people are concerned with doesn't always precisely "originate" from asia in the truest sense, however, it does come from mail relays being prone to being open.
On today's roads, a driver's license is required in most countries and certainly in the U.S. The purpose is at least partially to demonstrate proof that they have met minimum required skills and knowledge to operate a vehicle lawfully and safely. I hate to say "Hey, we need even MORE legislation" because I generally stand for smaller government. However, I believe that since the IIS flaws which still exist today (along with unpatched and currently still infected operating Windows boxes) combined with other people running servers with open relays among many other problems, I'm beginning to think that having an operator's license (not unlike a radio operator's license) should be required for internet usage.
Not only could this better raise awareness of security, but also netiquette and some basic technical understanding about the net and how things operate.
So, to just run a "client" computer, no license or something very minimal should be required. To run a personal or private server (email, web, ftp, whatever...small or limited use) something of a "Class C" license should be required. ISPs and hosting companies should require a professional license and such.
I don't propose that these cost any money or require any given renewal concerns. Costs should be extremely minimal to the point that it doesn't matter and only serves to fund the project. I just think that while we can't have "joe user" installing a Windows Server or some default *NIX to utilize the internet should be held accountable for his lack of knowledge, skills or ability as it DOES affect the rest of us in some way or another. Negligence in other areas of life are punishable offenses.
As things stand now, the internet is treated as a concern that is separate from daily life, however, I hold that for some, the internet is as essential to public access as our roads are! I don't think this notion is far fetched and I don't think it will "shut out" too many people.
In addition to that, suspending a license could be a more appropriate punishment for certain hacking activities as opposed to life in prison and never again accessing a computer device.
Anyway... I'm sure this idea in its basic form has a great deal of merit and will serve the public good. The devil is in the details and we should be very careful with its implementation. (example: licensing/certifying Operating Systems as 'internet safe' and such might be an issue of great concern and commercial interest.)
They should use Vipul's Razor (Score:2)
Nevermind Open Relays Old Version of Formmail (Score:2, Informative)
Starting digging through the logs and find an autotmated tool is using an old version of formmail that one of our users had installed. Seems like a spider found that is was a formmail cgi and tested it and found it to be vulnerable. so It sent e-mail to an aol box. 4 hours later what appears to be a Windoze program using the Microsoft URL Control is Sending tons of messages through this formmail cgi. By passing any rules we have setup in the mail server to dynamic blackholing of people that send too many messages or messages with too many invalid to's in the header, cause it came from a trusted host.
Besides that fact that I was pissed, I was intrigued. That was pretty slick, once you start closing down one way for them to spam they keep coming up with more.
On a side note we have found that if you simply strictly follow the RFC's you cut back a lot of mail you accept, and also Doing a reverse dns lookup, just to make sure their ip resolves to something helps a lot. By turing on Reverse Dns lookups and not accepting mail from ip's that don't resolve. We drop about 68K messages a day.
Unidentified Internet marketer (Score:2, Insightful)
"According to Brightmail spokesperson Francois Lavaste, an unidentified Internet marketer overwhelmed Brightmail's filtering system with messages, slowing down all e-mail delivery."
Why not name and shame them?
If they used their own servers then you know who they are, and if they didnt (although the sheer volume means it is very unlikely they could have used an open-relay unnoticed) then trace them back and make an example of them.
They are clearly a professional operation so bad press is going to make them look really bad in front of their existing clients, and if you tried hard enough you could have great fun suing them for all they were worth...
Well, gee... (Score:2)
Could certificates eventually solve this? (Score:2)
I'd hate to label every piece of e-mail with a valid certificate (forcibly associating someone's words with their identity), though, but given the way things are moving, I can foresee this in the next 10-20 years.
Everybody will have a digital certificate, and every e-mail will be transparently and automatically signed with this certificate. People on the receiving end will know who's sending the message not by looking at the From: header but by examining the identity of the certificate, and users will be given the option to reject or accept messages that aren't signed (meaning the identity of the person can't be trusted). Since a high and growing percentage of this anonymous mail will be spam, eventually more and more people will start rejecting it, and spam will neatly kill itself off (at the same time killing off the ability for people to send e-mail anonymously).
It's a sad state of affairs, but it's going to be impossible in the near future to differentiate between e-mail sent from someone you don't know, and mass e-mail sent from a spammer.
Re:Could certificates eventually solve this? (Score:2)
I'm not going to try and solve the difficulties in making something like this happen today. Who knows, maybe by the time something like this happens we'll have private keys in physical cards or secured with biometric scanners. It doesn't seem out of the realm of possibility that these things will become more prevalent in the future and that it will make it easier for us to do just what I was describing.
Wouldn't it make sense.... (Score:2)
Yes, this would put some sort of list of who your friends are server-side. A bit of a privacy issue I'd guess (not that having all your e-mail readable might not put that to shame!).
It might also take a bit more work on behalf of the SMTP server, but I don't think this would be a crippling level of work.
Of course, the _other_ option is locating spammers and dropping 1000 lb. LGBs on their locations. That'd fix their wagons....
20% increase in email kills AT&T? (Score:2)
-- I saw it on the internet, it must be true.
AT&T? Who's next to complain - Spamford? (Score:2)
Cleaning up the AT&T house would get rid of more than 20% of of the spam *I* receive.
Re:how many slashdot posts until some idiot... (Score:2)
If ISP can't play nice, drop their address blocks. (Dropping all of China wouldn't be much loss right now.) The trick is to block all an ISPs blocks, not just the spammer's IP. Spam friendly ISPs routinely shift the IP address. When their legit customers start leaving they'll wise up.
It gives me the warms fuzzys when some spam friendly ISP posts to news.admin.net-abuse.email, and asks pretty-please to be taken of the blocklists. (Then someone points out that they got spam from them in the last couple of days, and to take a flying leap.
Re:Asia, huh? (Score:2)
Re: (Score:2)
Re: (Score:3, Insightful)
Re:Blocking port 25 (Score:5, Insightful)
Anyway, blocking outgoing port 25 is a stupid idea. Many of us work from home and have our own domains, and we legitimately want to have our outgoing mail show our own domains, not @attbi.com or @rr.com or whatever.
There are also some practical problems:
Re:Blocking port 25 (Score:2, Informative)
At least that's what my ISP does. I have to set up my sendmail to smarthost through my ISP's mail server, and it works fine.
Re:Blocking port 25 (Score:2)
Yes, you can claim to be whomever you choose, but mindspring/eartlink will be able to tell who actually sent the message by simply looking at their logs. There they will find the IP of the origination point and thus YOU. If you connect directly to some server on korea that doesn't log anything or add any header listing where the message came from, then there's no way to tell who's responsible.
Re:SMTP Charges, Email Authenication? (Score:2)
The point is that there needs to be economic value in doing this. Micropayments haven't taken off because it's not worth the effort to track down individuals for payments of a few cents.
To make this system work, you would need some way to identify and charge the original sender (ISP or self-hosting company or individual), and you would charge something like $0.25 per message. The ack might refund $0.20, to provide a small fee to cover operating the system.
Even if someone sent a 100 messages every day, that's only a few bucks in access fees. But the spammer who sends 100k messages in a single month would get hit hard.
Of course, there's also the problem of mailing lists, etc.
Re:Not a problem (Score:3, Informative)
FIRST! Filtering at the receiving end is not the answer... at least not the whole answer and doesn't address all the other problems. The filter does not prevent the use of bandwidth!! It merely prevents the packets from being processed beyond initial reception and inspection. So the badthwidth is still being eaten.
SECOND! As another reader/writer has commented, in order to own an internet domain, a valid email address MUST be supplied. This is completely unavoidable. And simply being 'vulnerable' is not an excuse or justification for someone else to unfairly exploit your resources!!!
I also use ATTBI but I don't use the email service they provide. I guess it means I don't get the updates, bulletins and other information but asside from having essential connectivity, I get my services from elsewhere. I'm very happy with that arrangement.
Re:Not a problem (Score:2)
How?
Well, my address WAS posted at a few places.
But they were all trusted locations.
Let me ask you some questions.
Have you ever used e-bay?
Any other online retailer?
How much do you trust this (these) online retailer(s)?
Have any of those retailers gone out of business since you gave them your e-mail address by any chance?
Does anybody else who DOES have your e-mail address have a habit of doing stupid ass shit? (such as, say, running outlook. . .
Does your browser know your real e-mail address? (IIRC, it is simple to grab a persons e-mail from their browser).
Have you used anon FTPs and actually submitted your REAL e-mail address to them? (doh!)
Do you read over ALL licencing terms that you agree to on sites that may even possibly have your e-mail address?
And their privacy policies?
And compared the two side by side to look for any loop holes that the company may be able to use?
Do you use separate e-mail addresses for different tasks? If so, how segregated do you keep these different addresses?
In other words, 'idiotic things' pretty much means ANYTHING that is not fully Tin Foil Hat Paranoia Compliant.
Re: (Score:2)
Re:The first thing to be done... (Score:2)