Die spam die (but only on *nix ?)

I came across this spam bouncing software, which looks to be that one extra step beyond mailwasher that makes life complete. But it's not available for M$ yet - anyone seen an equivalent that is Windows happy ? (Though it may be better to see if the mailwasher guys can add this to their stuff).

Regards

Mark

From www.tmda.net ...

Messages from unknown senders are held in a pending queue until they respond to a one-time confirmation request sent by TMDA. Once they respond to the confirmation, their original message is deemed legitimate and is delivered to you.

This is a good feature, and it will prevent spam, but it requires intervention on the part of the sender. My ISP tried this out for a while and it was a rousing failure. Many legitimate senders were unable to respond to the message correctly, and got blacklisted because of it. It also has the disadvantage of needing to store all messages (including spam) on the receiving server.

My ISP has switched to a similar system which works on the same principle, but doesn't require user intervention and doesn't require storing the spam in a temporary file. It still tends to blacklist legitimate senders once in a while (a big pain in the butt) but not nearly as often as the response-required system described above. And it does work at preventing spam 100 percent. I never get spam at my oronet address.

Here's how it works without user intervention:

- Root premise: Most spammers fake their return addresses as one of the tricks to disguise where the message originated.

- When a mail comes into my ISP's server, its return address is checked against the existing whitelist and blacklist. If it's on the whitelist, it gets in. If it's on the blacklist, it's bounced.

- If it's not on either the whitelist or the blacklist (i.e., it's a new address), the mail server "soft rejects" the message. This is not a bounce, it's essentially a message to the sending mail server to "try again in a few minutes".

- My ISP sends a test message (within which it states that no reply is needed) to the return address. The only purpose of this test message is to see if the return address bounces.

- If the return address bounces, it goes on the blacklist.

- If the return address does not bounce (within a few minutes), it goes on the whitelist.

- When the sender's mail server re-sends the previously-soft-rejected message, assuming the test message hadn't bounced, since it's now on the whitelist, it gets in and now all messages from that address are whitelisted.

This is neat because it does the same thing that TDMA software does, but without the need for digital signatures, or for user intervention by the sender. And no server storage space is wasted holding spam messages in a queue (the sending server gets to do that).

(Though it may be better to see if the mailwasher guys can add this to their stuff).

If I understand correctly, Mailwasher is a client-side tool. I think the TDMA system and the system that my ISP use are server-side, they run on the mail server.

Hmmm... I like the idea, but won't spammers simply start using real addresses that just point to /dev/null instead of a legit account? This would add them to your whitelist. I rather like SpamAssassin's heuristics (sp?). We still get a few spam messages, but my users know to forward them to me and I just add them to my blacklist, never to be heard from again. In 178,000 emails filtered by SpamAssassin, only 2 have been tagged as spam when they weren't, and these were horribly written emails, with things like broken html in the message body, everything in all caps, and weird fonts.

won't spammers simply start using real addresses that just point to /dev/null instead of a legit account?

Yes, to a point. The premise behind these systems is to make it more expensive (and hence less economic) to send spam. Also, as soon as the spammer has to have an address to which mails can be sent (even if they are dropped on the floor), they add a degree of traceability.

The TMDA premise is that it requires a real account (and could require a real person, with a suitable challenge-response mechanism), which changes the economics still further.

Do you know what system your ISP is using, or have the rolled their own ?

Does this include some kind of authentication mechanism? That is, is there anything that stops them 'stealing' and forging my (or your) address?

I like the idea, but won't spammers simply start using real addresses that just point to /dev/null instead of a legit account?

In addition to the reason Roger cited, there is another reason they don't usually do this.

Known spammers who don't disguise their return address are already on existing publicly available blacklists. My ISP uses these blacklists as the second half of their two-pronged attack against spam. I neglected to mention this aspect of the system in my original post.

Do you know what system your ISP is using, or have the rolled their own ?

Good question. I wouldn't put it past Scott to have coded this up himself, but I think it was an existing system that he modified. I don't know the name of it.

Does this include some kind of authentication mechanism? That is, is there anything that stops them 'stealing' and forging my (or your) address?

I think so, but I'm not certain. So far, I haven't seen this be a problem, so I think there's something in there that helps prevent this. Dunno what that would be, exactly, though. It does a lot of careful checking of the mail headers and the sending server, I just don't know exactly what.

Ahh, good to hear. Also, in response to them hijacking your email address, that adds a whole new level of illegality to their practice. It's shady as it is, that would certainly push it into the illegal realm.

That is, is there anything that stops them 'stealing' and forging my (or your) address?

Not really. As Tony says, there's a certain amount of double-checking that you can do to ensure that the envelope and headers match, and that the mail came from a server responsible for the relevant domain. This last check is not recommended, however.

If you want to make sure that an email actually came from the person it claims to, then you'll need to rely on digital signatures. PGP (or GPG) will do this for people. There's nothing in the SMTP protocol that will authenticate servers against each other.

You could (fairly easily) modify TMDA (for example) to require that emails be signed by the sender. It would be a PITA for people who didn't understand this stuff.