[BTP]

A long time ago (1995) I had registered my own domain and I had my own personal email. Life was good. 5 years passed when a downloaded my email from my domain registration. (My fault; I should have known better at the time than to use my personal email address in there)

I used to have my sound on for email, and even when I wasn't at my desk I could hear when mail arrived. Soon after my email was comprimised, I soon began to receive spam. It grew at an exponential rate, from 1 a month, then 1 a day to the current 20-50 a day. It sounded like a videogame.

My sound is still off, I recently switched to using Mail from Entourage. Mail is nothing short of brilliant. It keeps spam out of my mailbox with next to no false positives (none of the false positives have been personal email). Still, I am still downloading a LOT of spam. For a while, my sys admin had filters that slowed spam, even though I asked them to use Spambouncer. (Someone here recommended it) Life was tolerable, but I still had a lot of spam in my inbox.

Recently the box was totally rebuilt (long story for another forum), there is no more admin, just me. If I hadn't been learning so much *nix from OS X, I doubt I would have learned the little I know.

I managed to install Spambouncer and life is great. This thing is awesome! It kills spam DEAD. It has had 0 false postitives and only 2 have slipped through (Mail got those). Not bad at all!

I was not comfortable about doing this at all, but now that I am done, looking back it all makes perfect sense. Funny that one of the better solutions to spam is only on *nix based machines.

My biggest problem configuring it was my lack of basic understanding. I knew what the instructions wanted me to do, and I could do them, but there were simple things not said that I missed. Some trial and error, but I made it.

I mess around in the terminal on OS X, but I always have the GUI in most cases, the Linux box, I don't. But Linux has given me something Windows and the Mac OS** haven't, the ability to take back my inbox.

I now don't worry about having my sound on, I don't worry about dialing up with my wireless phone and having to download tons of spam and the myriad of other pleasant thoughts that not having to deal with spam brings. I may even turn HTML rendering back on! Ok, probably not.

Thanks for reading this ramble, but I am very happy right now with Linux, Spambouncer and having my inbox back. Maybe this will be temporary, but it is nice to have it back. Any other happy Spambouncer users out there?

** Excluding having OS X Server and a machine to run it on. Spambouncer DOES run on OS X.

[[APi]TheMan]

Originally posted by BTP:
long rant <snip>

I feel the same way. I used to leave Mail.app open and just see the dock icon change when I received mail, but now I get so much spam to my .Mac address that I don't like to leave Mail.app open, because I usually have 4 or 5 e-mails... spam

Do you have to run your own mail server (sendmail) to use Spambouncer, or could I use it with my .Mac account?

[BTP]

Rant?

You have to have a shell account on your email server. Sorry.

I thankfully don't get any spam (crossing fingers) to my .Mac, but I read in the forums that Apple filters it.

I also used a despammed.com email addresses that forwards to my email address and they are free.

For right now, I am in heaven. Only 3 spams have slipped through and many dozens have been blocked. No false positives so far.

If you have your own domain, you can move it to somewhere like pair.com, who will give you shell access for cheap. It used to be $6 or $9, something like that.

I'll be willing to share what I know about how to do it, though I suspect that there are many people in the Unix Forum that know FAR more than me.

You can run Spambouncer with qmail and sendmail, but just today I was reading someones opinion that Postfix is even better, as it uses true server bounces, rather than the bounces after the spam has been recieved. I was mistaken that Spambouncer bounced to the actual source, not the forged FROM address.

HTH.

[Arkham_c]

I use spambayes (spambayes.sourceforge.net). It's phenominal. I wrote an experimental Mac GUI for it, but I haven't released it just yet.

[Rainy Day]

Originally posted by [APi]TheMan :
Do you have to run your own mail server (sendmail) to use Spambouncer, or could I use it with my .Mac account?

You do not actually need a shell account to run SpamBouncer. All that is required for SpamBouncer is that procmail is available as your MDA (Mail Delivery Agent) and that you have a way to change procmail's configuration file (e.g. FTP). procmail is available on a number of platforms, but is most commonly found on UNIX boxes and is typically associated with a shell account.

If, for example, you have a domain name and you host it with an IHP (InterNet Hosting Provider) and they have procmail available as an MDA but they do not allow you shell access (perhaps for security reasons), but you have FTP or SFTP access (which is likely so you can upload your web site), then you probably can use SpamBouncer (provided they allow you access to your procmail configuration file, which is likely since procmail isn't of much use if you don't). SpamBouncer is nothing more than a fancy procmail recipe.

I doubt that SpamBouncer is available under .Mac, however.

Now you can, if you like, run SpamBouncer on your Mac under MacOS X. In this scenario you'll still be downloading all the SPAM to your Mac, but SpamBouncer will filter it before it's delivered to Mail.app. Not so good if you're using dial-up, but not a bad solution if you have broadband. Most effective, of course, would be if you could run SpamBouncer on your mail server, that way you won't have to download the SPAM to your Mac in the first place. It's really a question of bandwidth.

Originally posted by BTP:
You can run Spambouncer with qmail and sendmail, but just today I was reading someones opinion that Postfix is even better, as it uses true server bounces, rather than the bounces after the spam has been recieved. I was mistaken that Spambouncer bounced to the actual source, not the forged FROM address.

Don't worry about "true server bounces." SPAMmers will never see the bounces anyhow. Most SPAMmers forge their return address, and there's no magical way to return the eMail to them if they've done that.

Personally, i use sendmail. It's already on a MacOS X box. Postfix is popular only because sendmail configuration is obtuse (but it's not so bad really). But that really has nothing to do with SpamBouncer (which is dependent on procmail). procmail is most commonly associated with sendmail, but not exclusively so. For example, qmail can be configured to use procmail as an MDA; it just doesn't come configured that way.

[BTP]

I'd say you know your stuff.

Cool to know all that. I learned what I read and haven't moved beyond that. I always like learning new things.

I thought there was a difference between procmail bounces and Postfix bounces. Again, from what I read, Postfix bounces the message before it is accepted, whereas Sendmail accepts the message and then filters it.

The reason I am making the distinction is that I had been hoping that if I were able to bounce the spam, eventually, (years) I might be spammed less. I know, I filter it, but it still gets sent to me.

[Rainy Day]

Originally posted by BTP:
I thought there was a difference between procmail bounces and Postfix bounces. Again, from what I read, Postfix bounces the message before it is accepted, whereas Sendmail accepts the message and then filters it.

Just to clarify: Postfix is an MTA (Mail Transport Agent), just like sendmail. In fact, Postfix was written as an alternative to sendmail. Both can use procmail as a MDA (Mail Delivery Agent).

For the record, sendmail doesn't unconditionally accept all incoming mail. It only accepts mail for which it has a map to accept. So if an incoming mail is addressed to joe@somedomain.com but there is no such user, that mail will be rejected (unless there's a catch-all account for the domain and user "joe" hasn't been mapped as a reject address).

The reason why SpamBouncer bounces are faked with sendmail is because once sendmail passes an eMail off to an MDA, it is considered "delivered." Postfix may do the same in its treatment of mail, as regards procmail, but i don't know very much about Postfix. I think Postfix may have filtering options as plug-in modules (which are designed specifically for Postfix), and which, as you suggest, are invoked before the mail is accepted for delivery and passed off to an MDA like procmail. This may be why some people (incorrectly) suggest that Postfix supports server level bounces and imply that sendmail doesn't. Postfix may simply have rich pre-delivery filter options (which sendmail lacks).

But that is really moot because SPAMmer's would almost never see the bounces anyhow, and in the unlikely event they did, it is improbable that many would attempt to clean up their SPAM lists (as that would cost them more than sending eMail to null addresses). I've heard of people who have turned off an eMail account with true server-level rejects, and when turned back on a year or so later, find the address receives more SPAM than when they turned the account off.

Part of the reason for this is that there's zero motivation for folks who sell SPAM lists to actually sanitize them. While there is some benefit to the SPAMmer (the guy actually sending out the SPAMs), there is no advantage to the guy trying to sell SPAM lists to SPAMmers. Culling out dead eMail addresses only reduces the number of addresses they can brag about when selling their lists. It also requires time and money to do so, and so erodes the profit margin. Far easier to simply lie and say their lists are "verified." This is not exactly a respectable industry, and ethical standards are not any higher than that of a politician or used car salesman.

Server level bouncing is an ineffective SPAM countermeasure. Your choice of an MTA should be based completely on other criteria. Even a flip of a coin would be a better criterion (honestly). But if it gives you a warm feeling at night, well then there's something to be said for that!

[Edit for grammar]

[Rainy Day]

Originally posted by BTP:
Postfix is even better, as it uses true server bounces, rather than the bounces after the spam has been recieved. I was mistaken that Spambouncer bounced to the actual source, not the forged FROM address.

I just read this a little more carefully and see there's a slight misunderstanding here. True server level bounces do not necessarily go back to "the source." They go back to whoever is trying to hand off mail to your MTA. In the case of SPAM, this is usually not the SPAMmer. SPAMmers generally steal resources by using somebody else's eMail server to send out their SPAM. Perhaps you've heard the term "open relay"? That's what SPAMmers look for (and generally find and use). Somebody else's eMail server which is willing to act as a intermediary to you.

So a server level reject goes back to the server trying to hand the eMail over (the open relay), but not to the SPAMmer because the open relay must rely on the info in the mail headers, which likely has been forged, to try to return it to the originator. This is why server level rejects have virtually no impact on SPAMmers.

It is not uncommon for the SPAMmer to forge the recipient's address as the sender of the message. Thus when your server bounces the incoming eMail, it's possible it could be "returned" to you.

The only way a server level bounce vs a fake bounce (like SpamBouncer generates under sendmail) could possibly make any difference whatsoever to the SPAMmer is in the unlikely event the SPAMmer has used a legitimate return address and was examining the bounces to determine which were true server level bounces, and using that info to cull their lists. But you really have a better chance of winning the PowerBall lottery jackpot than this happening.

For the sake of argument, let's just assume the SPAMmer did want to cull their list so they only send eMails to valid eMail addresses (presumably to maximize the effectiveness of their SPAMming resources). Would such a SPAMmer be any more inclined to send a SPAM to an address with a known SPAM filter than to a nonexistent eMail address? One would have to think both would be a waste of their resources.

In the end, server level bounces neither inflicts more pain and suffering on a SPAMmer, nor decreases the amount of SPAM which will be sent to your eMail address. It really is a non-issue as regards SPAM countermeasures.

There certainly is a cost for SPAM, beyond its annoyance factor, however. It consumes resources. Clogs up mail server hard drives, and reduces effective bandwidth (it's like having clogged pipes or atherosclerosis). ISP's need to buy larger HD's, faster computers, and bigger connections to the InterNet, a cost which they pass along to the consumer.

The best SPAM countermeasure is to close up open relays. Make sure your SMTP box doesn't relay. By default, modern sendmail ships with relaying turned off. In the old days, before SPAM and when sendmail was about the only available MTA, sendmail used to relay mail freely. As SPAM came about, sendmail's relaying became a problem. As a result, it developed a bad reputation as a SPAM relay. The problem has long ago been fixed, although some old sendmail configurations may still be relaying SPAM. Today, open relays are usually the result of inexperienced postmasters.

The next best line of defense is a server level filter. If you get something which is clearly and definitely SPAM, the best course of action is to simply delete the eMail rather than bounce it (server level or fake). Bouncing an eMail which will never go back to its source is unproductive and only further consumes resources and reduces available bandwidth. Bouncing known SPAM may give you a vague feeling of satisfaction, but it is a hollow satisfaction and ultimately only contributes to the problem created by SPAM.

[[APi]TheMan]

Originally posted by Rainy Day:
Now you can, if you like, run SpamBouncer on your Mac under MacOS X. In this scenario you'll still be downloading all the SPAM to your Mac, but SpamBouncer will filter it before it's delivered to Mail.app. Not so good if you're using dial-up, but not a bad solution if you have broadband. Most effective, of course, would be if you could run SpamBouncer on your mail server, that way you won't have to download the SPAM to your Mac in the first place. It's really a question of bandwidth.

I am not concerned about bandwidth, I'm on college ethernet. I'll check out Spambouncer, is it difficult to set up in my situation?

[Rainy Day]

I am not concerned about bandwidth, I'm on college ethernet. I'll check out Spambouncer, is it difficult to set up in my situation?

No, not difficult, but it will take a little work. All the tools you need, except for SpamBouncer itself, are part of the default MacOS X BSD install. You just have to hook things up and turn them on.

You'll probably need to use fetchmail to suck eMail into your Mac and hand off to your MDA (i.e. procmail). It can also be used to poll any number and combination of POP2, POP3, IMAP2bis, IMAP4, IMAPrev1, ESMTP ETRN, and ODMR based accounts (which means just about anything), so your typical .Mac, college POP3 mailbox, or AOL account should all be easy.

Then just set procmail as your MDA, and hook in SpamBouncer. You'll probably want to tweak SpamBouncer a bit. Finally, tell Mail.app to look for mail in your UNIX mailbox.

You can find links for more info on these tools and for SpamBouncer on the Things MacOS X web page; look in the fetchmail, procmail and SPAM countermeasures sections.

[[APi]TheMan]

Originally posted by Rainy Day:
You can find links for more info on these tools and for SpamBouncer on the Things MacOS X web page; look in the fetchmail, procmail and SPAM countermeasures sections.

I'm down to play around with fetchmail and procmail a bit but regarding 10.2.x's Mail.app, the Things MacOS X site notes that the ability to check UNIX-style mail spools... eh.

Thanks, Rainy Day.

edit: I wonder if GNUMail.app can read UNIX-style mail spools... hmmm

[Rainy Day]

regarding 10.2.x's Mail.app, the Things MacOS X site notes that the ability to check UNIX-style mail spools... eh.

Looks like Apple removed that ability from Mail.app in Jaguar... but hey, Mail.app stores mail in UNIX mailbox format anyhow, and MacOS X is UNIX afterall, so there's a work-around involving UNIX links:

http://www.koch-schmidt.de/cronnix/docs/faq.html

[Edit/WARNING: I now believe there are potential problems with the link approach (above) which could result in loss of mail or mailbox corruption. Please read my follow-up post below. Almost certainly a better idea is to tell procmail to deliver the mail directly into one of Mail.app's mailboxes, but there are potential problems with that idea too. One would need to ensure that Mail.app is observing the same lockfiles as procmail, else data corruption or mail loss could occur. There are other potential problems too, as outlined in my follow-up below. Caution is advised!]

Another work-around is to set up a local IMAP or POP server to allow Mail.app to read the local mailbox, but that's a bit too convoluted for my tastes. It also could open the door to hackers, so there's a security consideration here.

[Rainy Day]

There are three workarounds to the removal from the Jaguar version of Mail.app of the ability to read UNIX mailboxes. One involves using UNIX file links, which are similar to MacOS aliases, and a second involves procmail delivering mail directly into one or more of Mail.app's mailboxes. The links approach will suffer all the same problems as the procmail approach, plus it will have a few additional problems of its own, so we can immediately rule out the link approach in favor of the procmail approach. The third approach is to set up an IMAP or POP server so Mail.app can read a local UNIX mailbox. This approach circumvents potential mailbox corruption problems of the other two approaches, but would add system overhead and introduce a potential security risk which might open a door to your Mac for intruders.

It is important to note that all of this is speculation at this point. It could be that Mail.app deals with changes to its mailbox files gracefully. Investigation is required, however, before any of these musings be taken as recommendations; they are merely advisories of potential problems, not actual confirmed problems. What does seem certain, however, is that the link approach should be ruled out as an option in favor of the procmail direct delivery approach.

The potential problems with the "procmail direct delivery" solution all have to do with how Mail.app would behave should one of its mailboxes be changed "behind its back." If Mail.app observes lockfiles and deals with changes gracefully, then this approach will work without problems.

Worst case scenario, however, is that Mail.app assumes that it alone will alter its mailboxes and ignores lockfiles, or fails to notice that a mailbox has been changed before it alters one of its mailboxes (e.g. when moving mail or deleting messages from within Mail.app). In this case, loss of mail or mailbox corruption could occur. It is also possible that Mail.app would fail to notice newly added messages to a mailbox. Yet another potential problem is that Mail.app might use lockfiles and keep a mailbox locked for long periods of time (e.g. when a mailbox is currently being displayed in Mail.app) and prevent or hinder procmail from delivering mail. Again, this is only speculation as to potential problem areas, not reports of actual problems!

The IMAP or POP server approach could prove to be the safest approach from a mailbox file corruption standpoint, but it sure is inelegant, adds overhead, and could potentially introduce a security issue by opening up a port on your Mac.

I'll investigate these issues when i've a little more free time to see which is best/safest overall.

Talk about opening a can of worms! Thanks, Apple, for removing support for reading UNIX mailboxes! (I wonder if there's a tech note addressing this issue?)

[Edit: Rewrite for clarity.]

[[APi]TheMan]

Originally posted by Rainy Day:
Talk about opening a can of worms! Thanks, Apple, for removing support for reading UNIX mailboxes! (I wonder if there's a tech note addressing this issue?)

Thanks for the response. I took the time to download GNUMail.app and it supports UNIX mail boxes, but the settings in GNUMail.app's account setup dialog are a little different than how the tutorial explains to set up Mail.app to read UNIX mail. In short, I'm not too sharp on the fetchmail lingo and I'm not sure I'm getting the settings correct.

I changed the protocol in my .fetchmailrc to IMAP to work correctly with the .Mac server (mail.mac.com) by the way.

When I start fetchmail I don't get a message saying that my mail has been downloaded (like the how-to documentation says I should).

Thanks, man.

[Rainy Day]

Originally posted by [APi]TheMan:
I'm not sure I'm getting the [fetchmail] settings correct.

When I start fetchmail I don't get a message saying that my mail has been downloaded (like the how-to documentation says I should).

Hmm... it's been a year or two since i've configured a fetchmail, so i'm a bit rusty on it at the moment. I will be delving back into this whole topic in the next week or so. Hopefully i'll remember to post my findings on this thread, so it'll be archived at least.

But here are a couple of resources for you:

man fetchmail

You probably have already done that. Pay particular attention to the -c, -v, and -v -v options.

And there's this O'Reilly OnLamp article.

[Also, FYI, i did some major rewriting to my last couple of posts above. Hopefully it's clearer now.]

[Edit: Typo]

[Rainy Day]

Also:

fetchmail FAQ

fetchmail home page

[[APi]TheMan]

Originally posted by Rainy Day:
man fetchmail

You probably have already done that. Pay particular attention to the -c, -v, an -v -v options.

Yeah, I did check out -v to see if starting fetchmail in verbose mode would tell me something about why I wasn't getting any confirmation to sdout. No luck, I just get dumped to a new prompt. A quick ps -auxww | grep fetchmail shows it is, in fact, running.

In my post about not being sure about getting the settings correct, I was talking about GNUMail.app's settings... as they are not labeled exactly the same for the UNIX account as they are discussed in the tutorial for setting up 10.1.x's Mail.app.

I'll check out the O'Reilly article.

[Rainy Day]

A quick ps -auxww | grep fetchmail shows it is, in fact, running.

Ah, that could be the problem. Kill the daemon while debugging/confirming your configuration file commands and do all your testing by invoking fetchmail via the command line.

Also, i would use the command line mail command to check your local mailbox while you're getting fetchmail configured. Once configured, then work with GNUMail.app.

While i don't think this is your problem yet (as you aren't getting any diagnostic messages from fetchmail), it could be a problem once you get that going (from the fetchmail FAQ):

R1. Fetchmail isn't working, and -v shows `SMTP connect failed' messages.

Fetchmail itself is probably working, but your SMTP port 25 listener is down or inaccessible.

The first thing to check is if you can telnet to port 25 on your smtp host (which is normally `localhost' unless you've specified an smtp option in your .fetchmailrc or on the command line) and get a greeting line from the listener. If the SMTP host is inaccessible or the listener is down, fix that first.

I'll check out the O'Reilly article.

The fetchmail FAQ is really quite extensive; give it a look too.

[[APi]TheMan]

Originally posted by Rainy Day:
Ah, that could be the problem. Kill the daemon while debugging/confirming your configuration file commands and do all your testing by invoking fetchmail via the command line.

Yeah, I've been killing the fetchmail while I edit my fetchmailrc then reinvoking fetchmail, so I've got that covered.

Interesting, something I noticed when running fetchmail with -c:

Code:
[ekm218-093-r:~] aorth% fetchmail -c
9398:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:284:
fetchmail: SSL connection failed.
fetchmail: Authorization failure on aorth@mail.mac.com

Yeah, I assume that means my password is wrong... but it's not.

Also, i would use the command line mail command to check your local mailbox while you're getting fetchmail configured. Once configured, then work with GNUMail.app.

How does the command line mail program know where to get my mail? I assume it checks /var/mail/username?

[Rainy Day]

Originally posted by [APi]TheMan:
Interesting, something I noticed when running fetchmail with -c:

Code:
[ekm218-093-r:~] aorth% fetchmail -c
9398:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:284:
fetchmail: SSL connection failed.
fetchmail: Authorization failure on aorth@mail.mac.com

Yeah, I assume that means my password is wrong... but it's not.

Not necessarily. It could be the account name is wrong. Now if the machine and/or domain name is wrong, said account/password combination probably wouldn't exist on said machine, so that too could generate this message.

But "mail.mac.com" looks right. At least, that's what i think it was for iTools, and i'm assuming .Mac uses the same name? Yes?

Check the fetchmail FAQ's, if you haven't already, as that might have some tips. It's probably something fairly simple.

How does the command line mail program know where to get my mail?

If no input file is specified, it reads the user's default mailbox file.

[[APi]TheMan]

Originally posted by Rainy Day:
Not necessarily. It could be the account name is wrong. Now if the machine and/or domain name is wrong, said account/password combination probably wouldn't exist on said machine, so that too could generate this message.

But "mail.mac.com" looks right. At least, that's what i think it was for iTools, and i'm assuming .Mac uses the same name? Yes?

Yah, I just logged onto the webmail interface at webmail.mac.com with the same username and password. Ugh. I'll read the FAQs.

[BTP]

If you were running an OS X box as your mail server, you could use this hint (from Macosxhints.com) to set yourself up.

Rainy Day, you are a wealth of information! I have just been reading the latest stuff with great interest.

Update on my Spambouncer experience: I ***LOVE*** this thing!!!

I had 1 false positive and I still run through the logs (1 minute max) to check for false positives. Also I turned on the various blocklists and the few, 1-2 a day, that slipped through, is now squashed!

I am quite happy..

[[APi]TheMan]

Originally posted by BTP:
If you were running an OS X box as your mail server, you could use this hint (from Macosxhints.com) to set yourself up.

Yeah, I greatly appreciate Rainy Day's help.

BTP, I'm stoked you are so happy with Spambouncer, I wish I could be so happy... That link you posted is pretty much the same instruction set that Rainy Day sent me to. Fetchmail is installed and configured, I just can't get it to authenticate on the .Mac servers.

Ugh.

[BTP]

Sorry about the dupe.

I am learning from you guys, I had no idea how far you could take this. I don't get any junk at all on my .mac, which I know they filter.

There is no comparison to how good it feels to be blocking all that crap. I am *so* sick of it all and now I can (almost) go back to normal. My email sounds and it is something for me. How original!

I hope you are able to figure something out, this is so excellent! My latest count is one spam slipped through since the 16th, Mail easily grabbed that one. One false positive, but because they were on a spammy network and the IP range was blocked.

Since I can notify blocked senders if I choose, this is not a problem --so far.

[Peter Panther]

Just to be absolutely complete about killing spam early, there is a way to tie up ressources on the spammers server called "Teergrube".

http://www.iks-jena.de/mitarb/lutz/u...rgrube.en.html

Basically, it will figure out you're receiving spam, then hold the connection open by repeatedly pretending to have trouble getting the message. As a result, the spammer will have one of his servers outgoing connections feed the teergrube his message, one bit at a time. While he is doing so, he can't send thousands of other messages. And why wouldn't you finally bounce or dump it in the bitbucket anyway, after all ?

You obviously want to make sure you don't accept too many of those incoming connections so it does not turn into a DOS-attack against yourself, but that's pretty easy.

[Rainy Day]

Just to be absolutely complete about killing spam early, there is a way to tie up ressources on the spammers server called "Teergrube".

Basically, it will figure out you're receiving spam, then hold the connection open by repeatedly pretending to have trouble getting the message. As a result, the spammer will have one of his servers outgoing connections feed the teergrube his message, one bit at a time.

This is a really bad idea for two reasons:[list=1][*]SPAMmers rarely use their own hardware to send out SPAM; they usually steal resources on someone else's hardware. You aren't inconveniencing the SPAMmer at all by this tactic, only the SPAMmer's victim.
[*]Your filter might falsely identify legitimate eMail as SPAM (false positive).[/list=1] I recently looked at the error log of a mail server which had been exposed to the InterNet, but not yet connected to a domain. It received about a dozen hits a day from SPAMmer's looking for a mailserver to co-opt. SPAMmer's are thieves and slither with the snakes, but the best way of dealing with them is to not respond to them in any way. By trying to retaliate, you're likely to involve innocent parties and waste bandwidth yourself without causing any grief whatsoever for the SPAMmer.

[pimephalis]

Originally posted by Rainy Day:
This is a really bad idea for two reasons:[list=1][*]SPAMmers rarely use their own hardware to send out SPAM; they usually steal resources on someone else's hardware. You aren't inconveniencing the SPAMmer at all by this tactic, only the SPAMmer's victim.
[*]Your filter might falsely identify legitimate eMail as SPAM (false positive).[/list=1] I recently looked at the error log of a mail server which had been exposed to the InterNet, but not yet connected to a domain. It received about a dozen hits a day from SPAMmer's looking for a mailserver to co-opt. SPAMmer's are thieves and slither with the snakes, but the best way of dealing with them is to not respond to them in any way. By trying to retaliate, you're likely to involve innocent parties and waste bandwidth yourself without causing any grief whatsoever for the SPAMmer.

Actually, the best way to deal with spammers is to LART them. That is, if you have the know how, find out where they're connecting from and begin notifying the people responsible for providing them with connectivity. That means, you inform their ISP of their spamming. If nothing is done (or you get the feeling that their abuse email box is really and alias to the waste bin), then inform the ISP's upstream provider of their non-responsiveness. Then complain to the people providing their DNS, etc. etc. etc. Finally, if none of this works, nominate them to every block list you can find.

The general idea is never to have any communication with the spammers, but to do everything you can to get them and/or their associates disconnected.

One final word of caution; don't ever use your real email address when complaining about spammers; many are connected with truly irresponsible ISPs and these people will not only ignore your complaint but will also give out your email address.

p.s. I would NEVER recommend this, but you can also take a slightly ironic but renegade approach; find out who is spamming you and sign them up for every physical piece of junk mail you can find. On the order of tons, if possible.

[Rainy Day]

Originally posted by pimephalis:
find out where they're connecting from and begin notifying the people responsible for providing them with connectivity. That means, you inform their ISP of their spamming... Finally, if none of this works, nominate them to every block list you can find.
<snip>
The general idea is never to have any communication with the spammers, but to do everything you can to get them and/or their associates disconnected.

I agree that this would be an ideal solution. It's not a terribly practical one when you receive, as i do, on the order of 1000 SPAM's a week. SPAMbouncer does, i believe, have the ability to automatically send a complaint eMail to the upstream provider. I'm not sure how well that might work, however. I've never turned it on for fear of false positives, and i haven't the time to review each complaint eMail before it is sent, so i keep it turned off.

p.s. I would NEVER recommend this, but you can also take a slightly ironic but renegade approach; find out who is spamming you and sign them up for every physical piece of junk mail you can find. On the order of tons, if possible.

Well, once again, you'll probably never be able to figure out who the real SPAMmer is, so this is nearly impossible to do. It's much more likely that you'll only figure out who was the SPAMmer's victim (i.e. the person whose computer the SPAMmer co-opted to send out his or her SPAM), mistake that person for the SPAMmer, and that's who you'd be targeting. A far better solution would be to send a polite eMail to this individual, as they are likely unaware that their computer is serving as a SPAM relay; this would allow them to take corrective action.

Remember, SPAMmers steal resources and cover their tracks. They don't want to be found. Closing open relays is the most important SPAM fighting technique.

Earlier in this thread i mentioned that i would look into the possibility of depositing mail directly into Mail.app's mailboxes (e.g. from SPAMbouncer). After examining this issue, i believe that it probably can be done, but it's not straightforward and maybe shouldn't be done.

Mail.app "mailboxes" are packages (i.e. a special kind of folder which generally looks like a single file in the Finder). It appears that inside its mailboxes Mail.app does use a lock file (named .lock), so one can tell when Mail.app is using a particular box and thus avoid writing conflicts with Mail.app, but the problem is that Mail.app is likely to lock a mailbox for a very long time (i.e. until the user either opens a different mailbox, or closes Mail.app). Thus delivery to the mailbox might be held off for a very long time, and i'm not sure what kind of complications might arise from that. It might be possible, however, to send an AppleEvent to Mail.app to tell it to free up the mailbox and thus make this approach practical. If you do write to one of Mail.app's mailboxes, you should delete the file named mbox.SKindex.isValid (to force Mail.app to update the mailbox's index).

On a slightly different note, in the last couple of weeks, i have learned that sendmail itself supports mail filters (called "Milters"). I'm going to investigate milters in more detail later. I'm thinking it might be possible to hook something like SPAMbouncer into a milter and achieve true server level bounces. While this won't make any difference to the SPAMmer, it is possible that there might be some advantages to this approach for the postmaster (e.g. if one can determine that a message is SPAM solely from its header info, then the server could reject it without accepting (downloading) the full body of the message, and thus save some bandwidth). But this kind of filtering might be difficult to do. Stay tuned for the latest developments.