Is there any way to filter and keep my spam instead of simply rejecting it? Or is antispam a strictly boolean thing?

I'm not asking for anybody to write me an In A Nutshell book here. Just that email servers and antispam are still a little new to me, so I don't know which ones can do what and so on.

Update: I think the answer is "Yes, and it's very complicated"
http://wiki.apache.org/spamassassin/IntegratePostfixViaSpampd
http://onetforum.com/fourm/viewtopic.php?p=63#63

You would need to read the documentation for whichever spam filters you are planning to implement. There are generally options regarding what actually happens to the spam, whether it is rejected, vanishes into a black hole or is simply tagged as spam and gets passed on.

I use Dspam on my main mail server (not a Linode, my Linodes just act as backup MXs) and that which is identified as spam is not delivered to my main mailbox, but goes into a quarantine mailbox. If I didn't clear that out on a regular basis, I would indeed be keeping my spam.

From the days when I used Spamassassin, I seem to recall that one of the options was just to put a "this is spam" row into the mail header.

Conclusion: you do whatever you want by configuring the anti-spam software accordingly.

If you would like a description of my spam filtering system as a guideline (I have several stages in the process), please feel free to contact me directly.

I recommend that you block as much spam at SMTP time as possible. I keep mine set up so that obvious spam is rejected then, while "maybe" spam is tagged and accepted.

By rejecting mail at SMTP time, you're keeping the sending system on the line while you decide whether or not to accept it. That way, if it's legitimate, the sender is guaranteed to get a bounce notice, since his sending server will know it didn't go through.

Also, it saves a lot of disk space and aggravation to simply refuse delivery of most mail.

Absolutely. Over 50% of the mail I receive in is rejected through DNS blacklists and SPF checks (mostly the blacklists thought due to all those horrible people out there with either no SPF records or ones with a soft-fail on them).

I would not have said it was hard to do.

Im running debian and postfix with amavisd/spam assassin, and i have it set that it tags my spam and puts ***SPAM*** into the subject line for anything that it thinks is spammy or spam.

It wasnt overly hard to do, and no one is potentially losing email.

_________________
ServerAdmin - www.our-lan.com
"Diplomacy is the art of saying nice doggy whilst looking for a really big stick"
"In my experiece, any attempt to make any system idiot proof will only challenge God to make a better idiot"

I would not implement SPF checking. Have a read of http://homepages.tesco.net/J.deBoynePol ... rmful.html

If you use spamassassin though procmail it won't throw anything out. You can configure spamassassin/procmail/your mailer to do just about anything. Greet delays also work pretty well.

Meh, of all the criticisms on that page, only the one about RFC 1123 is really valid. The rest are all matters of interpretation and are on very shakey ground, or even wrong (if you trust your own relays then the store'n'forward and backup MX server arguments are voided).

If you're going to deploy an SPF aware mail infrastructure then you have to be careful on the design. A too naive implementation can fail, but that's an implementation issue.

_________________
Rgds
Stephen
(Linux user since kernel version 0.11)

You are right that the arguments on that page are a bit weak.

Spammers can easily adapt to and overcome SPF, thats why I don't like it.
Protecting envelope sender addresses just means the spammers have to pick any domain that doesn't use SPF or has no DNS servers and use that domain name for their envelope header. SPF doesn't seen to do reverse lookups on the IPs the connections come from.

I used to check SPF records, but I left it off when I recently upgraded my distro. I use RBL and greylisting (plus SpamAssassin via procmail), and I found that SPF caught practically no spam that wasn't already removed by the other methods.

I still publish an SPF record for my domains in hopes that it will keep spammers from using them as a return address. I was getting 3000 backscatter messages ("bounces" from poorly configured email servers and autoresponders) a day. Fortunately that has tailed off to about 300, though I'm not convinced that it's due to SPF.

Regarding the original poster's question about saving spam, I'll echo what other people have said about ways of just marking and accepting it. However, I know the conventional wisdom used to be that if you can reject mail during SMTP negotiation, it might convince some spammers to remove that address from their database, the theory being that they can save time to send spam to someone else.

Roy

Isn't that the point of SPF. If all legit mail servers have an SPF record, then the spammer can't pretend to come from one of those domains.
They then have to use domains that don't have SPF, and if there are only a few (compared to now) it's easier to block them.
If they use a domain they own with their own SPF record there is a link of proof as to where the spam is comming from and who owns / controls the domain.

SPF is a prove I sent it if I say I sent it system, not an anti-spam system (from what I understand of the docs)

SPF is a 'show it was apparently sent by a host that is authorised to send mail for this domain' system. It doesn't prove anything and, without really widespread adoption, it doesn't achieve much.

_________________
/ Peter