Keeping my spam
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"
10 Replies
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.
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.
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.
@smiffy:
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 implement SPF checking. Have a read of
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.
@sednet:
I would not implement SPF checking. Have a read of
http://homepages.tesco.net/J.deBoynePol … rmful.html">http://homepages.tesco.net/J.deBoynePollard/FGA/smtp-spf-is-harmful.html
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.
@sweh:
@sednet:I would not implement SPF checking. Have a read of
http://homepages.tesco.net/J.deBoynePol … rmful.html">http://homepages.tesco.net/J.deBoynePollard/FGA/smtp-spf-is-harmful.html
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.
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 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
@sednet:
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.
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)
@kangaby:
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.