Hi there, On 22 Jun 2006, at 15:47, Tracey Gates wrote:
I've been reading up on SPF and understand that it checks the validity of the return address of an email and if that return address is valid, it doesn't change the scoring of the email to identify it as spam...a wash so to speak. If it cannot validate the return address then it assumes that it's spam....is that correct?
No. You should read and fully understand <http://new.openspf.org/ Introduction> before proceeding. There's also the SPF website at <http://www.openspf.org>.
Put simply, SPF is a mechanism for specifying in DNS which mail servers send mail from a domain. SPF has absolutely nothing to do with spam, it aims to stop joe jobs and forgeries of the envelope sender.
SPF doesn't "score" anything. SA can be configured to score messages based on SPF. Spammers can setup SPF records for their own domains (and have done so) so you shouldn't deduct points for mail which matches the SPF record. SA has never assumed that a message is spam based on only a message hitting one rule.
You may be able to configure your MTA to check the SPF records for the envelope sender, in this case, you can choose to reject mail which fails the SPF check (the sending IP is not included in the SPF record and the SPF record for the domain is terminated with -all, hardfail)
You should also be aware that SPF breaks forwarding to the point that it is unusable unless you also do some form of sender rewriting (ala SRS), however SRS is not yet ready for prime time (IMHO) and may never be (libsrs2.org hasn't been updated in years)..
We are getting some emails that end up as being identified as spam but aren't. What we would like to do is to send a "bounce" email back to the sender (if it is a valid return address & their email has been identified as spam by spamassassin) for them to tell us that it really isn't spam.
This is an absolutely horrendous idea for a number of reasons. You have no way of guaranteeing that the return address is "valid". You cannot rely on SPF, since most domains do not have SPF records, if they do they are usually terminated with ~all (softfail) which is for all intents and purposes useless (even worse is ?all which allows everyone and their dog to send mail, carte blanche, claiming to be from the domain in question).
Even IF the message has been sent from an IP which is specified in the SPF record for the domain, you still have no idea if the localpart is valid.
I know that this may sound weird but it's difficult to us to review all the spam to catch a few false positives. So my boss thought that this might be a solution. Of course the sender of the email couldn't reply back to the bounce because it would also be considered spam.
If you are getting so many false positives that it is "difficult", there is something wrong with your SA setup. Make sure you haven't set your spam score too low, 5 is the recommended default. What rules are these FPs hitting?
If you're trying to come up with a "solution" which absolves you of reviewing spam for false positives, you're out of luck. No anti-spam tool is ever 100% accurate.
You just blew your idea out of the water with that last comment.
Is anyone else doing this? Is this a good idea? How do we tell the senders to verify that what they sent us is indeed NOT spam?
If anyone else is doing this, they are they should announce it loudly and clearly so everyone else who is actually sane can block them for all eternity. No- it is a Very Bad Idea(tm).
Your last question makes absolutely no sense at all, sorry. -j
PGP.sig
Description: This is a digitally signed message part
