Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

IETF to Look at Spam

CmdrTaco posted more than 11 years ago | from the could-this-be-the-end-of-smtp dept.

Spam 211

m00nun1t writes "CNET has an article about the Internet Engineering Task Force (IETF) looking at what they can do about spam. According to the article, many of the proposals seems to "require changes in basic e-mail technology", which presumably means SMTP (and about time!). Maybe they are looking beyond just SMTP - anyone have any insights here?"

cancel ×


Sorry! There are no comments related to the filter you selected.

It wouldn't be adopted instantaneously. (5, Insightful)

Scoria (264473) | more than 11 years ago | (#5471135)

If an alternative to SMTP were developed, the protocol would not be likely to disappear immediately subsequent to the creation of its successor. The transition would be gradual, as reverse-compatibility could remain necessary for several years afterward. As suggested by the release of Apache 2.0, for instance, not every server administrator adopts a "technological improvement" until it becomes an adequately proven and stable product.

Re:It wouldn't be adopted instantaneously. (1)

frenchinengland (633384) | more than 11 years ago | (#5471173)

The transition to an alternative of SMTP can't be compared to the release of Apache 2.0. Apache 2.0 does the same job to previous versions except better, ie serves web pages via HTTP 1.0/1.1.

A new version of SMTP could require updating all E-Mail related software (client and server) and that's not a small chore.

Yes, I agree. (1)

Scoria (264473) | more than 11 years ago | (#5471195)

The adoption of another protocol is certainly a momentous proposition. However, considering the lethargic rate at which Apache 2.0 is being adopted, we can only hypothesize regarding a new email standard. Optimistically, I believe that it would require several years of dedicated effort on behalf of the Internet community.

AOL, Earthlink, MSN, etc. (1)

Scoria (264473) | more than 11 years ago | (#5471211)

Convincing "larger ISPs" to implement an alternative standard would also require prodigious effort.

Re:It wouldn't be adopted instantaneously. (1)

blibbleblobble (526872) | more than 11 years ago | (#5471257)

"If an alternative to SMTP were developed, the protocol would not be likely to disappear immediately"

The problem would be: do servers accept connections from legacy SMTP connections (which means spammers can just connect on SMTP and take advantage of the lack of identification), or do servers refuse to accept connections from legacy SMTP connections (which means that either everyone has to upgrade at once, or people using SMTP software have their connections dropped)

Re:It wouldn't be adopted instantaneously. (2, Insightful)

Mad Bad Rabbit (539142) | more than 11 years ago | (#5471395)

The problem would be: do servers accept connections from legacy SMTP connections (which means spammers can just connect on SMTP and take advantage of the lack of identification), or do servers refuse to accept connections from legacy SMTP connections (which means that either everyone has to upgrade at once, or people using SMTP software have their connections dropped)

Presumably AMTP servers (a name I'm making up, A for authenticated) would accept connections from legacy SMTP servers, but prefiltered with various ad-hoc spamblock techniques we use now (Bayesian filtering, limits on connection rates, etc.)

Re:It wouldn't be adopted instantaneously. (2, Insightful)

Skapare (16644) | more than 11 years ago | (#5471437)

Adopting a new protocol is very different than upgrading to a new version of an implementation of a protocol. In the case of a new protocol, there might be two different kinds of things going on at the same time, either with the same MTA, or different MTAs. In the case of Apache 2.0, you can't have the same web site available under the new version at the old version at the same time. With a new protocol, you can easily have a transition period because of the window of concurrency. With a new version of an implementation of the same protocol, deployed for a single instances of usage (e.g. a domain), it's basically one or the other. You can run Apache 2.0 on while Apache 1.3 still runs But you can't have running both very easily.

Re:It wouldn't be adopted instantaneously. (1)

Scoria (264473) | more than 11 years ago | (#5471550)

As indicated by this comment [] , I was merely attempting to indicate that the adoption rate of Apache 2.0 is lethargic. My statement was not intended to compare two processes. I concur; migrating to another protocol entirely would be arduous and intensive.

Re:It wouldn't be adopted instantaneously. (1)

metlin (258108) | more than 11 years ago | (#5471442)

On a related note, here's an interesting proposal written by [] cygnusx [] which I believe has been/will be submitted to the IETF.

For some odd reason, my name features there too :-)

wheres the first post trolls (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5471139)

mabye the trolls are in soviet russia,where everything is laggd 2 mins

(4th post???)

Re:wheres the first post trolls (0, Offtopic)

Scoria (264473) | more than 11 years ago | (#5471145)

Perhaps they are deleting "penis enlargement" spam.

IETF to look at spam? (3, Funny)

onthefenceman (640213) | more than 11 years ago | (#5471141)

Maybe their address got used as a reply-to in the latest "$1000 per week from home" letter...

IM2000? (2, Informative)

dialt0ne (114408) | more than 11 years ago | (#5471143)

Although I'd find it hard for the IETF to swallow djb's personality, there's always IM2000.

Re:IM2000? (0)

Anonymous Coward | more than 11 years ago | (#5471225)

Software engineers who are swayed by personality should be fired.

First Dupe! (3, Funny)

Anonymous Coward | more than 11 years ago | (#5471147)

First Dupe! []

Good effort but will ultimately fail (0)

FlynnMP3 (33498) | more than 11 years ago | (#5471149)

This is another attempt to have technology police human behavior. It hasn't worked in the past, why should it work now? I agree that SMTP could be made a lot more secure for the commercial Internet

Weak article (1)

virtual_mps (62997) | more than 11 years ago | (#5471150)

The article didn't say much beyond "gee whiz, there's a spam problem!" -- not exactly a revelation. It does hint at technical solutions to the spam problem, but I wonder if that's an approach that will ever work. I think at the heart this is a problem that can only be fixed with legislation (like it or not). Something along the lines of making it illegal to send spam with forged headers would help a lot.

Re:Weak article (1)

gmuslera (3436) | more than 11 years ago | (#5471200)

But did say that IETF is willing to get involved in developing (technical) measures, probably making/suggesting changes on the base protocols, and that is stronger than any particular trying to do the same.

You can sign up for the mailing list here: (3, Informative)

Saint Aardvark (159009) | more than 11 years ago | (#5471152) []

Among many, many others, I saw Vernon Schryver, the guy behind Distributed Checksum Clearinghouse [] , on the list. It's been pretty high volume, though, and I haven't had a chance to really spend some time reading it yet.

Re:You can sign up for the mailing list here: (1)

metlin (258108) | more than 11 years ago | (#5471461)

A piece of warning that I have adhered to from a few members of the list - it sees about 200 messages and odd a day, and I guess you join only if you really know what you're doing.

Another thing is that the list is supposed to be populated by discussions surrouding a lot of filtering techniques, which really aren't the way around spam.

I feel that if you propose to truly eliminate spam, a protocol level change is what would be needed.

My 0.02.

IETF? What does this have to do with toddlers? (-1)

I VOMIT ON TODDLERS! (642865) | more than 11 years ago | (#5471153)

Get your priorities straight! Time for some giggly, vomit-covered toddlers!

It's about time? (0)

Anonymous Coward | more than 11 years ago | (#5471159)

which presumably means SMTP (and about time!).

Maybe you should change TCP, UDP, and IP while you're at it? Maybe we could switch every 6 months or so just to make sure developers are "keeping up."

For the sarcasm impaired that means... nevermind, you're perfect.

Postfix sender verification (0)

Anonymous Coward | more than 11 years ago | (#5471162)

Take a look to Postfix Sender verification system. It can help little bit among other measures.

The really interesting thing about dupes (2, Offtopic)

astrashe (7452) | more than 11 years ago | (#5471164)

The really interesting thing about dupes is that they tend to suggest that there are large numbers of readers who pay more attention to the site than the guys running it.

If I was running slashdot, I'd probably push the people who had the power to approve stories to read each and every story that gets approved. It seems like a reasonable minimal committment to the community even for volunteers, and presumably some of these guys are drawing actual paychecks for the work they do here.

The dupes show that the guys approving the stories don't really care enough to take the time to do that.

Re:The really interesting thing about dupes (1)

6169 (318124) | more than 11 years ago | (#5471332)

I'm sure they *do* read each of their own postings, but it is extremely difficult to read every story/article posted on Slashdot, and even then the sheer volume would cause people to forget and post dupes anyway. Why not just code a simple hook in Slashcode that automatically searches for fairly recent articles containing the same URLs, or submitter name, or just scans for repeated words that don't show up all the time in normal language. It would run and show matches (if any) after *anyone* puts a story in the queue. I doubt it would miss many obvious dupes, of which we have many at present.

Re:The really interesting thing about dupes (1)

astrashe (7452) | more than 11 years ago | (#5471551)

I don't know -- how many stories get posted in a day? I don't think it would be that much harder than reading a newspaper. I doubt it's harder than what you have to do for your job, or for what most people have to do for their jobs.

I'm not suggesting that people ought to be blamed for not remembering a story from 3 months ago -- but 3 days ago seems reasonable.

I don't believe that an automated system to detect dupes would be simple or effective. There are often different articles about the same thing, and often dupes come through someone submitting a completely different article. I don't think that it's usually from the same submitter (although I haven't checked that), and repeated word scans seem to be something that would be very difficult to pull off.

Re:The really interesting thing about dupes (1)

6169 (318124) | more than 11 years ago | (#5471653)

Alright, I will grant you that reading every /. story (or at least the summaries and a brief look at the URL like everyone else does) is certainly possible for the editors.

The thing about an automated system is that there is still a human to check the output...the system could just find a few uncommon words in the story (example: 'IETF') and then just use the existing code search function to display the summary of the best (or most recent) hits. The editor just glances at them and should be able to tell in seconds if he's posting a dupe or not (humans are good like that). If it catches 50% that's still a good improvement with little effort, and there is plenty of room for improvement (bayesian filters?) Just a thought. That's what the comment system is here for, right

Move the onus from the recipient to the sender. (5, Informative)

wackybrit (321117) | more than 11 years ago | (#5471166)

Someone posted a response to another spam story a few weeks ago, sadly I can't find it, but they described an interesting mail delivery system they'd created.. and it sounded, to me, as if it could certainly be the future of mail delivery.

They said that when someone sent a mail, it simply went to the local server, and no further.

It sounded like a 'reverse IMAP' style system to me. That is, your outgoing mail simply went to a folder on your server, which allowed you to edit and even delete mails BEFORE they were picked up by the recipient. The recipient's e-mail server would only receive a 'notice' that someone had mail for them.

When the recipient went to collect their mail, their own mail server would then have a basic list of where the e-mails for the recipient are, and then it'd go ask for them from the remote servers and feed them through.

So, how does this help spam?

It allows spam to be truly filtered on the OUTGOING rather than the incoming!

Why's that a great thing? Well, it means that if you're an AOL or MSN user, you're not going to lose 80% of your mail simply because of over-zealous filtering by your ISP. Instead, spam mail will not even be sent, let alone received!

Of course, bad eggs could always set up servers with no filtering systems on them and send their spam that way.. but BECAUSE e-mail will be picked up FROM the senders server with this system, it means blacklisting is a whole lot easier! You just ban a server and you know you've got rid of the bad eggs.. whereas the current SMTP system allows open relays and all sorts of 'trickery' to get around filtering systems.

So.. the conclusion is.. make e-mail stay on the sender's server until it's time for it to be collected. It allows you to edit or delete mail before the recipient collects it, it stops spam, and it reduces bandwidth(!) -- if someone never collects their mail, then the mail has never gone across the net.. it's still on the sender's server.

I hope the original poster of this idea will pop up here again and correct me if I got his ideas wrong, but he was certainly on to something.

Re:Move the onus from the recipient to the sender. (5, Informative)

andyveitch (622036) | more than 11 years ago | (#5471197)

This is Dan "Qmail" Bernstein's Internet Mail 2000 [] .

Re:Move the onus from the recipient to the sender. (3, Insightful)

ccady (569355) | more than 11 years ago | (#5471244)

This system has some flaws:

1) If a person sees an e-mail in their inbox, then they can read it, and they are happy. Can you imagine the hordes of people who would now see that they got an e-mail, but could not get it for one reason or another? This makes e-mail *seem* fragile. Please explain to my step-father why he can see that he has e-mail, but he cannot read it on the plane. This is not a technical issue, but a psychological one, which is much harder to program around :-)

2) By what criteria could you filter the email? If you have not received the e-mail, you probably won't have enough information to tell if it is spam or not. The only information that you could go on is what is in the "notice" message.

Nice try.

Re:Move the onus from the recipient to the sender. (1)

LostCluster (625375) | more than 11 years ago | (#5471417)

1) If a person sees an e-mail in their inbox, then they can read it, and they are happy. Can you imagine the hordes of people who would now see that they got an e-mail, but could not get it for one reason or another? This makes e-mail *seem* fragile. Please explain to my step-father why he can see that he has e-mail, but he cannot read it on the plane. This is not a technical issue, but a psychological one, which is much harder to program around :-)

Just like his e-mail sits on a POP3 server until he downloads it at which point its possible to store it locally if desired. Once the transaction completes, it can still be on his local HD.

2) By what criteria could you filter the email? If you have not received the e-mail, you probably won't have enough information to tell if it is spam or not. The only information that you could go on is what is in the "notice" message.
The server on which the the e-mail is stored according to the notice is info enough. If you trust that server, you'll accept that they have already done the spam filtering and canceling for you. If you do not trust that server, you simply ignore all notices from that server. Servers that are ignored by large chunks of the population suddenly become an undesirable place to send from.

Not enough (0)

Anonymous Coward | more than 11 years ago | (#5471504)

> The server on which the the e-mail is stored
> according to the notice is info enough.

Is it?

> If you trust that server, you'll accept that
> they have already done the spam filtering and
> canceling for you. If you do not trust that
> server, you simply ignore all notices from that
> server.

Some of my friends use and Filtering based on servers isn't enough. I'm on some mailing lists and I often recieve legitimate email from unknown servers.

This solution doesn't stop spam. We can already do the "I don't accept emails from this server" today without a special protocol. We can already "accept email from only a few people on your list". Several ISPs allow you to set your own spam blocking on the ISP server so you don't see spam.

But this doesn't help (1, Insightful)

Anonymous Coward | more than 11 years ago | (#5471248)

Yes, leaving the email on the sending server essentially makes the sender pay for outgoing emails, but how does it solve the spam problem?

If I recieve an email from, how do I know that it's not from one of my friends who are using the Bar cybercafe or from someone on a mailing list I'm on? Most spam filters rely on actually reading the contents of the email. It would be nice if I could tell the server, "please filter out this spam using this filter" but it ain't going to happen and if it does there's no way I'm going to trust them to do it.

So basically, the only way to be sure it's not spam, is if I filter it in my own system.

RSS (1)

brunnock (18853) | more than 11 years ago | (#5471276)

We've kind of taken that approach with our own MLM [] by storing the outgoing messages on our own server and delivering notifications via RSS [] . Subscribers can read the actual message by visiting our web server.

Re:RSS (4, Insightful)

Angry White Guy (521337) | more than 11 years ago | (#5471345)

The only problem with this is scalability. Sure SMTP has had its problems, but the nice thing about SMTP is you control the server. You control how fast mail comes in, from who it comes in, how fast people can give you e-mail, and how fast you give it out to subscribers/recipients. All of these schemes seem to remove that control from your machine.

Instead of adding a band-aid solution to spam, let's sit down and list what we need for an a-mail server. Scalability, reliability, fault tolerance, expandability and distributed servers top my list. I'm sure that there are other better ones out there too. If you're going to revamp the protocol, try to get everything in the first time, and let's try to get it right.

Re:Move the onus from the recipient to the sender. (1)

kirkjobsluder (520465) | more than 11 years ago | (#5471349)

I see some flaws with this from the user end. Would mail clients have to negotiate a connection for every mail message? One of the things I like about email is that if a message appears in my mailbox, it is there ready to download (via IMAP). One of the things I dislike about pull technologies such as HTTP is that I never know when I request a page if the page will be available.

In addition from a user end it can make things more confusing because of the need to negotiate different policies for how long messages are retained. What happens when I need to grab that 6 month old bit of administrivia that I didn't bother to read then but became less trivial in the last hour? Having the sender control the duration and content of email can be a problem for things like email invoices.

Re:Move the onus from the recipient to the sender. (2, Insightful)

LostCluster (625375) | more than 11 years ago | (#5471480)

This would likely be made invisible to the user.

When the checking-mail process begins, the client would go to the receive-side server to get the list of notifications received. It would first apply any local filter rules to strike out unacceptable notifications, then go one-by-one to the servers to confirm that they sent the message the notification claims, that the server is still offering the message, and than ask for the message itself.

If the message has been declared spam by the server operator, then the server will intentially pull the message from availablity and essentially vaporize it before it hits a majority of inboxes. Server owners have an incentive to do this... because it'd be extremely easy to add server owners who don't into a local blacklist.

Yeah, a verbose log file can be made available for the geeks that wanna know what happened under the hood, but the average end user wouldn't see the message pop into their Inbox until the message has been sucessfully cleared and transmitted. Once its in the Inbox, it's a local object that the user can do what they want to.

Re:Move the onus from the recipient to the sender. (4, Insightful)

JamesSharman (91225) | more than 11 years ago | (#5471452)

This sounds perfect, And here is how it can be implement with backwards compatibility

It's implementation could also be made rather interesting. Rather than a completely new protocol that is totally impractical (since it would require everyone upgrading simultaneously) this kind of scheme could be implemented in a completely backwardly compatible manner. Allow me to describe what I mean.

Your email server has been upgraded to the new system and you send an email. Your outgoing server store the email and forwards a very simple email message onto the recipients email server, this small email contains the appropriate subject line and an extra chunk (with appropriate mime type) containing the information necessary to retrieve the full email message (ie: Server details, email id and probably an authentication token of some sort). Your client software supports the new standard it receives the stub email and retrieves the full message appropriately. This stub email is not an extra compatibility thing; we are simply using the existing smtp infrastructure to tell the recipient that they have a piece of email.

But what if the recipient has not yet upgraded, here comes the clever bit. Html email works as an extra mime chunk that enabled clients automatically decode and show the reader, non enabled clients see the standard plain text version of the message that is also present in the message, this mechanic can be used to our advantage here, the normal text or html portion of the stub email contains a hyper link back to the sending server which a url designed to bring up a basic web mail page with the recipients message.

Using this implementation scheme it would be possible for the sender who upgraded from day one to send an email to anyone with the complete confidence that they would be able to read the full text of the message. The only proviso here is that the recipient had access to a web browser.

In addition I can see one other advantage to your proposed scheme that has not been mentioned, the email system becomes inherently more secure. Since the sending server must actively hand over the email it can record that this has been done and tell the recipient if the message had been read before. Although as with anything else strong cryptography would be required to ensure to ensure that nobody could get hold the authentication token (and thereby read the email) it would be possible for the sending server (providing you trust it) to tell you authoritatively that nobody else had retrieved the message contents.

How about a global crackdown (1, Interesting)

Anonymous Coward | more than 11 years ago | (#5471174)

All the (legitmate ISP's in the world should come together and make a global blacklist of (rouge) isps. Along with distributed baylasien filtering, and reject emails with forged headers a different reply-to attribute (to stop joe jobs), should stop all most the most commited of spammers.

Linux users tend to get less spam because there are less security holes to "extract" your e-mail address, a lot of spammers deliberatley take advantage of microsofts flawed software selling "evidence erasers", "spam blockers" (ironicly), "pop up lockers", and "computer cleaners", of course these software packages are visual baisc applications which open up smtp relays on your computer.

Super Duper (0, Redundant)

Anonymous Coward | more than 11 years ago | (#5471175)

Yet another dupe [] . Sigh. There have been way too many duplicate articles lately. Are /. editors not reading their own site?

Re:Super Duper (0, Redundant)

supergiovane (606385) | more than 11 years ago | (#5471242)

Yet another dupe [] . Sigh. There have been way too many duplicate articles lately. Are /. editors not reading their own site?

break down the spamming practices (0)

handybundler (232934) | more than 11 years ago | (#5471176)

Make the changes to what is wrong with the sytem that allows for things like Email parsing to occur, or random address creation, etc etc..

Possibly, make those practices illegal, or more enforcable if they already are illegal.

I'm still one for the 'beat-spammers-severly-about-the-head-and-face-are a' option myself, but that doesn't fly in todays non eye-for-an-eye society.

Sad news ... Stephen King dead at 55 (-1)

Anonymous Coward | more than 11 years ago | (#5471178)

I just heard some sad news on talk radio - Horror/Sci Fi writer Stephen King was found dead in his Maine home this morning. There weren't any more details. I'm sure everyone in the Slashdot community will miss him - even if you didn't enjoy his work, there's no denying his contributions to popular culture. Truly an American icon.

Sender Pays! (4, Informative)

LostCluster (625375) | more than 11 years ago | (#5471179)

The fundemental diference that protects most communication systems from Spam-like abuse is that the sender is responsible for a majority of the costs of the message. Yeah, there are telemarketers and junk postal mail, but the are seriously limited by the fact that there is a noticiable cost assosciated with each additional message they send. The fact that it costs money to send such communications makes it impractical to bother people with offers with an extremely low reponse rate.

SMTP/POP3 e-mail presently leaves the cost of holding the message during the wait for the intended reader to be available on the receive-side server. The spammer doesn't even have to maintain a constant and consistant Internet connection.

Under the current system, a sender can send 100 MB of messages in an hour without penalty. However, a receiver who gets 100 MB of messages in an hour usually will find any other messages sent to them bouncing.

Requiring the message be held on a sender-side server instead would transfer the costs of sending a large volume of e-mail onto the sender, and therefore discurages the practice better than any law ever could.

Re:Sender Pays! (1)

addaon (41825) | more than 11 years ago | (#5471460)

I don't get it. Presumably, a spammer is sending out a million copies of the same e-mail. So he sends out a million 'hey, pick up your mail' notices to these new mail servers... and when the people go to check their mail, their servers go and talk to the spammers, which stored it remotely. Now, why does the spammer's server need to store more than one copy of the e-mail? Where is the increase in cost?

Re:Sender Pays! (2, Informative)

soundofthemoon (623369) | more than 11 years ago | (#5471615)

It's not just the storage space for the message. It's also the bandwidth costs. That's the nice thing about this approach. It doesn't bother ordinary users, but is death for spammers. Instead of making a send raid on a few SMTP servers, they have to keep their servers running while a million readers all come calling. It's like they have set up a DDoS attack on themselves. It would be fine for non-spam businesses like to do that, as they maintain some whompin big servers. But it would kill the small spammer, as the capital outlay for spamming would go up a lot.

Re:Sender Pays! (1)

LostCluster (625375) | more than 11 years ago | (#5471658)

Because the spammer server would have to transmit the million payload messages over a course of a few days rather than a hit-and-run instant. The spammer now has the responsilbity of keeping his server online, and can't exactly rely on an somebody who carelessly left open relay anymore.

Moreover, it's likely that in the first few seconds 1000 or so of the million will see that e-mail, identify it as spam, and a few dozen of that 1000 will put that server on multiple blacklists. To the 900,000 remaining people who subscribe to any one of those blacklists, their software drops the notification into the bit bucket, and the payload never makes it.

So now, an attempt to reach 1,000,000 people only connects with 11% of that... and 90% will not even bother with anything more from that sender (be it the username/domain combo or the whole domain depending on the blacklist listing) again until the blacklist operators say otherwise.

Re:Sender Pays! (2, Informative)

Ben Hutchings (4651) | more than 11 years ago | (#5471682)

Currently the spammer is likely to be sending a few thousand copies of the email to someone else's mail server, each specified as being for a few hundred recipients. The mail server expands this to a million copies.

Man jailed for goat sex attack (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5471182)

A man has been jailed for six months after a trainload of commuters saw him having sex with a goat.

Rob Malda, 23, of Kensington Road, Hull, pleaded guilty to one charge of buggery with an animal after the assault on the female goat in August last year.

Sentencing HIV-positive Hall, Judge Michael Mettyear, at Hull Crown Court, described the incident as "bizarre and disgusting". Hall had a previous conviction for indecent assault against a six-year-old girl.

The judge expressed frustration at being unable to order that Hall be banned from working with children in the future, adding: "You have pleaded guilty to buggery with an animal, a goat. It was committed in open air with people about, with people who could see.

"You were acting in an indecent manner, indeed, there was an seven-year-old boy in a position to see, although he was protected by his grandfather."

The court was earlier told how Hall had been returning from his sister's home on August 14 when the assault took place at the Argyle Street allotments.

A seven-year-old boy out walking with his grandfather had witnessed the attack together with a train-load of commuters on board a Hull to Bridlington service that had stopped at nearby signals.

Hall was seen holding on to a belt that had been put around the nanny goat's neck with one hand, while masturbating with the other. He was then seen with his trousers around his ankles having "penetrative sexual intercourse" with the animal.

Forensic tests matched semen taken from Hall's clothing to that found at the scene and samples of the goat's hairs were also found in his underwear.

Reading from the pre-sentence report, Mr Mettyear said Hall had shown evidence of being "preoccupied with sex", having "emotional instability" and problems maintaining relationships. It added that he targets "vulnerable" victims - "a child in the first instance and now an animal".

Slashwife (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5471186)

News for niggers. Stuff for darkies.









Re:Slashwife (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5471252)


This is fun :).




.the quick brown fox jumped over the lazy lameness filter dog

hooray (2, Interesting)

collapser (610412) | more than 11 years ago | (#5471188)

at last I will know to where in Nigeria I should go!

seriously tho. even if it is all legal-ified and I'D correctly, there will still be such things as ticking the little box to say you dont want any spam from service X,Y, and Z.
In fact, the way online revenues are going i can see recieving /solicited/ spam as being the only way you will be able to read salon. if it's still going by then.

it would be nice(?) to have a better system but I never forget the age old adage of no system being tamperproof. Lots of enterprising folks enjoy anonymity for non-spam purposes, so naturally some form of workaround should emerge fairly quickly.
oh lord i'm sounding like Toffler.

Cookies (1, Interesting)

Anonymous Coward | more than 11 years ago | (#5471191)

Why don't we have a system deliver a kind of cookie for a permanent or reply only privileged contact? That would help a lot by ensuring no known important mail would get filtered.

Internet Mail 2000 (3, Informative)

oohp (657224) | more than 11 years ago | (#5471194)

Dan Bernstein [] has a project called Internet Mail 2000 [] , ment to design a new Internet mail infrastructure which makes mail storage the sender's responsibility.

What's the point (1)

Nintendork (411169) | more than 11 years ago | (#5471196)

After all, we know how law-abiding spammers are. And how effective the government is in combating computer criminals. I really don't think this will make a difference.

That statement is original and in no way related to a comment on another totally unrelated article. *grin*


Re:What's the point (2, Insightful)

LostCluster (625375) | more than 11 years ago | (#5471228)

Laws might not be able to stop spammers, but protocols have a better shot.

Simply put, it's too easy to create spam over the SMTP protocol. The from, and reply to fields are completely free text, and have no requirement that they must be a reflection of the actual sender of the message.

However, if SMTP were to fall out of favor for a new protocol, that new protocol could start the rules over and require that the server that is named in the from field must confirm that the username provided actually sent the message. Spoofing for the use of spam would then become practically impossible.

Once we have a confirmed from address, it puts a responsiblity to stand behind each e-mail sent through a server. Moreover, once spam use has been detected a really reputable server operator could simply stop authenticating that sender's e-mail.. causing auto deletion before its presented to a user.

If you can't make it illegal, try to make it impossible...

Re:What's the point (1)

1nv4d3r (642775) | more than 11 years ago | (#5471493) protocol could start the rules over and require that the server that is named in the from field must confirm that the username provided actually sent the message. Spoofing for the use of spam would then become practically impossible.

To me, trying to stop spam is like trying to keep people from copying digital media. There is always a way around it.

When you think about it, the two concepts "I'll let anyone try to send me mail" and "I'll only actually get the mail I want to get" are not very compatible at all.

I think most of slashdot understands this. The only reason there aren't a bunch of "wonder how long before Spam gets through whatever they come up with" mails is that we hate Spam, and want to believe it can be stopped.

TMSP (2, Funny)

dolo666 (195584) | more than 11 years ago | (#5471210)

How one Microsoft employee gets promoted to VP of E-services Technology:
"I propose we go with TMSP protocols instead of SMTP, because it will allow us to move goal posts, get on the same page, keep ahead of the game, reach out and manage expectations. Also, e-services facilitate gap analysis that is goal directed to overcome security contingencies in a consumer driven brand-limited distrobution channel. TMSP is also client-centric."

Authenticated SMTP (5, Interesting)

Anonymous Coward | more than 11 years ago | (#5471213)

The technology exists, off the shelf, today.

There is a SMTP command called STARTTLS which will enable SMTP over SSL. It's defined in RFC 2487. Sendmail supports it with a compile-time option, and so do most other MTAs. It's backwards compatible with normal SMTP.

You will need a certificate, of course.

This has 2 big effects:

- encryption of email in transit between SMTP servers (a nice bonus)
- authentication of SMTP servers

Since sending spam isn't illegal in most jurisdictions, knowing WHO sent the spam (or relayed it) allows you to contact them and complain, threaten and retaliate (mailbomb, portscans, DDOS, etc.)

If you receive email from a host authenticated by versign (or whoever), you apply little filtering.

If you receive email from a host not using ssl, it goes into a queue for maximum filtering.

Much of the spam I receive today is from DSL customers who spew directly.

- there will be additional CPU load for all the email servers
- cost of certificates

Re:Authenticated SMTP (1)

MrLint (519792) | more than 11 years ago | (#5471450)

Only problem here is that if you require a certificate you have to subsidize the broken monopoly that is verisign.

Re:Authenticated SMTP (1)

Skapare (16644) | more than 11 years ago | (#5471537)

I get almost no spam from DSL customers. That's because I block the DSL connections. And to be sure I don't get stuck having to keep a list of DSL IP addresses updated all the time as those pools are changed, I do the blocking based on the domain name. What this does is allows the ISP some actual control. For example, they can separate their centralized email servers (that legitimate mail is supposed to relay through) from their direct DSL lines, based on domain name (most ISPs are smart enough to put the DSL lines in subdomains, just like they did for dialups). Dedicated connections that just happen to be using DSL technology can simply have reverse DNS set up to identify the mail server hostname within the customer domain name. If a customer sends spam, then I can block that customer by their domain name (instead of by an IP address which might end up being used by someone else later, without my knowledge).

Still, using a certified method of sending mail can help, whether it is by STARTTLS in SMTP (certifies the sending mail server), or a certificate in the message itself (provided I allow the SMTP session to get as far as the "DATA" command, which might not happen on those untrusted servers like the generic DSL ports).

Missed opportunity (4, Funny)

gmuslera (3436) | more than 11 years ago | (#5471214)

If any mail infrastructure reorganization were done before the finding this mount of this sendmail hole [] , that would have been be a good way to have a mostly forced deploy of compliant mail servers around the world.

Taskforce yes, but more like SWAT! (0)

dark-br (473115) | more than 11 years ago | (#5471222)

Creating laws, regulations, and whatnot will come nowhere near solving the problems. Sure, if a spammer lives in the US then maybe this would work; but what about all these scams from Europe, Australia, Britain, etc. Just because laws exist in one jurisdication, it doesn't mean that others will play ball. And even having laws does nothing if they're not enforced. Why not have a group of IT police hunt down spammers? After all, they're already guilty of theft and fraud (think bandwidth people). Why not prosecute under existing laws and treat spammers like the theives they are. Even though you won't catch spammers outside your legal jurisdicition, you'll help. And every country that helps would quickly be eliminating the spam problem we live with.

Re:Taskforce yes, but more like SWAT! (1)

Highwayman (68808) | more than 11 years ago | (#5471562)

Unfortunately the Department of Justice's cybercrime outfit is busy busting [] the real criminals and putting a stop to warez and bong sites. Once they get done with those, I'm sure they will move on to those sites callously putting Britney Spears' virginal head on pr0n star bodies and other such travesties of justice. I'd be happy if they would just update their website [] which I suspect may have been put together as a junior high school computer class project.

Changing SMTP (5, Insightful)

arvindn (542080) | more than 11 years ago | (#5471229)

It think it is possible to move to a different protocol than SMTP by building a protocol over it, rather than throwing it out.

The article notes that one of the major problems is the filtering of genuine mail due to agressive spam filters necessitated by cleverer spammers. Consider this analogous to dropping some packets at the network layer. Just as the transport layer handles this problem, we can build a higher level protocol to handle filtered mail.

Note that having a mechanism to handle dropped mail allows us to employ agressive filtering: one that is sure to stop 100% of spam.

What I have in mind is as follows: when Bob receives a mail from Alice (i.e, it has passed through Bob's filter) the client software sends a confirmation mail back to the Alice. This is not a regular mail that the Alice will see in her inbox; it has a special header flag that marks it as a confirmation. Alice's client software keeps track of the confirmation messages; by looking at her "sent-mail" folder she can see which of her messages have not been confirmed (and are hence likely to have been mistaken for spam).

Finding that Bob has filtered her mail, Alice can either re-word it and send it again or do something like (assuming that Bob knows Alice): "Hi Bob, this is me, Alice. Your filter blocked this so I've rot13'd it to get past the filter. rot13 what follows to read my mail." Another option is to encrypt the mail with Bob's public key (assuming that spammers' scripts won't be clever enough to get your public key from your web page). Note that 99% of the time the mail is going to get through. You have to make that little effort to prove you are a human only once in a long while.

There is minor problem with requiring the receiver to send a confirmation message: Bob might check his mail only after a couple of days, during which time Alice may assume that her mail was blocked. There are 2 solutions: either Bob runs a script to filter his mail regularly, or else has his ISP implement his filter for him.

Note that this won't work if you have the receiver send a reply whenever the message did get blocked: the reply could itself get blocked etc. (This is called the red army - blue army problem in networking).

Re:Spammers too smart for this. (3, Insightful)

1nv4d3r (642775) | more than 11 years ago | (#5471272)

Hi, arvindn, it's me, 1nv4d3r. Your spam filter blocked my mail, so rot-13 this to see what I sent you.


(not to mention that return token let's them know that you at least look at your mail.)

Re:Spammers too smart for this. (1, Interesting)

Anonymous Coward | more than 11 years ago | (#5471329)

But you would have a valid email address of the
spammer. Which means it is much easier to shut
him down or sue him or whatever you think is

But there already exists something similar to
the idea the problem is that it isnt any
mail client that has somehting built-in.

I would like something like this:

1. You receive email. Mail client check if
this somebody you have in your addressbook
, you sent an email to him before or you accepted
an email from him before. If so pass it through
and happy ending. Other wise go to 2.

2. Mail client returns mail with some specific
format and ask for confirmation mail. It the
other client supports it can autogenerate a
confirmation. Client would only autogenerate
response if it knew it sent email for the
requested confirmation.

3. If you receive confirmation pass the mail

I am sure this would reduce spam substantially
since they would have to have a valid email address. And all this without filtering.

Re:Spammers too smart for this. (1)

1nv4d3r (642775) | more than 11 years ago | (#5471431)

2. Mail client returns mail with some specific
format and ask for confirmation mail. It the
other client supports it can autogenerate a
confirmation. Client would only autogenerate
response if it knew it sent email for the
requested confirmation.

As an added benefit, it would also send a huge amount of extra traffic to spoofed return email addresses. A new DOS attack is born every day!

This sounds better than the first post, where Alice tries to send mail again manually. In this setup, it sounds like Alice's mail gets through after the confirmation step.

Couldn't this be built in to the internet mail servers? They could always do this step, and stop forwarding mail that the return addresses don't think they sent?

Re:Changing SMTP (1)

dnoyeb (547705) | more than 11 years ago | (#5471667)

A very simple partial (90%) solution is to reject email that has a forget header.

Then you know _exactly_ where your spam came from.

Keep it simple... (4, Insightful)

ccady (569355) | more than 11 years ago | (#5471230)

World of Ends [] , recently [] discussed [] on Slashdot, discusses why the simplicity (or stupidity) of the Internet is so useful. "The Internet isn't a thing. It's an agreement," they say.

That same argument applies to e-mail. Following their logic, it is best to leave SMTP alone. Simpler protocols are better. Leave the "value-added" pieces to the edge, and let the simple message transfer protocol alone.

Authentication... (2, Insightful)

Dukebytes (525932) | more than 11 years ago | (#5471235)

I hope that it involves authentication of some sort or another. IANAP - but they only way I can see to get rid of spam is to tell the SMTP server that you will allow mail to be delivered to you. If someone sends you an email - and you "unsubscribe" - they have to remove you from the list - the SMTP just hops it. If the SMTP servers themselves maintained a list of "unsubscribed" or blocked addresses - they couldn't send you an email.

I know - I don't write code - and this probably sounds stupid. But I don't really see any way of forcing someone to quit sending you email. SMTP is short and sweet - but it can't continue to just hop mail. It has to be checked somehow. And it would slow down the mass emailers a lot. Hopefully someone a lot smarter than I in this area can come up with something.


Power grab by TBTB (3, Insightful)

acceleriter (231439) | more than 11 years ago | (#5471247)

Watch for any attempt to impose digital certificates or other revenue generating schemes--wouldn't Verisign love it if now not only those who wanted SSL to work without presenting dire warnings to customers but everyone who wanted to be able to send email at all had to pay Verisign's extortion money for a certificate recognized by MSIE.

Perl to the rescue: poetic justice (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5471251)

Almost all spam goes through open relays. To stop spam, stop the open relays.

If all users ran a small script that mailed the last 100 spams they received to the last server they got spam from through the next to last server they got spam from with a return address of the next to next to last server they got spam from then we have real fun.

1. Open relay #1, gets your messages: "Here is some mail for you to relay". Please send these 100 messages to this other open relay #2. Open relay stores and attempts to delivery 100 messages, eatting up its resources.

2. Open relay #2. gets is contacted by open relay #1 100 times. Consuming some resources. It says "I don't have this mailbox." You should tell the sender. So, open relay #1, consumes more resources, making the 100 messages into 100 bounce messages.

3. Open relay #1, now tries to deliver the 100 bounce messages to "the sender", open relay #3.

3. Open relay #3 gets contacted by open relay #1. And consumes some resources responding to 100 "No such user here." Open relay #1 drops the messages.

The point is, spamees, can perform a distributed DOS that shuts down the open relays, by having them talk to each other. After all, the open relays have told the spamees: "Hey, I will try to send mail to anyone: as proof here is some spam for you." The spamee is saying: "Thanks! Here are 100 messages for you to deliver to another open relay that sent me spam."

The only one who really is really penalized are the ISPs who carry the traffic. However, the ISPs who allow open relays on customer networks deserve the traffic and more. Any upstream ISP should not sell service to ISPs who allow open relays...

Hell, send 1000 messages instead of 100 to the open relay. Also, have the servers to contact send bounce messages selected at random. This forces open relay #1 to open 2000 connections.

BTW, the messages looks like this: "Dear postmaster, please do not spam me. You are receiving this messages because you opted into my sent-me-spam mailling list, by sending me spam. Attached is a spam from another list member."


Backward compatibility (4, Insightful)

dpbsmith (263124) | more than 11 years ago | (#5471259)

email is by far the most widely used of all Internet services. I belong to an organization many of whose members are retirees are on fixed incomes, and it is only within the last two years that the number of people with email has grown to a critical mass (about 2/3 of the membership).

Of members of the lay public who regularly use email as a means of communication do not have the level of technical comfort that most Slashdot readers take for granted.

Of people who use email, the percentage who know how to use a web browser is much less than 100%. The percentage who can google for information is much less than 100%. The percentage who can successful extract and decode an email attachment is much less than 100%. The percentage who can view a government form or a corporate brochure in PDF format and read it with Acrobat is much less than 100%.

And the average age of their computers and operating systems is much more than three years--and they're not likely to update their email programs.

Whatever is done needs to be 100% backward compatible with existing email clients, not requiring even simple upgrades, or an astonishing proportion of real-world Net users will be disenfranchised.

(And please, let's not have any facile expressions of contempt for AOL users or webtv clients or people who bought email appliances (that includes one of the retirees I mentioned).

Re:Backward compatibility (2, Insightful)

bafu (580052) | more than 11 years ago | (#5471646)

Whatever is done needs to be 100% backward compatible with existing email clients, not requiring even simple upgrades, or an astonishing proportion of real-world Net users will be disenfranchised.

Whatever is done needs to be able to deliver email while effectively correcting the system of incentives that encourages spamming. Any other considerations, like it or not, can only addressed insofar as they don't interfere with acheiving that goal. The current email system is broken and an ever-increasing amount of noise is flooding into that system. The end result is that the delivery system (which, as you have pointed out, is important to so many people) is in the process of collapsing. You talk as if the choice is between a healthy email system and some new one that we don't really need, when it's really a choice between a system that will inevitably be rendered useless by spam volume and a new one. And that new one has to include whatever features are required to avoid a repeat performance.

If the best solution is all server-side (and some proposals are) they may be able to also get the kind of backward-compatibility that you feel is required. But, make no mistake, we aren't doing anyone any favors if we don't actually fix the current system, even if the fix does eventually require a client upgrade when the last parts of old system are finally phased out. If it is any comfort, I would expect that "AOL users or webtv clients or people who bought email appliances" will be the least-effected since their providers understand that market and have control of both ends of that particular client-server implementation. routing (0, Interesting)

axxackall (579006) | more than 11 years ago | (#5471268)

Look at the subject. Sounds crazy? It is crazy - the traffic from/to virtual IP addresses is not routed. Even inside your proprietary networks. The only way to route it is to translate address to some real one from the list of non-anonymous addresses. Thus, every packet in Internet is identified by its source. Just in case of NAT the source points to that local ISP.

Same thing must be done in email business. All messages must have correct From field, and all must be signed with key identified by From field. All keys must be signed in a public (well known and trusted) CA. The router should relay only messages with verified signature keys.

No more anonymous email!

It is not a business of the router to watch the content of the message. But the header (let's think that the sig is the part of the header) must be checked. Specifically, the key of the sig must be verified in CA for being non revoked. Of course the revoke list can be cached on the router side for performance reasons.

Then it will be very easy to create a report gathering center (it could be a DB at the same CA), where you can send the fingerprints of bad guys. Once the key collects more than N (specified) bad reports, the key is revoked, and all messages with key won't be relayed anymore.

Of course, inside the interprise you can have "old-style" non-signed email. But in order to relay the message into outside of theintranet, it must be signed. That can be done automatically by the enterprise relay on behalf of corporate users. Even using the corporate key - remember NAT for IP?

Have this infrastructure on the place and it will often unnecessary to presecute spammers: their keys will be revoked after N bad reports.

By the way, how to send a bad report? Simple. Remember Y!Mail UI? They have a link in the message header area: "Report as a spam". Same button should be in every MUA UI: "Report the key a spammer's one". As well as another button: "Bleck messages with this key" - you still can do blocking (or any other filtering) of messages locally based on the key (ID).

Why a key is better than a return address? You must have a valid key. That's the key :)

Can you generate new keys with the same speed as you can generate your return addresses? I don't think so. And if you still can generate enough of key to keep your business profitable, then let's change your profit calculation forumal. From now on, the spammer has to pay big penalties for revoked keys.

Am I am asking too much?

Re: routing (3, Insightful)

alansz (142137) | more than 11 years ago | (#5471366)

You are asking a little too much in a few ways.

Computationally, that's a lot of public key encryption in action. For sites that process large amounts of email, this is going to hurt. But let's say we can throw money and CPU at that problem. And I suppose we can do the same for the problem of the tens of millions of key/address pairs we'll need to store centrally. Not so bad, then.

Socially, the existence of anonymous email may be important and valuable. But I suppose anonymous remailers could appear and use their own corporate keys to signed messages in your scheme.

Practically, you'd need a way to prevent denial of service attacks against someone's email by generating sufficient fradulent 'bad reports' to cause their key to be centrally revoked. This seems bad.

Nothing totally insurmountable, but still pretty annoying to deal with.

(P.S. No packet on the internet is truly identified by its source in most cases. IP addresses can be forged fairly trivially. This doesn't really bear on your proposal, but thought you should know.)

Re: routing (1, Funny)

Anonymous Coward | more than 11 years ago | (#5471388)

Am I am asking too much?

A possible solution?... (0)

26199 (577806) | more than 11 years ago | (#5471269)

All mail accounts should use whitelists enforced by the ISP.

The only way to get on a whitelist is to send an email:

Subject: Request to join whitelist
From: ...
Reason: ...(100 chars max)...

Any emails from people who are not on the whitelist must be of this format or they are automatically rejected at the ISP. Mail clients recognise request mails and notify the ISP of the user's choice.

Mail clients can also automate the process of requesting to be added: 'you haven't emailed ... before. Please say a few words to persuade them to accept your emails, e.g. introduce yourself.'

Unfortunatley the age-old problem crops up: this is only a good solution if everyone adopts it. (Then, for example, mailing lists can mail out requests to new members...)

Re:A possible solution?... (1)

Fuzzums (250400) | more than 11 years ago | (#5471387)

whitelists are only interesting for personal mail.
how about companies. for them this is no solution.

Spam can be avoided without protocol changes. (0, Troll)

Krapangor (533950) | more than 11 years ago | (#5471275)

You just grab spam by its very nature.
Spam is highly redundant commercial advertisement. And we don't want it. So the basic approach would be to exploit this redundancy to filter from the original message streams. However highly localized approaches like personal mail filters will always fail due to the high variety of spam.
How would your personal mail filter know Japanese or Chinese spam ? Not at all, it would just let the spam mails through.
So we can only solve this problem by a worlwide highly sophisticed effort. And the key component will be again the identification of redundancy.

The idea is to build up redundancy signatures of email messages. The global network of SMTP servers exchange these signatures by a grid orientated P2P network. When the distribution of a special signature is worldwide too high then it's identificated as spam and destroyed everywhere [1 [] ]. Note that a distributed annealing algorithm can do this in O(log(log(n)))+theta(n) operations (theta(n) a blotzmann distribution due to the annealing process).

Building up these signatures is a little more complicated, something like MD5 checksum won't be sufficient. After some preparsing we have to project the text into a suitable banach space for further operations. Cleckerson and Allman have proposed an infinite dimensional Lie group for this task, surely any Diffeomorphism group over a Hardy space will do [2 [] ]. In this space we can build unique (!) singnatures using a simple frequency domain transformation. However we can't of course exchange an infinite amount of data, so an approximation will have to do it. Reseach any Valdpornik and Rosé has shown that there are decent approximations for this task [3 [] ]. So we can use these thing to build up our signatures and the whole stuff works indeed.

However the highly numerical approach requires DSP coprocessors in mail servers. But I think that Intel and AMD will throw in a DSP core to their server processors in a few years anyway, so that's not a big issue.

Re:Spam can be avoided without protocol changes. (2, Insightful)

WolfWithoutAClause (162946) | more than 11 years ago | (#5471468)

Spam is highly redundant commercial advertisement. And we don't want it. So the basic approach would be to exploit this redundancy to filter from the original message streams.

No. Not all redundant mail is spam. There are plenty of legitimate distribution lists out there.

However highly localized approaches like personal mail filters will always fail due to the high variety of spam.

Yes. However, if a high enough % of people point at an email message and say 'spam' then it's spam. People are very good at spotting spam- so a mechanism that records what people think about the mail and not deliver it to anyone that hasn't already read it would be very successful. If 90% of the first few thousand people to read an email say it's spam, the other million need never see it at all.

I don't see the big issue. (-1, Troll)

Moderation abuser (184013) | more than 11 years ago | (#5471288)

My regular mailbox has 0 spam mails. My spamprobe account has 756 spam mails.

If everyone simply filtered it out of the way and didn't read it, spam would go away. The only conclusion I can come to on this is that those who do receive spam are people who want to receive spam.

Dr. Jeffery Race's proposal on NANOG (3, Informative)

djmitche (536135) | more than 11 years ago | (#5471318)

A participant in the NANOG (North American Network Operators' Group) mailing list recently posted a Best Current Practice proposal [] regarding spam to that list. He was fairly heavily flamed by some of the frequent posters on the list, but his idea (which has a basis in sociology) does have some merit.

He uses the idea of emergent structure. To quote, " if all (or even most) players expect other players to act in a certain way, a predictable pattern of behavior emerges which becomes compelling for all players. This is the way all organizations work."

*Barf* (2, Insightful)

Keebler71 (520908) | more than 11 years ago | (#5471327)

Replace "IETF" with "Microsoft" and you have this [] slashdot story a whopping two weeks ago. Of course the slant then was how evil Microsoft was for daring to make people pay for email (which of course was not true... the article was about email accountability to reduce spam).

Disadvantage of the current internet (2, Insightful)

sabri (584428) | more than 11 years ago | (#5471330)

When the protocols we all use now were developed, everybody trusted each other. There wasn't a real need for advanced security options. Nowadays, with the current commercialization of the net (which also provides me with my income) it looks as if the commercials are winning. By commercials I mean those who have absolutely no respect for other peoples right or bandwith. Let's not forget that spam isn't the only problem: dos attacks are a real threat too.

Due to the original designs being not real secure, I'm quite sure that the spam problem can not be solved without fundamental changes in the way we use email nowadays. Perhaps the policy regarding blacklisting can be changed: at this moment most people accept mail from everybody, but not from a few blacklisted sites. It's likely that this will be changed: we don't accept your mail unless we know who you are. Unfortunately, even then there will always be people who will abuse it. Hopping from one account to another, or sue-ing every single ISP that has the guts to disconnect their connection after spamming. In short: it's not simply a technical matter, their will be a need of *globally equal* legislation too. Legislation alone won't do the trick either. No, it's time for Mr Geek to marry Miss LawAndOrder.

Don't forget that the IETF is not the first to attempt to find a solution. RIPE [] has its anti-spam workgroup for example.

YAES (Yet another e-mail solution) (1)

gozar (39392) | more than 11 years ago | (#5471338)

Why can't the current SMTP servers keep a list of trusted servers, and anything that is not trusted it severly limits the delivery rate (maybe 1 per second (minute?) and then increase the rate).

It wouldn't eliminate SPAM, but it would slow down its propagation.

Been Done Before (1)

1nv4d3r (642775) | more than 11 years ago | (#5471361)

IETF to Look at Spam

I've been looking at spam for years. In fact, I can honestly say that I look at it more every year. Hasn't helped at all.

Come on, IETF, try something we haven't done yet! Like get congress to declare Spam an act of Terror.

Maybe... (1)

pr0c (604875) | more than 11 years ago | (#5471378)

Maybe with the knowledge that filtering is imporving and new protocols, proggies etc are on the way spammers will just stop spamming.. LOL

So in a nutshell you could handle it this way (i didn't think of this my self i read the story and links and other messages)...

Mails are not auto delivered they sit on the server so any fake emails looking like they came from someone else will not get delivered.

So.. Fag Spammer sends mail looking like it came from and the client sees (automatically) that there is email to pick up from and then requests the mail, cowboyneal's postoffice responds no such message and then deletes the notification... boom spam stopped. At this point in time this would stop 90% of spam dont' you think? Its such a simple solution.. a big undertaking maybe but simple.

And this would cause email to come from real addresses only or atleast real servers. But then you have the same problem... blacklists, you'd have to either setup your own blacklist or *GASP* assume someone elses blacklist aint gonna fuck up your mail. On the other hand you know the real server so its easier to talk to the datacenter/isp the spammer is using and have their box shut down before that spam is picked up and since it was never delivered the whole time.. just ready for pickup i guess a lot of spam is still stopped.

Novel use of SMTP (0)

vrmlguy (120854) | more than 11 years ago | (#5471406)

Here's an idea that uses existing SMTP to accomplish much of what's been suggested, while avoiding certain drawbacks.

Someone's server connects to yours and sends the MAIL TO and RCPT FROM commands. Your server checks this info, along with the originating IP address), against a list of pre-authenticated sites (your employer, your family, etc) to decide if it will accept the DATA command. If so, you get the mail; otherwise the connection is severed. The sender should then start retrying deliveries intermittently over the next few days.

Meanwhile, you get a message from your server telling you that mail is available from so-and-so addressed to such-and-such. You use a canned reply: DENY, to keep rejecting the mail until the server gives us, ACCEPT ONCE, to accept the next message with that description, or ACCEPT FOREVER, to add the description to your permanent acceptance list.

Note that "important" stuff gets fully delivered immediately, so you can check your email offline later, while potential spam is held at the sender's expense, not yours.

Also note a simple variation on this idea: your SMTP sever could decide to accept the DATA commnand, but then read the mail headers, evaluate them, and then decide whether to break the connection prior to accepting the body of the message. This would give you enough data to perform stochastic filtering on the message. (I've seen reports [] that indicate that the headers are the most useful data when applying spam filters.)

That should be Internet RESEARCH Task Force (5, Informative)

notonymous (606597) | more than 11 years ago | (#5471412)

Actually, it's the IRTF -- not the IETF -- that is undertaking this work. To quote from the IRTF home page [] - "[Mission] To promote research of importance to the evolution of the future Internet by creating focused, long-term and small Research Groups working on topics related to Internet protocols, applications, architecture and technology."

Don't expect a quick fix from this initiative.

Make the sender pay (1)

Catamaran (106796) | more than 11 years ago | (#5471426)

See for example hashcash [] and camram []

Here's my long-winded solution... (1)

sethadam1 (530629) | more than 11 years ago | (#5471432)

I thought about it one day and just rambled on on my weblog... =1 046736931


Summary of IETF ASRG discussions (5, Informative)

wayne (1579) | more than 11 years ago | (#5471490)

Four days ago when this was mentioned on slashdot [] , I posted the following summary of what had been discussed. Sadly, this summary is still pretty complete.

From what I take from all this discussion is that the only "solution" to spam is to do the types of things that we have been doing for years, but to do more of it and quicker. Use well run DNS blacklists (Spamhaus SBL [] , ordb [] , dsbl [] , etc.), use good content filters (bayesian filters, etc.), use bulk mail detectors such as DCC [] or vipul's razor [] , etc.) and per-user whitelists and blacklists.

Or, combine all of the above techniques by using SpamAssassin []


I've been subscribed to the list since near the beginning and have been following it fairly closely. Much of the discussion has been rehashes of old topics such as "what exactly is spam?", "make the sender pay something, either money or CPU", etc.

The most interesting discussions that I've seen so far are:

  • Mail transfer programs (MTA) such as sendmail, exim, qmail, etc., should keep track of sender-recipient pairs. The first time the sender-recipient pair shows up, sendmail (or whatever) should issue a "temporary delivery failure". This will force the sending mail transfer program to queue the mail and resend it later. This is completely backwards compatible and doesn't require end users to do anything.

    Most spam specific programs will not queue and retry, and thus the spam will be dropped.

    Spammers that use real mail transfer programs or open relays will need to be able to hold all their outgoing spam for a while, increasing the spammer's costs and slowing down the delivery of spam. Legitimate email will not be thrown out, it will only be delayed and only for the first time.

    Of course, you don't really want the databases to remember every sender-recipient pair forever, nor do you want to remember pairs that were added by spam so this really isn't a "first time" database, but it is close.

    Apparently the "canit" program already does this, but I had not heard of this technique before.

  • Spam filtering really needs to be done while the email is being received. Sendmail can already do this with the milter filter, but other MTAs should also. Most mail servers are I/O bound, not CPU bound so this really isn't much of a burden on the server.

    If you filter during the email receive process, you can make the sending MTA do the bounce. This means that you will not have to deal with spammers forging "from" and "reply-to" headers. You won't have to clean up bounces that never succeed, nor will you be responsible for bouncing spam to another victim that the spammer selected for the "from" or "reply-to" headers.

    Also, false positives will recieve a bounce message instead of just disappearing. This reduces the danger of important email being lost.

  • There are also several proposals to deal with ways of verifying that email being sent from a given IP address and claiming to be from a certain domain is actually authorized to send email claiming it is from that domain.

    Right now, there are DNS records that tell you which IP addresses are valid to try and send email to for a given domain (the MX records), but many ISPs have different machines for sending and recieving email. There are currently no DNS records to tell you which tell you which IP addresses a domain will send email from.

    The problem with this kind of proposal is that there are many people who think they have legitimate reasons to forge "from" or "reply-to" addresses. It also forces ISPs to make sure that every time they add a new outgoing mail server, they need to update the list of valid IP addresses. If they forget to do this, then only bleeding edge spam filters will detect a problem.

Re:Summary of IETF ASRG discussions (1)

Animats (122034) | more than 11 years ago | (#5471654)

If "temporary delivery failure" was an end-to-end message, that would be effective. But it only goes back one hop. So open relays will resend their queued spam.

Worse, the spammers who send their messages multiple times will still get through.

In the mean time... (1)

stinkykitten (531841) | more than 11 years ago | (#5471530)

Until the ultimate fix for spam is created why can't mail servers just limit the amount of mail that is sent by any user?

Is it possible to setup sendmail and such to limit the number of emails sent to a quantity over time? If there was a limit of say 1 email every 5 minutes for generic users (obvoiusly, some algorithym that would allow for small bursts would make sense), that would effectively stop someone from spamming from a regular account. If a person wants to setup a mass mailiing account they will have to pay for it.

If this was implemented then even the hijacking of a server would be pointless as the server would normally run in restricted mode. If spammers were to hack or create a false unrestricted account then they would be opening themselves up for far more than just spamming violations, creditcard fraud would make spamming a much larger risk.

Why do so many people keep looking for the next answer before they use the tools they already have?

If they are reinventing SMTP, might as well... (5, Insightful)

Istealmymusic (573079) | more than 11 years ago | (#5471566)

...allow binary transfers. I can't tell you how much CPU time has been wasted by base64 encoding binaries, sending them over an inefficient protocol, and decoding them on the other end. yEnc does a good job but the whole encoding shenanigan is a major pain for anyone trying to send family photos or the latest AFI album. Please, IETF, make a better 8-bit clean push protocol, because SMTP is the only one we have.

Solution: Client Edits /Manages E-mail on Server (0)

securitas (411694) | more than 11 years ago | (#5471585)

I have often thought that client software (preferably cross-platform) that lets the user remotely view e-mail on the server and delete the spam BEFORE downloading mail to a local machine is something that would make the world a better place.

I have looked for a client that implements this strategy but have been unsuccessful to date. Perhaps my Googling skills aren't up to the task.

Does anyone here know of software that lets the user do this?

Essensially, what we need is forced authentication (1, Insightful)

Kjella (173770) | more than 11 years ago | (#5471598)

If you try to deliver a mail to, you have a system for finding out what server mail should be delivered to. This should also work the other way around, any mail from should come from one of these same server. Note that it doesn't have to actually do both, just put it on the same "acceptable" server list.

Now what happens to all the people that want to send mail from a different host? They need to auth with their "real" mail server. So if I want to send from with a address, it'll have to go like this: -> ->

This would not stop spam per se, but it would stop fake from e-mail adresses, which is extremely annoying.


The next step seems obvious (2, Funny)

solarrhino (581267) | more than 11 years ago | (#5471622)

CMTP - Complex Mail Transfer Protocol.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?