Slashdot Mirror
Novel Method for Universal Email Authentication
MKaplan writes "Most spam is sent using spoofed domains. Email authentication schemes such as SPF attempt to foil spoofing by having domain administrators publish a list of their approved outgoing mail servers. SPF is sharply limited by incomplete domain participation and failure to authenticate forwarded email. A paper describes a novel method to rapidly generate a near-perfect global SPF database independent of the participation of domain administrators. A single email from an unauthenticated domain is bounced and then resent — this previously unauthenticated domain and the server listed in the return path of the resent bounce are entered into a globally accessible database. All future emails sent from this domain via this server will be authenticated after checking this new database. Mechanisms to authenticate forwarded email and to nullify subversion of this anti-spam system are also described."
Isn't this the same thing as greylisting?
Mail servers are authenticated by Spamcop and forward spam automatically to Spamcop which adds it to their database. When using reject_rbl_client bl.spamcop.net SPAM is blocked.
Works like a charm!
So what happens when you receive an email from a big site like Sympatico, Hotmail, or any number of other places that have farms of SMTP servers, where your message isn't guaranteed to be resent from the same IP?
This also requires users to install software to use effectively, and features CAPTCHAs which are a usability nightmare and not nearly as impregnable as the author thinks.
All that effort instead of just adding a TXT record to their domains.
The author may be an anti-spam kook but the paper is so badly written I can't be bothered identifying which.
I'm surprised I don't see it.
...but this had to be posted.
Your post advocates a
(X) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
( ) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
(X) It will stop spam for two weeks and then we'll be stuck with it
( ) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
( ) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
(X) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
(X) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
(X) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
(X) Blacklists suck
(X) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
( ) Sending email should be free
(X) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
(X) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your house down!
Then he talks about having people install software:
Yeah, installing new software is a great solution.
The proposed scheme ignores one thing: the majority of bounce messages today are false bounces caused by spammer joe-jobs, therefore they themselves get flagged as spam and deleted/ignored. In addition, it also increases the annoyance of greylist authentication schemes, since a spammer forging my address in the From field will cause every host participating in this scheme to send me a verification e-mail for a message I didn't send which I'll have to deal with. The proposed scheme makes a very fundamental mistake: assuming that you can trust the sender's address in a message to be the true sender's address. You can do that only after you've determined the message is authentic and not spam, at which point you don't need this scheme anymore.
As soon as I saw a spam Item, I just skipped forward to this good old reliable post.
Funny because its true !
I really love this one...
music lover since 1969
Which is kind of like greylisting. The FIRST problem is that the spammers have adapted to this and retry.
The SECOND problem with this is he's saying:
Huh? So this is also about SENDING email?
And it doesn't address the issue of "fast flux" where the domains are "legit" in that they exist and point to the IP address of the sending machine
So he's talking about "bouncing" messages
No fucking way is this going to work.
Put this into use and it'll never work. I didn't read the entire paper, but after looking over the pretty pictures it looks like the sending party has to resend the message? That will only happen 50% of the time. I do support at a university and the types of calls I get lead me to believe the average user (not average linux geek) would be totally and completely confused and would call the helpdesk every time they got one of these replies.
Is MS windows boxes that are comprised and doing this - you can see this where the spam mails get 'chinese whispered from one box to another and end up incoherent (to say the least).
Any ISP should/could get suspicious of thousands of mails sent from one 'home user' source at anytime. But when you have thousands of 'users' doing the same thing, it gets lost in the noise.
One simple solution is:
if account == home user & running MS
if mails sent > 10 per minute
block it
fi
fi
etc.
Very easy.
"SPF is sharply limited by incomplete domain participation"
That's not a big problem. 99% of non-participating domains fit in default SPF record "a/24 mx/24 ptr -all", we use it in qmail for few years. Together with Spamassassin it results in 99,8% antispam accuracy (warning: one big exception is yahoo.com, you should use domainkeys or add ptr:yahoo.com to default spf rule)
A Google search revealed this intelligent discussion of the scheme.
http://www1.ietf.org/mail-archive/web/asrg/current/msg12403.html
Whats with the "Office Live" link at the bottom of the article?!
Suggests a Microsoft-owned site.
*lead me to believe the average user (not average linux geek) would be totally and completely confused and would call the help desk every time they got one of these replies.* I would have to agree with Anonymous Coward to say that as a self-declared "average user" I would be completely confused. And aren't the average users who we should be targeting anti-spam technology to? I mean, your average computer genius can figure out how to get rid of spam on their own I would think, making the "user friendly" aspect of any anti-spam technology a key factor if the object is to get rid of spam for the masses!
Spammers from forging the valid domain that the source IP would be originating if it were legitimate mail? Now we'd have to verify not just domains but individual addresses in the database, and that would simply cause the spammers to turn around and use the compromised user's own address (at which point, the blowback will hopefully indicate something is wrong at the least)
I have said before, and am saying again, we need an economic solution to an economic problem.
The spammers continue to send out spam becuase they make money at it. If we can make it less profitable for them, then they'll stop doing it. However, the spammers have so many partners in crime that we can't easily hinder them until at least one of their cohorts will agree to work on the right side of the law.
The way I see it, we still should be going after the registrars. A good chunk of the spam comes from a small portion of the spammers (and their gangs). We know who these people are, and so do the registrars. But currently, we just play the same game ad naseum:
And the game repeats. And the only party who can easily be contacted about it is the registrar - who will of course deny all wrong doing, or just hide behind the security of whatever communist country they reside in this week.
If registration was instead restricted to actual respectable registrars (at least for common TLDs) then a lot of this could be short-circuited.
Instead, we allow registrars who don't speak English (or at least claim to not speak English when you contact them) to sell
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
Am I alone in having read that as "Novell Method for Universal EMail Authentication"? Might have been more interesting.
As I stood at a kiosk at a trade show this week, and waded through my spam-filled email on a few services (work email, hotmail, and gmail), the young woman at the kiosk next to me accessed her myspace and facebook accounts and responded to friends only.
She turned and said that only old people use email. And she was a VENDOR at the conference.... Things that make you go hmmmmmmmm......
Many if not most mail servers now drop messages to invalid recipients at SMTP time and don't send bounces any more. I've had to implement this on every mail server I set up to keep the mail queues from backing up to several thousand messages to invalid "bounce" addresses.
It would work if bounce messages were still sent.
A title like, "novel method to rapidly generate a near-perfect global SPF database" bothers me because there are too many "brag words": "novel", "rapidly", and "near-perfect". Horn tooters are usually crackpots and cons.
As far as spam solutions, I think some kind of purchased "e-stamp" is the way to go. Until zombie owners get hit in the pocketbook, nobody will clean up the crap.
Table-ized A.I.
SPF causes MailserverB look up DNS data for the email domain for MailserverA, and compare it's SPF published IP addresses with the IP address of the incoming email connection from SpammerS. If the two don't match, then MailserverB hangs up on SpammerS with a 566 eat-shit-and-die error code.
That's all SPF does: eliminate impersonation.
For that, it's a great idea.
If you think that SPF is going to eliminate all spam, then you have misplaced hopes. Don't throw out SPF just because it is a piece of the solution instead of the whole solution.
The problem you describe is solved with SURBLs.
IMO, people should use both.
"The most sensible request of government we make is not, "Do something!" But "Quit it!"
May be because my slashdot nick sounds like my real name.
Heroes die once, cowards live longer.
This is just an additional layer over automatic whitelisting of addresses using tagged responses.
Some years ago I set up for my family a pretty simple set of procmail rules and scripts that bounced messages that hadn't otherwise been classified as spam or been whitelisted with requests that they be resent with a certain keyword in the subject line. For example:
"Hello, you just sent me the following message. Could you send me the message again with the word 'leisure' in the subject line? You can reply to this message if you like, just be sure to add 'leisure' to the subject line."
Over a period of several years the only spam that's gotten through this has been from a 419er.
The advantage of a subject line token like this is that you can tell people the token to use, or put the token in the subject line when you send the message so it's usually there when the recipient replies.
Whether you take the resulting message and whitelist the sender address, or some other information in the header that you consider reasonable, that's up to you. It's not really the same thing as the SPF database, though, even if you choose to make the same kind of information the key you use for whitelisting. The point of SPF is that it's supposed to be authoritative for the organizations involved, and doesn't include things like "I sent something with my work address from Earthlink and now you're accepting mail from my work domain through Earthlink's servers".
And using this to whitelist the sender rather than their whole domain gives you a lot finer control.
This is clearly Challenge/Response with automated whitelisting. The following Wikipedia entry addresses every facet of this system:
http://en.wikipedia.org/wiki/Challenge-response_spam_filteringWe implemented greylisting. It is the answer. Tens of thousands of emails per day are bounced by our servers away into oblivion. Server CPU is neglible. Let's not reinvent the wheel. Why don't we just build greylisting right into the SMTP protocol? Sure some spammers will resend, but at what cost. How many _can't_ resend?
Also I believe SMTP over TLS is the second part of the answer to the spam problem. It adds one more cost to the sender i.e. exchanging certificates and encrypting email. If you send out 2 million emails and have to exchange 1.5 million certificates then encrypt the email with the certificate you downloaded, well, I think you see the problem for the renegade spammer whose sending email over cheap DSL/dial-up links. We have HTTPS. Why not enforce SMTPS? I believe the protocol has already bveen established.
Why not just cancel the sending of any e-mail that would cause a bounce? If someone is attempting to send an e-mail to addresses A, B, C, and D, check each address to see if a message would bounce, and if even one (say, C) sends a bounce reply, don't send the e-mail.
The only legitimate use I could see being interrupted is mailing lists, if someone's e-mail address is suddenly terminated, without them first leaving the mailing list. But surely, it shouldn't be that much of an issue if each message of the mailing list is opt-in from a link in the previous message, unless complete an unexpected e-mail address termination is far more common than I assume.
I read something a few years ago regarding a potential solution for catching spammers. It was based on the presumption that because spammers send millions, if not 100s of millions of messages at a time, that it would be computationally impossible for them to calculate the results of a math problem and then checksum the result/sign the result against the message and then send it and the problem as part of the header. Or something to that effect. The assumption was that the home or casual user send so little mail that it wouldn't introduce a delay into their mail sending flow to perform this operation. So when you receive the message, you then check the result sent against the result you calculated and if they match, give it a better score.
Of course, I don't doubt that I missed something in my recounting of it but it sounds on the surface like a better idea than the article describes.
Democrats and Republicans are like AIDS and Cancer, I want neither!
So? They don't care. They have, effectively, limitless bandwidth and limitless processor power.
Greylisting WAS effective
No. It fails when they implement (as they have) a process to resend any temp rejections after X minutes.
Greylisting had THREE features:
#1. It could temp reject spam and if the spammer never tried again
#2. It could temp reject spam and if the spammer randomized the "From:" username/domain
#3. It could temp reject spam and if the IP addresses was listed in a blacklist within the temp reject time frame
Now all that is left is #3. It costs the spammers NOTHING to upgrade the zombies. And if they get the spam through, the spammer wins.
Now, the zombie can appear MORE legit than a lot of the real mail servers out there.
(X) and I don't trust ideas from an idiot who can't put up simple text web page with a few gifs that will display properly in browsers that have javascript disabled.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
I've been using greylisting. For me, it really hasn't become less effective, but I have noticed that the mix of the spam has changed dramastically.
I'm getting ready to switch to two methods.
First, on one specific account that has become inundated with spam (probably because it is on just about every web page with registered IANA port assignments), I'm in the process of switching it over to the point where it will only accept unencrypted e-mail from a select list of whitelisted sources. If someone is not on that list of whitelisted sources, they are going to have to encrypt the e-mail using my public PGP key for the e-mail to be delivered.
Second, our mail server has something in the range of 100 to 200 users. I am generated thousands of additional e-mail addresses and aliasing them on the server to a single account. Those thousands of new e-mail addresses, initially 8,192 e-mail addresses, will be listed on various web pages for the spammers to harvest.
As e-mail starts to be delivered to those addresses, I will opt-out of all the e-mail so that they know the e-mail address is real and gets read. Once the spam reaches a certain level, I will then start blacklisting every incoming server delivering e-mail to one of those 8,192 addresses.
The length of time on the blacklist will vary. No IP address will be removed until a reverse DNS lookup for it exists.
If the reverse DNS lookup gives any idea that it may be a dialup, dhcp, or anything else that makes it look like it is probably a home computer (e.g. dialup-10-1-1-99.example.com), the IP address will be blocked for a month or more.
If the reverse DNS indicates that it is an smtp server (e.g. mta09.example.com), it will be blacklisted for maybe 24 or 48 hours.
Anything else will be blacklisted for one to two weeks. If additional e-mails arrive from a blacklisted IP address, the clock will start over.
I figure that with 8,192 spamtrap addresses and 100-200 user addresses, most spam zombies will be far more likely to hit the spamtrap addresses first where they may be automagically blacklisted.
Hashcash isn't a viable solution once you have a couple of mailing lists, it'd hit legitimate senders harder than the botnet operators. Our current mail servers are a mix of dual 2.4GHz Xeons and older 1.2GHz PIII machines. Planned upgrades will see us cutting costs by consolidating servers on ESX. Meanwhile even todays lowend desktop machines are able to match our servers for compute and botnet operators have access to plenty of them.
"Spammers will always look for a way to pump out their spam": So all one needs to do is prevent the pumping. I do that by slowing my SMTP receive process down deliberately. It sleeps 5 seconds before sending a banner in response to a new connection request, then it sleeps 1 second every step of the way through the SMTP protocol state machine. Most spammers give up in disgust and go away. The little bit that is left is easy to filter and legitimate mail is only delayed by about 10 seconds, which is really nothing.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
Instead of greylisting, I have experimented with a system where my SMTP receiver would send '450 try again later' messages randomly to incoming connection attempts. It actually works. Since the vast majority of incoming mail is spam, a 50% rejection rate reduces spam by almost 50% since most spammers will not retry, while legitimate mailers will.
In the end, I settled for an even simpler approach, where I just throttle the receiver dramatically, so that it takes about 10 seconds to receive a message. Most spammers don't like slow receivers and go away. Real mailers don't have a problem with it. It reduces incoming spam by more than 90%. So this simple change keeps my mail server very well rested from the nice long sleeps...
Excuse me, but please get off my Pennisetum Clandestinum, eh!
Thank you.
Can anyone say, "Single point of failure, or perhaps - "How can I segment a market to 'make money quick!'"
If you have a spammer, who sends email with a fake reply-to address, then countering this should be straightforward.
Let's say there's a system where the servers put emails in storage, and communicate to decide if the recipient should receive a message.
When an ISP's server receives an email, it should generate a hash from the email, and send the first half to the server who sent the original.
If there's no response at the other end, then the spam email is never received by the recipient. If there is a response, and the server doesn't know the second half of the hash even with the time and date of the email, then nothing happens.
Only when the server sends the second half of the hash, does the recipient receive the message.
Now this system would increase net traffic, and rely on servers being upgraded. A transitional system can be used, where eventually those who want to can choose to receive only emails which support this system.
If there are flaws in this, or was attempted in the past, or anything else on this subject, I'd love to know.
I have chosen to respond to this comment as it was moderated a 5, thus lending legitimacy to the criticism. Not all of the comments moderated at 5 (such as the form responses) are worthy of a reply so I will not respond to all of them.
"So what happens when you receive an email from a big site like Sympatico, Hotmail, or any number of other places that have farms of SMTP servers, where your message isn't guaranteed to be resent from the same IP?"
Section 7.1 point #1 states that major domains and domains the publish SPF records will not be entered into the Receiver Generated SPF database. You cite the example of Sympatico and Hotmail, but email from these domains is already authenticated so why try to repeat the authentication? RIA only bothers to authenticate non-authenticated email. Major domains that have large server farms already usually authenticate their email.
As for unauthenticated domains it is possible that sometimes a bounce will be resent from a different server than the one that originally sent it. For the most part this just means that a couple of more bounces will need to be resent before every MTA of the domain is listed in the Receiver Generated SPF database.
A few oddball domains may persistently send their email via one server and resend their bounces via another in such a way that a server may never appear in a resent bounce; Section 4.3 details how inevitably these servers will be included in the database.
"This also requires users to install software to use effectively"
It absolutely does not "require" senders to install software. See the last bullet point in section 11.1
"and features CAPTCHAs which are a usability nightmare and not nearly as impregnable as the author thinks."
The CAPTCHA is not used to for authentication, it only is used to challenge the small residual fraction of authenticated email that it classified as 'unsure'. Use this system without the CAPTCHA if you simply want universal authentication.
Section 6.2 and 6.3 answer your concerns regarding the use of the CAPTCHA and references are cited.
"All that effort instead of just adding a TXT record to their domains."
Domain administrators SHOULD publish SPF records, but perfect compliance will never happen. See section 2.1
Sincerely,
Michael G. Kaplan
This scheme seems every bit as awful as those "Hi! Before anyone e-mails me the first time, I make them go through these steps" filters
- It causes backscatter
- It doesn't work with mail from mailing lists
- It's not accessible
Additionally:
- It doesn't work well with sites that have many MTAs (requires one bounce/CAPTCHA per MTA)
- It doesn't work well with an SMTP server that sends for many domains (requires one bounce per MTA per outgoing domain)
- It merely confirms that "this server can send mail for domain X". If you've got a spambot and can determine your user's domain name (e.g. comcast.com), this won't stop anything at all.
The author brushes off concerns with bold (well, italic now) statements like:
Resend software is a simple onetime update for webmail systems, email clients, and local mail servers...Universal Distribution of Auto-Resend Software is a Surprisingly Simple Thing to Achieve
Hah! A simple one-time update for all servers and clients everywhere! Granted, RIA doesn't depend on that update happening, but it's clear even the author thinks it'd be a pain without auto-resend.
There is little disincentive to implement Auto-Resend software as it is a one-time upgrade that remains dormant until needed.
There is a huge disincentive; looking up a user's mailbox to see if he did, indeed, send the message you claim he sent is a ridiculously expensive operation, if it's even possible at the server level. It could also lead to a privacy leak if done wrong; people could forge RIA bounces to probe outgoing mail flows.
At best, it potentially doubles the volume of outgoing mail, which deepens queues, requires more disk space, etc. etc.
I'm guessing the author is unfamiliar with high-volume mail sites - the very ones he wants to implement this scheme first.
Suspicious Domains Will Be Neutralized By CAPTCHA Encoded Sub-addresses
Great. So now e-mail that's "suspicious" requires intervention from a sighted human, and all his "auto-resend" silver bullets are used up. He does imagine yet another client change that will "nicely reformat" a CAPTCHA. Yeah, right. Oh, and now he's e-mailing me graphics on my Blackberry.
In general, he seems to imagine that he personally runs the One True RIA list, and we all trust his determinations of what is and isn't "suspicious", with reputation scores, rate limiting, etc. That is, of course, ridiculous; the original MAPS RBL has splintered and grown to the point where there are over 200 DNSBLs available.
He talks about automatically e-mailing users that he has "detected" are running zombies. Right, because that's a good idea and isn't spam.
Domains commonly associated with phishing (e.g. Paypal.com, Citibank.com)
As if there's a way to create a comprehensive, or even useful, list of "domains commonly associated with phishing".
with the passage of time it will become difficult for spammers to purport that all of their spam is sent via increasingly obsolete or esoteric brands of software.
Of course it won't. I still get spam from "The Bat!". Before, he forgot about the big guys; now he's forgetting about the long tail. Spammers can make up any number of X-Mailer names.
I have chosen to respond to this comment as it was moderated a 5, thus lending legitimacy to the criticism. Not all of the comments moderated at 5 (such as the form responses) are worthy of a reply so I will not respond to all of them.
"The proposed scheme ignores one thing: the majority of bounce messages today are false bounces caused by spammer joe-jobs, therefore they themselves get flagged as spam and deleted/ignored."
What? Are you saying that if you email someone and 2 minutes later a bounce returns from that same person that your email system will junk the bounce? Vacation messages and delivery failure notifications issued in response to your email never reach your inbox? If this is uniquely happening to you then your email system is defective, the rest of the world doesn't have a problem receiving legitimate bounces (Ironport's bounce study cited in my article does not mention this as a problem).
"In addition, it also increases the annoyance of greylist authentication schemes, since a spammer forging my address in the From field will cause every host participating in this scheme to send me a verification e-mail for a message I didn't send which I'll have to deal with."
Greylist doesn't have anything to do with RIA. I am unable to respond to whatever misconception about my system you have.
If you are trying to make some kind of comment about the problem of erroneous bounces then you should review section 9 - it is dealt with extensively.
"The proposed scheme makes a very fundamental mistake: assuming that you can trust the sender's address in a message to be the true sender's address."
What? The whole basis of the paper is that the sender's address is not to be trusted; this scheme solves that exact problem in an almost completely non-disruptive manner. I'm not sure why this comment was moderated a 5.
Sincerely,
Michael G. Kaplan
Others have already explained at length how this is yet another
FUSSP -- and they're quite correct. It appears to be the product
of the same confusion that gave us SPF, Domain Keys, et.al.:
that is, mistaking the forgery problem for the spam problem.
Yes, they're related; yes; they're both abusive; and yes, they're
often seen together; but they are NOT the same problem and
it's a serious, fundamental error to think they are.
At this point in time, there is no solution to the forgery
problem available, because there are (depending on whose
estimates you'd like to believe) something between 10e7
and 10e8 (or more) fully-compromised systems out there,
which are of course capable of transmitting mail using any
identity whose credentials are located on those systems.
No fix is even on the horizon for that situation.
As to the spam problem, a limited solution presents itself
via this approach: any system which emits spam is either
(a) owned by a spammer, that is, a leased server in a co-lo
or similar or (b) broken, that is, an open SMTP relay or
perhaps a system with an exploitable proxy or (c) hijacked
by a spammer, that is, effectively owned while still putatively
under the control of its "real" owner.
In all cases, such systems are de facto enemy territory,
and the appropriate course of action is to (a) identify them
and (b) deny ALL traffic from them until they're no longer
enemy territory. There is little sense in expending bandwidth,
CPU cycles, and expertise trying to work out what traffic from
them might not be spam -- even if this futile effort is
successful, it doesn't matter, because accepting traffic
from a known-hostile source is just not a good idea no
matter what might be in it. Moreover, due to failure to
maintain and monitor RFC 2821 and RFC 2142 role addresses,
refusing mail is often the ONLY way to bring the attention
of the responsible party to the situation (I'm thinking of
(b), above, here).
But back to this FUSSP: consider for a moment how this
system could be used to target attacks via (a) forgeries
(b) redirected MX records (c) fast-flux DNS (d) targeting
of blind users (which is why ANY use of captchas is
quite, quite stupid) (e) deliberately induced deadlock
(f) bogus responses to mailing list traffic and (g) some
number of other things that will probably occur to me
if I can force myself to read this poorly-written gibberish
again.
-
captchas (yeah, sure - we all LOVE jumping through loops just to send some mails)
-
requires new software on client and server (users AND mail server admins will tell you this: "I fart in your general direction! Your mother was a hamster and your father smelt of elderberries!"
:-)
-
relies on a central authority (why should all the world rely on one central system - possibly even run by Michael G. Kaplan who can't even correctly add some images to his suggestion)
-
even more bounces (sounds like greylisting on steroids with lots defective-by-design)
Well, there may be more - but i stopped reading after i found thosechallenge-response has been done before. it was broken then, and it's still broken now.
this seems to be a minor variation on the same stupid idea behind other challenge-reponse systems like TMDA - with the same problems (esp. backscatter to the forged addresses) that they all have.
the stupidity is further compounded by the author not understanding the difference between message From headers (which are just comments, not addressing information) and message envelope.
By the way, the above demonstrates the only way in which an apostrophe indicates plural number in Standard English: when referring to the plural of the character itself, such as "Dot your i's and cross your t's."
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
I don't know about the GP, but for me greylisting is very effective. I have a personal domain for my wife and myself. I have a catchall mail address.
Here are some stats for part of last week:
Start Date 23/09/07 04:02
End Date 28/09/07 17:00
5.54 days
Total spam: 4624
Spam blocked with greylisting: 4478 (96.8%)
spam via backup MX: 69 (1.5%)
spam retried (got past greylisting): 77 (1.7%)
Total through to end user: 146
Identified as spam (SpamAssassin): 123 (84.2%)
backup MX marked as spam: 50 (72.5%)
direct marked as spam: 72 (93.5%)
Total to end user not marked as spam: 23 (0.5%)
NB. Up until about a month ago, ~25% of SPAM came via my backup MX, which doesn't have greylisting. I don't know why it dropped, but I'm happy it did.
Ever stop to think
Doesn't matter which he means. Anything involving end users deciphering bounce messages is doomed to failure. I don't know how many times end users have called and asked me to explain a bounce message that I thought was very clear... like those "invalid recipient" ones that actually go on to say that the address may be invalid, and that they should re-check it.
And that's not even looking at security implications, like what happens when spammers start sending these same bounce messages, requesting users to confirm they're real, to any given sender address.
I still think the earlier suggestion by who I forget...on /.....if we set up
accounts with our isp to pay per email, then get a credit back for the amount of bandwidth we are allowed to use for the account type we have ( i set a fake one up with 100 emails per month OUT)
or just a flat fee per email...atleast we would have reports of how many emails are going out, which would then alert us, hey I dont remember sending 1 millioin emails last month...I guess I must have a virus on my computer, which then would mean you are responsible for your computer , clean it up,
we could say technically that this person is allowed a few offenses per year, but if each month is the same thing then they get stuck footing the bill....if i clean my computer, then 5 months go by, and then i get it again, the ISP should be smart enough to say , yeah probably a virus again, lets
see if he cleans it up before next month...atleast it would be a start to solving the problem of the user not being aware....and lessen the chances of people leaving their computers on all the time for no reason. This would be more for the masses then corporations though...
This technique has been around a bit. Here is my experience with it.
1. Initially it stopped a ton of emails.
2. It stopped a lot of Auto Registration Emails from sites(Which is bad). Think Forum Registrations.
3. Over time the Spam increased again. SpamBots come from authenticated servers too.
4. Get mail from legit users a lot.
Its good. Have to watch from automated devices you want. However, Whitelisting is still best.
I can program myself out of a Hello World Contest!!
and for those of us (purists) who still use mutt and read their email as text? I certainly hope that I don't get "I think this was spam, please resend to this captcha-encoded-email address to really get it through." Because then I'm usnig a graphical browser, which has more spam and security issues than my current solution.
There is an internationally accepted infrastructure for not only proving that you are a "valid" entity, but also for encryption of data transmission. It is used for HTTP, and has been adapted for other protocols as well. Why not start issuing certificates for email servers? You use existing proven technology so no need to re-invent another cement square wheel. If you don't have a valid signed certificate from a trusted certificate authority, no mail transfer. If a certificate is obtained by some spammer, or abused, put it in a revoked or blackhole certificate list. No need to waste cpu cycles scanning email for key words/phrases, etc. And now email is encrypted in transit. Some email servers already support it, why not use it? Because you can't send mail from home? Because it is sort of expensive? Because we would rather spend years and spends billions of whatever your favorite currency is arguing and proving some other method?
- It doesn't replace SMTP with some protocol nobody's using that's not really any better.
- This is especially good because the author doesn't really understand all the protocol details or the state of the art
:-) - It doesn't require everybody else to adopt it before it works - you can do it with your own email, and worst case is that you'll annoy some humans who you want to be able to send you email and won't annoy some robots that you wanted to be able to send you email. It's a lot like TMDA.
- If the major providers do adopt his proposal, the people who use his approach will annoy fewer Hotmail and Yahoo users (but who cares?), and also fewer Outlook users (i.e. people at work.)
But the proposal is seriously broken in a few waysBill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
No RIAA jokes? Hang on, I thought I was on slashdot?
Nick Waterman, Sr Tech Director, #include <stddisclaimer>
The problem with SPF and friends is that they require the recipient to implement a technical fix. I've been publishing SPF for a few years. A few weeks ago, some asshole spammer decided to spoof my domain for 24 hours; resulting in about one bounce a minute to my catch-all. No one checks SPF.
No, I will not work for your startup