I've always had some interest in examining the email message (content) source, headers, etc. In the past it was also helpful to have a bit of this trash e-mail to more quickly train bayesian type filtering.
One of my concerns is that I don't unknowingly whack the IP reputations.
By keeping spam-blocking by Block Lists ahead of SpamAssassin, you can block by reputation before you get to SpamAssassin.
But then running the default SpamAssassin rule sets take a lot of unnecessary machine resources, as they check everything against certain blocklists again, though no mail from senders in those blocklists gets to the servers.
So perhaps the best thing to do is write our own optimized version of SpamAssassin rule sets; I hinted at this in an earlier reply to this threae.
Another would be to block based on total point score based on using SpamAssassin the way it is now, and take out all the blocklists in exim.conf. However we'd have to decide if the current RBL rulesets would be adequate or if we needed to change/add/delete any.
And we might still have problems, because we'd be holding open connections after we receive data, until SpamAssassin decides whether to keep the email or reject it.
Another problem is that many mail servers don't recognize reject after data. so they won't return error information to senders. You may think this is unimportant, but there are problems with it:
RFCs require that all email either be delivered or returned. If you tell the sending server you don't want the email after they're no longer listening, you'e dropping the email without the sender ever knowing. So some mailservers, which will no longer send to servers which reject their email will keep sending, and even more important, false positives may not get reported. If your system calls something spam which is really important email, then don't you want the sender to know?
With this in mind I'd like to add a related request if it's applicable, about the safety of the different options.
EG: easy - hard to create a bad situation for someone ready to implement optional spam handling methods.
If only we could agree on one optimal method of classifying and blocking spam
.
Conservative message bounce actions, etc. I'm sort of afraid of sending improper or malicious bounce messages.
This has been discussed in several threads; I'm not sure if any of it has been well implemented. Anyone care to do the homework and report back?
including options present in the basic DA user E-Mail Management unless that strays too much from the topic.
Once I stop maintaining a separate SpamBlocker version and eveyrone migrates to the default DirectAdmin system (or at least almost everyone) it will become easier to include settings, options, etc., inside DirectAdmin.
Spam related and hopefully not off topic, it would also be interesting to know if/how admins handle 'non-email' hosting. I have been experimenting with "v=spf1 -all" FWIW. Kind of wish null MX gathered more momentum.
There are problem with
-all. For example, it completely breaks forwarding and it makes it impossible for you to send email from a server other than your own (this can often happen when you're travelling, and when using certain ISPs who invisibly reroute all outgoing email through their own email servers.
Of course without
-all SPF is of little help in the anti-spam world.
And it breaks the other use of SPF as well; that of verifying against spoofing (which was the original point of SPF.
A good example is email from PayPal. Youy'd think that PayPal would benefit mot from using
-all as it would allow everyone checking against SPF to know if email purporting to be from PayPal is spoofed. But PayPal has had to use
~all as otherwise forwarding of PayPal email simply wouldn't work. People accepting email at an address at their own domain and then forwarding it (for example) to their gmail account, would have it marked as spam.
For what it's worth, here's the PayPal spf record:
Code:
"v=spf1 include:pp._spf.paypal.com include:3rdparty._spf.paypal.com include:3rdparty1._spf.paypal.com include:3rdparty2._spf.paypal.com include:3rdparty3._spf.paypal.com include:c._spf.ebay.com ~all"
That
~all at the end means the rest of it is almost insignificant, though it can be (and possibly is; I'm not sure) checked by SpamAssassin which would give negative points to email coming from those servers to make sure it gets accepted.
Good luck in getting any two people to agree on what does and dosn't work
.
Jeff