Slashdot Mirror
FairUCE - the Smart Email Proxy
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'."
I've already had problems getting email from my government coworkers with spam validators like this. The military really doesn't like broadcasting who their email servers are... So they regularly get sent to Junk Mail.
If MTA's on the Internet required the forward and reverse DNS lookups to match ~70% of spam (and viruses) would disappear. This requires ISP's to correcty configure their DNS, which unfortunately doesn't happen because people are lazy.
Doesn't this just create more traffic?
Jaysyn
There is a war going on for your mind.
One problem with challenge response is that Spammers not only send me spam, but send spam purportedly sent by me. I regularly get error messages about mail that could not be delivered. Now I'll get loads of challenge messages instead.
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.
Guess I'm asking at the wrong place, but does this mean if I send email using my uni's SMTP server with my Yahoo! E-mail address in the "from" field, I will receive a challenge? A challenge being an email to the sender's address so they know the address is active, I'm guessing..
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, interesting..
What time is it/will be over there? Check with my iPhone app!
...that this is being pushed by a little fly-by-night company in Armonk.
1) Mobile user sets up notebook at new location and sends mail via the local mail relay.
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.
). 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, yeah, and completely stop mailing lists from being usable. That, too.
My server receives over 140,000 spam messages a day over 300 domains. So, will this system be running this process several times a second, then sending undeliverable bounce back messages just as often? Great, even more server problems, brilliant idea guys. My favorite solution is a client side filter. Thunderbird is amazing. I'd rather see the world go that way.
Have we not established a few basic tenets of the spamademic?
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).
what makes you think this hasn't happened already?
you think that's air you're breathing?
Liberal (adj.): Free from bigotry; open to progress; tolerant of others.
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.
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.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
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.
If corporations are people, aren't stockholders guilty of slavery?
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).
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. 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, 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.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf