FairUCE - the Smart Email Proxy 333
Jestrzcap writes "This just posted on Freshmeat: FairUCE (which stands for 'Fair use of Unsolicited Commercial Email') is an SMTP proxy, running between multiple instances of Postfix, that verifies email by attempting to verify the sender through lookups (a user customized challenge/response). It claims to be able to 'stop a vast majority of spam' without the need for content filters, and 'virtually eliminates spoofed addresses, phishing, and even many viruses with a few cached DNS look-ups and a couple of if/then statements'."
Oh crap.... (Score:5, Interesting)
forward and reverse (Score:5, Interesting)
Pyrrhic Victory? (Score:4, Interesting)
Jaysyn
Challenge Response Spam (Score:5, Interesting)
Of course if my MTA signed my messages with a random key, and the challenge message sent the key back, my MTA could filter out anything I didn't actually send. Unfortunately that requires coordination which the various email/spam task groups do not seem to be capable of.
So... (Score:3, Interesting)
And I read of a whitelist/blacklist. Does this mean the user having to manage this list? It looks like it's being done so that the user can reactively work about it though (instead of actively), maybe an email that says "You got email from xyz, Do you want this email?" Heh an email about an email, that'd be annoying.
I tried sending email using Yahoo!'s web interface with 3 addresses in the "To" field today, and when I clicked "Send" it asked me to answer a Captcha [captcha.net], interesting..
Interesting.... (Score:1, Interesting)
Naive at best (Score:4, Interesting)
2) FairUCE on recipient end bounces the mail because it can't find a relationship between the sender and the mail relay.
If the ISP blocks outbound port 25 access, you get a real catch 22. Can't use remote relay becuase of the port block. Can't use local relay because FireUCE will see that there is no relationship to the sender and block the mail.
This is an old idea. It can be implimented with procmail and a little perl. Few people do this, not for lack of tools, but simply because it is a bad idea.
What it does.... (Score:3, Interesting)
Oh, yeah, and completely stop mailing lists from being usable. That, too.
Great, freeze my server with bounce backs (Score:1, Interesting)
yet another waste of time (Score:5, Interesting)
1. Spammers make money by using a disproportionate amount of bandwidth than what they pay for. Stopping spam from entering peoples' inboxes is less than half the problem. 70% or more of all SMTP traffic is UCE and everyone pays for that in higher costs and slower performance regardless of whether they have spam filters in place.
2. The majority of the anti-spam solutions (with the exception of RBLs) including the one related to this article, require extra time, bandwidth and resources on the part of innocent networks to deal with the spam problem. This is a step backwards.
If you want to stop spammers you have to stop them from stealing bandwidth. To date, the ONLY effective solution thus far has been relay blacklisting. This has several added benefits including: stopping propagating of worms/viruses, and forcing ISPs to police the illegal activities of their users and shut down nodes which are spamming through their network.
As an ISP, I have no interest in yet another costly anti-spam solution that I have to install that doesn't address the larger issue of the tons of bandwidth spammers waste on my network and every one in between. This system wastes even more resources by attempting to verify the source of every e-mail in an even more detailed manner than before, so the end result is: more computing resources needed, more bandwidth needed and slower mail service.
No thanks.
I'll patiently wait until the *inevitable* SMTP whitelist scheme that is the only true solution to stopping spam (unless the authorities decide to actually start prosecuting spammers for their crimes).
Re:yet another waste of time (Score:3, Interesting)
Re:Here we go again (Score:3, Interesting)
you think that's air you're breathing?
Re:Challenge Response Spam (Score:5, Interesting)
So, I'd disagree with your conclusion that blacklisting doesn't work; if a spammer can use one of your IP addresses to spam, then you need to fix up your system to be more secure. A quick browse of mail logs will show any unexpected outgoing e-mail, and you can always feed your mailserver IP to spews.org and see if they list you (they're one of the most aggressive listing places).
If it's not coming from one of your IP addresses, then it doesn't affect mail sent from your domain, only from the spammer's IP addresses. Hence there is no fallout on you unless I use an aggressive list like SPEWS, and you are being blocked because your ISP hosts spammers himself.
Re:forward and reverse (Score:2, Interesting)
They can't in many cases - I work at company that has several website that send reminder emails for different free services. There are 8 different domain names that share 5 machines.
Each machine in the load balanced group of 5 can send out emails for any of the services.
If you have a bunch of services, cnamed to IP's the reverse lookup cannot guess which of the cnames you want to have returned to make you feel good about the fact that these are the same machines/owners/domains/groups/people.
A good example might be someone like friendfinder.com, they have "adultfriendfinder.com", alt.com and bigchurch.com they serve 10's of millions of hits per day to their various sites send millions of emails per month (at least). If their load balanced machines have multiple cnames/ips etc. people might find that their squeaky clean blue state church singles site emails are coming from a machine that has a reverse lookup of adultfriendfinder.com or worse alt.com - OMG!
Real Life Example
My aff emails come from ef154.friendfinderinc.com but the IP (216.34.38.114) reverses to e114.friendfinder.com. Again OMG, that isn't the same domain as the From address claims - team@adultfriendfinder.com - so they are lieing! It is a forgery! and the machine is lieing about who it really is, is it ef154.friendfinderinc.com or e114.friendfinder.com. ?
Three different domains for the From, HELO, and reverse lookup and yet as a human I can see they are legit and related - but a program would not be able to discern that. Reverse lookups muddy the waters more often than not.
Re:forward and reverse (Score:3, Interesting)
Re:forward and reverse (Score:3, Interesting)
Re:Challenge/Block (Score:3, Interesting)
One easy way to set that up is to use subdomains that don't even resolve after a certain point. So you might have me@2004.example.com good for only three more weeks, or me@amazon.example.com good for as long as Amazon (or your "healthy" girlfriend) doesn't sell you out. You can get tricky, of course, and use subdomains that are not so easily subject to a dictionary attack or guessing.
This is exactly the same solution as I use, and I've found it very effective. I've written some stuff about it here - Mitigating spam [whirlpool.net.au].
Did we come up with it independently ? The first "thought" that triggered me thinking about it was when I moved house, and wanted to make sure that emails to my domain, while unavailable, were bounced immediately, rather than having the sending SMTP server keep attempting for up to 5 days (or what ever it was configured to be). My solution was to set the MX record for my domain to point to an A record that resolved to 127.0.0.1. That lead to the idea of creating "sacrificial subdomains", and then abandoning when I get too much spam by changing the MX record value.
Re:"With over 150 public blocklists out there" (Score:2, Interesting)
Some blacklists list known spammer domains, but these are fairly well confirmed via the ownership of the domain. Many lists skip the actual 'sending spam' part and just list all domains owned by certain spammers.
What you are describing sounds like what people who have IPs near spammers go through. Can you point to one of these hundreds of domain blocklists that has listed you incorrect at some point?
The only thing I can think of is that you're running an affiliate system and can't keep your affiliates under control.
Re:Anobody notice the BASIC reference (Score:1, Interesting)
Oh? Then why does garbage collection *still* interact very badly with swapping?
When the active thread needs to access a piece of memory that has been swapped to disk, the thread will block. If the machine is otherwise idle, the garbage collector will run. The garbage collector starts bringing in several pages of useless memory, forcing out pages from the active set. The result: background garbage collection slows down the process by a factor of ten (experimental results).
Re:Challenge/Block (Score:3, Interesting)
Don't use 127.0.0.1. Use 127.29.13.4, or some equally random address in the 127/8 loopback.
Another alternative, depending on how you want the failed delivery to fail, is to use an IP address within one of the reserved IANA ranges [iana.org]. Bogon lists on the default free routers usually silently drop packets to these addresses. Unless spammers are doctoring the TCP/IP stack in their hosts, silent drops of TCP SYNs usually take around three minutes before the application is notified of a failure to connect. One address I use is 1.1.1.1/32.
Spamming software is almost always poorly written. They'll filter out 127.0.0.1, but aren't smart enough to do anything else. Those bastards will probably try to deliver mail to themselves for a week.
Which type of address you select, bogon (eg 1.1.1.1/32) or loopback depends a bit on whether you want to tie up their delivery resources immediately (1.1.1.1/32) or over a few days (loopback).
One of the issues with loopback though is that the delivery failure depends on whether they are running an MTA on 127.0.0.1. If not, they'll usually get immediate "connection failed" messages, although if they are firewalling the local host, the effect will be the same as using a bogon address.
If they are running an MTA on local host, then they'll likely get "bounce messages" with a "not a relay" message (or what ever the exact status is, I'm rusty on the exact SMTP messages).
Of course, another alternative is to delete the subdomain, meaning that the MX record lookup will fail.
Still, I prefer one of the "bad MX" address methods - there is a chance it will waste some of the resources of the spammers, increasing their costs.
Another idea, as part of this, is to create a bogus web page that contains a whole stack of these "sacrificial subdomain" email addresses. If spammers are using web page robots to collect addresses, they'll end up collecting a lot of them. That might frustrate them, such that they'll delete all email addresses for the particular domain, which, of course, would include any of your legitimate ones. You can have a look at mine here [nosense.org], which contains 7500 bogus addresses, covering a range of "sacrificial subdomain"s. I used 30 bogus domains, and a list of male and female names from files listed in Kevin Mitnick's book, "The Art of Deception". Using the full 30 domains, and the full male and female name list, I ended up with a 22 MB html file, with 256 000 or so addresses. I figured that was a bit too many (!) and cut it back. That being said, if my "sending" bandwidth was free or near free, it might be worth making the page around the 5 to 10 MBs in size, to also tie up spammer resources while they are running their address collecting robot.
None of these techniques are perfect, then again, if there is anything realatively simple you can do to frustrate the spammers, it is worth it. They might give up if their costs become too high.