I'd like to know why no one has come up with a decent, washable keyboard
Get yourself seven cheap keyboards and one expensive one. Throw them in the wash bucket when you go to bed. In the morning, plug in a fresh keyboard from the drying closet. Think of it like underwear.
I've gotten exactly one spam message in my inbox. That's an excellent percentage.
Excellent *for you* that is. How many unwanted emails have you sent out to joe-job victims? Here's my basic problem - after black/white list weeding, you're always left with a body of messages that you need to decide what to do with. Rather than taking on that burden yourself, you lay it off on others. That's just plain rude, and little different than the MO of a spammer - "let other people bear the costs of my own selfish actions"
That's only until *that* person gets a similar filter: it should be easy to recognize that this is a response to an e-mail they didn't send, and just delete it.
So I have to get one of these filters to deal with the stuff that other users of this filter are throwing at me? As I said, it's not very polite and "just delete it" is the favorite mantra of spammers. I'm cautious about *any* system that automatically generates email in response to arbitrary received mail - the potential for screw-ups is high, and ultimately, if the goal is reducing unwanted email, increasing the number of emails sents is counter-productive.
Simple : you reject at the "MAIL FROM:" stage if the envelope sender is "bad". That's precisely *why* rejecting like this is so much better than content-based filtering, but of course, mostly the spam has a genuine address in the envelope sender, so this only works for a small set of messages (and this is after the RBL checks).
I've found probably half the sites I have to give my email address to won't grok the username+filtername@mydomain.com syntax
Interesting, and a little surprising. I use the dash character for alias extensions (eg username-filtername@example.com) and I've never come across a site that had problems with it.
What you're planning has already been done, it's called TMDA, and it's not such a good idea. You're going to send out 800 "challenge" emails per day - have you given any thought to how many of those will be genuine addresses, but have nothing to do with the spam you receive because they just happen to be the joe-job victim? These kind of challenge/response systems may slighlty alleviate your own suffering through spam, but at a cost to all those unfortunate enough to have had their email addresses faked. And if the sheer impoliteness of such net behaviour doesn't put you off, note that you're using up more of your own bandwidth to send out such challenges
If any of the smtp exchange or address lookup fails, just forget it, they're probably not real anyway
It would make a lot more sense to make these kind of checks when you're receiving the email in the first place. Reject at the SMTP level - you never accept and process the spam in the first place
By "innocent" I was referring to the joe-job victims whose addresses are faked by spammers. As for open relays, surely you're aware that they represent only a small percentage of spam sources these days - most of the big spam runs are injected using armies of trojanned PCs (think about how you might use such an army to defeat SPF).
I think it's fair to characterise AOL's involvement with SPF as "experimental" rather than "adopting" at this point. And the reason for this is obvious - so much spam has a faked @aol.com address (I know of some mail admins who simply reject all mail "from" aol.com; others will weight against aol.com in spamassassin). Note that adopting SPF does nothing for AOL users *receiving* spam.
What you describe as a problem with SMTP - lack of sender authentication - is actually a design feature. Think about it this way - why should I have to be authorised by some corporation in order to send email? Are you arguing that one shouldn't be permitted to send email if you don't pay money to an ISP? Of course, the big ISPs *would* love this and are arguing about the method, but that's because who ever "owns" the method owns email and a potentially lucrative revenue stream (viz your example of the certificate proposal).
I'm trying hard not to sound like I'm throwing my hands in the air and wailing that we can never fix the spam problem, and obviously (I hope!), I loathe spam as much as anyone. But I also recognise that this is a *difficult* problem. Lots of very bright people have put considerable effort into thinking about solutions, and no-one has yet been successful. Even reverse-DNS type methods are nothing new. I'm not suggesting that you're an anti-spam kook (and I certainly am not), but if you haven't seen it already, check out the "You Might be an Anti-Spam Kook If..." page to get a flavour of the kind of difficulties and subtleties involved in coming up with a Final Ultimate Spam Solution.
So, we have a bet. Actually, I'm going to go crazy and offer a dollar on non-uptake of SPF and another dollar on non-uptake of TMDA. If or when I'm proven wrong, I'll start arguing over your criteria of "50% of the domains with MX records", which leaves me some wiggle room;)
I really wish now I'd written "significantly more people" instead of "everyone", since of course, "everyone" using TMDA is a special case, and only applies in the utopia where there is no spam and so anti-spam measures aren't necessary anyway. We can never get to the "everyone" scenario for the reason I've already given - the burden is not being mitigated, merely increased and spread around. What you see as "encouraging faster adoption of SPF" I see as inflicting damage on innocent third parties. Of course, you may be right and I may be wrong. But I've got a dollar here says neither TMDA nor SPF will ever take hold
If everyone used TMDA, then there wouldn't be non-whitelisted spam
I'm still trying to parse that to make sure I understand you. "non-whitelisted spam" is spam from a source that I haven't whitelisted? How is that different than the spam I have today?
You haven't addressed my basic problem with TMDA as spam-reduction technique in that it defrays the burden of spam on the TMDA user by spreading that burden to other innocent third-parties. TMDA (indeed any anti-spam system that generates emails to purported senders) can never offer a global solution to spam, because it just spreads the mess around. It may work well for a small number of individuals, but at a cost to the wider community, tragedy-of-the-commons style.
Compare also with email systems that detect viruses and generate emails to the purported sender - this makes a virus outbreak worse by flooding innocent third parties with alarming warnings (at best) or infective emails (in the worst cases).
If you switched your notifications from weekly to monthly because your customers couldn't keep up (or it was too embarassing) wouldn't that tell you that you had a problem?
And worse still, you then immediately break the fixed monthly cycle anyway because of a fix that is so critical. I think your assessment that this may be indicative of an underlying problem is fair.
Big unsurprise, no CAN-SPAM isn't working (assuming by "working" you mean reducing spam).
A sample from my spam-bucket this morning (one of those logo design offers):
[snip]This mailing has been performed by Internet Marketing Solutions,
1719 University Avenue, Bronx NY 10453 USA,
in compliance with the CAN-SPAM Act of 2003,
approved and signed by the president of
The United States of America on Dec. 16, 2003.
For this reason, this email cannot be considered SPAM.
I think people don't really understand what having windows 2000 SP1 source code spreading on internet really means. That's quite important and even if it's only part of the source code it's already enough for the first exploits to appear.
The author was kind enough to tell us about the first one, but I bet many others did find bugs and didn't report them because they are working on viruses and attacks using them.
Isn't it interesting that after a few days of access to the source code, exploits are appearing for obvious bugs; yet MS have had the source code available to themselves for years but still managed to neither find nor fix these same obvious problems.
Note also that in the past, lack of access to the source hasn't prevented the *ahem* occasional exploit being developed anyway.
TMDA certainly isn't for everyone. By sending out challenges to unknown senders, you shift the burden from yourself to the joe-job victim. Nice for you, not so nice for the poor people on the receiving ends - each spam you receive generates a spam for the joe-job victim. Not even that nice for you either, since for every spam you receive, you double the bandwidth it has consumed by generating an outgoing message. If everybody did use TMDA, our systems would all be clogged under the flurry of challenges. TMDA has its place, but that place is not as a general purpose spam-reduction technique.
Isn't it typical for the receiver to reverse-lookup the sender's IP, or at least forward-lookup whatever you hand it in the HELO to make sure you're legit ?
Some systems do this, but any sensible system will not reject solely on this basis because it breaks delivery of some legitimate messages. In particular, nowhere does it say that mail "from" a particular domain has to emanate from a particular host (there's no analogue to MX for *sending* hosts). That's what SPF and similar techniques are trying to impose - registered "senders" for a particular domain.
The [envelope-sender] cannot be spoofed in most cases
Simply : untrue. It's as easy to fake the envelope sender as it is the From: header. I think you're getting confused with "Received" headers, where each mail system inserts its own bit of tracking information. The envelope-sender is completely under the control of the sender, and (usually) propagates un-modified as an email is handed between systems (indeed, one of the criticisms of SPF is that by modifying the envelope sender you break forwarding).
Experience has shown that those who say "simply replace SMTP" do not understand the nature of the problem. It's no coincidence that one of the symptoms of being an anti-spam kook is that your solution involves replacing SMTP
Quoting the Sun second-hand by way of the Sydney Morning Herald doesn't really count as a news source. The Sun, as a flagship of Rupert Murdoch's News International has its own axe to grind with the BBC. You can't trust the Sun's "reporting" on anything, least of all about subjects where Murdoch has a vested interest. Your link is about as convincing as if the Sydney Morning Herald had quoted Slashdot.
I wish they had just reported as fact that Saddam had WMDs
Haven't you been paying attention? Saddam didn't have weapons of mass destruction, he had weapons programme related activities. Please do try to keep up.
As I recall, there was more to the strategy than you describe. You could make the "n" characters appear by (I think) "shooting" numbers that added up to 9 (eg 8 followed by 1, 7 followed by 2 etc). And the pace did increase, but only up to a certain point (level 9 ? can't remember); then it would revert to level 1 pace, but everything starting from one place closer.
Good times indeed. Can someone who actually remembers this game properly refresh my memory.
I recall a site I worked at back in the eighties where we had a certain model of mainframe, and a support contract valued at tens of thousands of dollars a year. We decided to "upgrade" the machine to a higher spec in the same series, and the next time the engineer was onsite for routine maintenance (which was usually every week), he took out his wire cutters and snipped a link on one of the processor boards. Bingo - hardware upgrade! The link was some kind of jumper that imposed certain restricions on the hardware. And yes, there was corresponding increase in the support contract costs too...
I receive around 70,000 spam messages to my account monthly...I use TMDA...AT LEAST 75% of the email received here is spam
In other words, you send out over fifty thousand "challenge" emails a month, most all of which will be to innocent third parties who were unfortunate enough to be joe-jobbed. Not only are you bombarding others' inboxes with crap they never asked for, you are effectively doubling your own bandwidth consumed by spam. TMDA not only doesn't solve the spam problem, it actively makes the situation worse.
Slashdot Mirror
--
The number of the modding shall be three, four shall the number of the modding not be, neither shall it be 2...
5 is right out.
Get yourself seven cheap keyboards and one expensive one. Throw them in the wash bucket when you go to bed. In the morning, plug in a fresh keyboard from the drying closet. Think of it like underwear.
I've gotten exactly one spam message in my inbox. That's an excellent percentage.
Excellent *for you* that is. How many unwanted emails have you sent out to joe-job victims? Here's my basic problem - after black/white list weeding, you're always left with a body of messages that you need to decide what to do with. Rather than taking on that burden yourself, you lay it off on others. That's just plain rude, and little different than the MO of a spammer - "let other people bear the costs of my own selfish actions"
That's only until *that* person gets a similar filter: it should be easy to recognize that this is a response to an e-mail they didn't send, and just delete it.
So I have to get one of these filters to deal with the stuff that other users of this filter are throwing at me? As I said, it's not very polite and "just delete it" is the favorite mantra of spammers. I'm cautious about *any* system that automatically generates email in response to arbitrary received mail - the potential for screw-ups is high, and ultimately, if the goal is reducing unwanted email, increasing the number of emails sents is counter-productive.
You're right - I did misunderstand the original poster, as of course, you have to actually set up the dash char on the server.
Simple : you reject at the "MAIL FROM:" stage if the envelope sender is "bad". That's precisely *why* rejecting like this is so much better than content-based filtering, but of course, mostly the spam has a genuine address in the envelope sender, so this only works for a small set of messages (and this is after the RBL checks).
I've found probably half the sites I have to give my email address to won't grok the username+filtername@mydomain.com syntax
Interesting, and a little surprising. I use the dash character for alias extensions (eg username-filtername@example.com) and I've never come across a site that had problems with it.
What you're planning has already been done, it's called TMDA, and it's not such a good idea. You're going to send out 800 "challenge" emails per day - have you given any thought to how many of those will be genuine addresses, but have nothing to do with the spam you receive because they just happen to be the joe-job victim? These kind of challenge/response systems may slighlty alleviate your own suffering through spam, but at a cost to all those unfortunate enough to have had their email addresses faked. And if the sheer impoliteness of such net behaviour doesn't put you off, note that you're using up more of your own bandwidth to send out such challenges
If any of the smtp exchange or address lookup fails, just forget it, they're probably not real anyway
It would make a lot more sense to make these kind of checks when you're receiving the email in the first place. Reject at the SMTP level - you never accept and process the spam in the first place
Innocent? Like Open Relays are innocent?
By "innocent" I was referring to the joe-job victims whose addresses are faked by spammers. As for open relays, surely you're aware that they represent only a small percentage of spam sources these days - most of the big spam runs are injected using armies of trojanned PCs (think about how you might use such an army to defeat SPF).
I think it's fair to characterise AOL's involvement with SPF as "experimental" rather than "adopting" at this point. And the reason for this is obvious - so much spam has a faked @aol.com address (I know of some mail admins who simply reject all mail "from" aol.com; others will weight against aol.com in spamassassin). Note that adopting SPF does nothing for AOL users *receiving* spam.
What you describe as a problem with SMTP - lack of sender authentication - is actually a design feature. Think about it this way - why should I have to be authorised by some corporation in order to send email? Are you arguing that one shouldn't be permitted to send email if you don't pay money to an ISP? Of course, the big ISPs *would* love this and are arguing about the method, but that's because who ever "owns" the method owns email and a potentially lucrative revenue stream (viz your example of the certificate proposal).
I'm trying hard not to sound like I'm throwing my hands in the air and wailing that we can never fix the spam problem, and obviously (I hope!), I loathe spam as much as anyone. But I also recognise that this is a *difficult* problem. Lots of very bright people have put considerable effort into thinking about solutions, and no-one has yet been successful. Even reverse-DNS type methods are nothing new. I'm not suggesting that you're an anti-spam kook (and I certainly am not), but if you haven't seen it already, check out the "You Might be an Anti-Spam Kook If..." page to get a flavour of the kind of difficulties and subtleties involved in coming up with a Final Ultimate Spam Solution.
So, we have a bet. Actually, I'm going to go crazy and offer a dollar on non-uptake of SPF and another dollar on non-uptake of TMDA. If or when I'm proven wrong, I'll start arguing over your criteria of "50% of the domains with MX records", which leaves me some wiggle room ;)
I really wish now I'd written "significantly more people" instead of "everyone", since of course, "everyone" using TMDA is a special case, and only applies in the utopia where there is no spam and so anti-spam measures aren't necessary anyway. We can never get to the "everyone" scenario for the reason I've already given - the burden is not being mitigated, merely increased and spread around. What you see as "encouraging faster adoption of SPF" I see as inflicting damage on innocent third parties. Of course, you may be right and I may be wrong. But I've got a dollar here says neither TMDA nor SPF will ever take hold
I'm still trying to parse that to make sure I understand you. "non-whitelisted spam" is spam from a source that I haven't whitelisted? How is that different than the spam I have today?
You haven't addressed my basic problem with TMDA as spam-reduction technique in that it defrays the burden of spam on the TMDA user by spreading that burden to other innocent third-parties. TMDA (indeed any anti-spam system that generates emails to purported senders) can never offer a global solution to spam, because it just spreads the mess around. It may work well for a small number of individuals, but at a cost to the wider community, tragedy-of-the-commons style.
Compare also with email systems that detect viruses and generate emails to the purported sender - this makes a virus outbreak worse by flooding innocent third parties with alarming warnings (at best) or infective emails (in the worst cases).
Good point. I recently added rules for the Habeas headers, since the only emails I've ever seen them in have been spam.
And worse still, you then immediately break the fixed monthly cycle anyway because of a fix that is so critical. I think your assessment that this may be indicative of an underlying problem is fair.
Big unsurprise, no CAN-SPAM isn't working (assuming by "working" you mean reducing spam).
A sample from my spam-bucket this morning (one of those logo design offers) :
[snip]This mailing has been performed by Internet Marketing Solutions, 1719 University Avenue, Bronx NY 10453 USA,in compliance with the CAN-SPAM Act of 2003,
approved and signed by the president of
The United States of America on Dec. 16, 2003.
For this reason, this email cannot be considered SPAM.
Isn't it interesting that after a few days of access to the source code, exploits are appearing for obvious bugs; yet MS have had the source code available to themselves for years but still managed to neither find nor fix these same obvious problems.
Note also that in the past, lack of access to the source hasn't prevented the *ahem* occasional exploit being developed anyway.
TMDA certainly isn't for everyone. By sending out challenges to unknown senders, you shift the burden from yourself to the joe-job victim. Nice for you, not so nice for the poor people on the receiving ends - each spam you receive generates a spam for the joe-job victim. Not even that nice for you either, since for every spam you receive, you double the bandwidth it has consumed by generating an outgoing message. If everybody did use TMDA, our systems would all be clogged under the flurry of challenges. TMDA has its place, but that place is not as a general purpose spam-reduction technique.
Some systems do this, but any sensible system will not reject solely on this basis because it breaks delivery of some legitimate messages. In particular, nowhere does it say that mail "from" a particular domain has to emanate from a particular host (there's no analogue to MX for *sending* hosts). That's what SPF and similar techniques are trying to impose - registered "senders" for a particular domain.
Simply : untrue. It's as easy to fake the envelope sender as it is the From: header. I think you're getting confused with "Received" headers, where each mail system inserts its own bit of tracking information. The envelope-sender is completely under the control of the sender, and (usually) propagates un-modified as an email is handed between systems (indeed, one of the criticisms of SPF is that by modifying the envelope sender you break forwarding).
Experience has shown that those who say "simply replace SMTP" do not understand the nature of the problem. It's no coincidence that one of the symptoms of being an anti-spam kook is that your solution involves replacing SMTP
Or just maybe, they put things in quotes when they are, um, quoting what somebody said?
Quoting the Sun second-hand by way of the Sydney Morning Herald doesn't really count as a news source. The Sun, as a flagship of Rupert Murdoch's News International has its own axe to grind with the BBC. You can't trust the Sun's "reporting" on anything, least of all about subjects where Murdoch has a vested interest. Your link is about as convincing as if the Sydney Morning Herald had quoted Slashdot.
Haven't you been paying attention? Saddam didn't have weapons of mass destruction, he had weapons programme related activities. Please do try to keep up.
As I recall, there was more to the strategy than you describe. You could make the "n" characters appear by (I think) "shooting" numbers that added up to 9 (eg 8 followed by 1, 7 followed by 2 etc). And the pace did increase, but only up to a certain point (level 9 ? can't remember); then it would revert to level 1 pace, but everything starting from one place closer.
Good times indeed. Can someone who actually remembers this game properly refresh my memory.
I recall a site I worked at back in the eighties where we had a certain model of mainframe, and a support contract valued at tens of thousands of dollars a year. We decided to "upgrade" the machine to a higher spec in the same series, and the next time the engineer was onsite for routine maintenance (which was usually every week), he took out his wire cutters and snipped a link on one of the processor boards. Bingo - hardware upgrade! The link was some kind of jumper that imposed certain restricions on the hardware. And yes, there was corresponding increase in the support contract costs too...
Good for you, but not so good for others
In other words, you send out over fifty thousand "challenge" emails a month, most all of which will be to innocent third parties who were unfortunate enough to be joe-jobbed. Not only are you bombarding others' inboxes with crap they never asked for, you are effectively doubling your own bandwidth consumed by spam. TMDA not only doesn't solve the spam problem, it actively makes the situation worse.