You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Jason Bertoch <ja...@electronet.net> on 2006/01/19 19:22:25 UTC
SPF test clarification
Can someone point me in the right direction on exactly what the difference
between the following SPF tests are, please? I assume that SPF_PASS means the
sending domain has an SPF record and the sending server IP matches. However,
the description for SPF_FAIL, SPF_SOFTFAIL, and SPF_NEUTRAL are all the same.
In which case does the sender domain not have an SPF record? Which one is there
a record, but the sending server IP doesn't match? What is the fourth case that
I'm missing?
Jason
Re: SPF test clarification
Posted by Leonardo Rodrigues Magalhães <le...@solutti.com.br>.
Jason Bertoch escreveu:
>Can someone point me in the right direction on exactly what the difference
>between the following SPF tests are, please? I assume that SPF_PASS means the
>sending domain has an SPF record and the sending server IP matches. However,
>the description for SPF_FAIL, SPF_SOFTFAIL, and SPF_NEUTRAL are all the same.
>In which case does the sender domain not have an SPF record? Which one is there
>a record, but the sending server IP doesn't match? What is the fourth case that
>I'm missing?
>
>
SPF defines 3 kind of fail: neutral fail, soft fail and fail. This
allows each domain to tell others what to do when SPF fails. If you're
really concerned about your domain being forged, a fail would be the
correct configuration (-all). In other cases, softfail (~all) or neutral
fail (?all) can be used.
http://www.openspf.org/mechanisms.html
Mechanisms can be prefixed with one of four characters:
|*-*| fail
|*~*| softfail
|*+*| pass
|*?*| neutral
--
Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br
Minha armadilha de SPAM, NÃO mandem email
gertrudes@solutti.com.br
My SPAMTRAP, do not email it
Re: SPF test clarification
Posted by Leonardo Rodrigues Magalhães <le...@solutti.com.br>.
Jason Bertoch escreveu:
> <pedestal>
> It's my opinion that if an administrator misconfigured his SPF record,
> or a
> number of other things on their side, it is their fault that mail
> cannot be
> delivered. In the case of SPF_FAIL, they have explicitly told us they
> don't
> want mail to come from a server not listed in their record and I
> believe we
> should follow their directive. In fact, isn't that the point of SPF;
> to help us
> reject forged messages coming from unauthorized servers? Why bother even
> dealing with SPF if we're still going to let people get away with poor
> administration? That's partly how we got here in the first place...
> </pedestal>
>
Yes, I agree with that. If you're working on a financial institution
and you're pretty worried about mail forgery, than any kind of SPF Fail
should be enough for you dropping that message. Altough if you're not in
that situation of extremy worry about mail forgery, i dont think spf
fail is reason enough for rejecting messages.
Log analisys have proven that several domains, even big ones, have
bad spf records. i agree if big-domain-admin made some mistake, it's his
fault, not mine. But please, if you convince my boss from that, i'll pay
a beer :) Generally we, admins of not-big domains/servers, have to do
everything possible to receive message from big-domains, including those
with crappy SPF records.
And more important ...... SPF was created to fight against email
FORGERY. It wasnt created to fight SPAM, altough it helps a lot, because
spammers uses to spoof what i called big-domains. But it's easy for a
spammer to spoof some domain with no SPF records and then SPF checks are
gone !!
Are you a bank ??? Forget all this discussion and drop everything
that didnt SPF_PASS. In all the other cases, i think you'll save some
headache if deal more gently with SPF. At least now that SPF is starting
to get deployed. In two years, when SPF becames reality for all and
almost all domains have SPF records, than these ideas can change and spf
failing may became a reason enough for message dropping.
--
Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br
Minha armadilha de SPAM, NÃO mandem email
gertrudes@solutti.com.br
My SPAMTRAP, do not email it
RE: lock files are not being deleted
Posted by Gary V <mr...@hotmail.com>.
>Is Spamassassin supposed to automatically delete lock files when completed?
>I am just wondering why so many files are created, some timestamps are from
>the previous day.
>
>My log files show the following:
>
>Jan 19 14:17:06 mail spamd[22166]: debug: lock: 22166 trying to get lock on
>/home/filter/.spamassassin/bayes with 3 retries
>Jan 19 14:17:06 mail spamd[22167]: debug: lock: 22167 trying to get lock on
>/home/filter/.spamassassin/bayes with 3 retries
>Jan 19 14:17:06 mail spamd[22164]: debug: lock: 22164 trying to get lock on
>/home/filter/.spamassassin/bayes with 7 retries
>Jan 19 14:17:06 mail spamd[22168]: debug: lock: 22168 trying to get lock on
>/home/filter/.spamassassin/bayes with 6 retries
>Jan 19 14:17:08 mail spamd[22164]: debug: lock: 22164 trying to get lock on
>/home/filter/.spamassassin/bayes with 9 retries
>Jan 19 14:17:08 mail spamd[22164]: Cannot open bayes databases
>/home/filter/.spamassassin/bayes_* R/W: lock failed: File exists
>
>
>It then has several files such as: bayes.lock.mail.domain.com.21886
>
>
>Is this a sign that a process is not completing? Just curious if anyone
>has an idea.
>
>Thanks in advance
>
>Alan Fullmer
Are you using the default NFS-safe locking system? If so, consider flock:
http://spamassassin.apache.org/full/3.1.x/dist/doc/Mail_SpamAssassin_Conf.html#miscellaneous_options
Gary V
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
lock files are not being deleted
Posted by Alan Fullmer <li...@xnote.com>.
Is Spamassassin supposed to automatically delete lock files when completed?
I am just wondering why so many files are created, some timestamps are from
the previous day.
My log files show the following:
Jan 19 14:17:06 mail spamd[22166]: debug: lock: 22166 trying to get lock on
/home/filter/.spamassassin/bayes with 3 retries
Jan 19 14:17:06 mail spamd[22167]: debug: lock: 22167 trying to get lock on
/home/filter/.spamassassin/bayes with 3 retries
Jan 19 14:17:06 mail spamd[22164]: debug: lock: 22164 trying to get lock on
/home/filter/.spamassassin/bayes with 7 retries
Jan 19 14:17:06 mail spamd[22168]: debug: lock: 22168 trying to get lock on
/home/filter/.spamassassin/bayes with 6 retries
Jan 19 14:17:08 mail spamd[22164]: debug: lock: 22164 trying to get lock on
/home/filter/.spamassassin/bayes with 9 retries
Jan 19 14:17:08 mail spamd[22164]: Cannot open bayes databases
/home/filter/.spamassassin/bayes_* R/W: lock failed: File exists
It then has several files such as: bayes.lock.mail.domain.com.21886
Is this a sign that a process is not completing? Just curious if anyone
has an idea.
Thanks in advance
Alan Fullmer
www.xnote.com
www.zoobuh.com
Re: SPF test clarification
Posted by Steve Prior <sp...@geekster.com>.
Jason Bertoch wrote:
> <pedestal>
> It's my opinion that if an administrator misconfigured his SPF record, or a
> number of other things on their side, it is their fault that mail cannot be
> delivered. In the case of SPF_FAIL, they have explicitly told us they don't
> want mail to come from a server not listed in their record and I believe we
> should follow their directive. In fact, isn't that the point of SPF; to help us
> reject forged messages coming from unauthorized servers? Why bother even
> dealing with SPF if we're still going to let people get away with poor
> administration? That's partly how we got here in the first place...
> </pedestal>
I don't disagree with this, though I can give you an example of what can happen.
I used to host the DNS for my domain with speakeasy.net who I had in general
been quite happy with.
Then they decided they needed to implement SPF and they were going to do it RIGHT NOW.
They didn't create an addition to their otherwise wonder DNS admin webapp (I guess
they were in a panic and didn't have the time), so instead they generated SPF records
based on the MX records for your domain. In my case I also used my employers mail
server to send email (and therefore needed to add it to my SPF record), but it
was certainly NOT OK to add them as a MX record for my domain, so I suddenly found
my emails being bounced from some mailing lists (this might have been one of them).
I tried to explain to Speakeasy.net that they were generating incorrect SPF records,
but they thought they were "close enough" and tried to talk me into some unacceptable
workarounds. I don't know if they ever changed this, but I was no longer using them
for DNS hosting in a matter of days.
Since Speakeasy really is pretty good in a lot of ways, I can only imagine what goofy
things some other ISPs have come up with.
Steve
Re: SPF test clarification
Posted by mouss <us...@free.fr>.
Jason Bertoch a écrit :
> <pedestal>
> It's my opinion that if an administrator misconfigured his SPF record, or a
> number of other things on their side, it is their fault that mail cannot be
> delivered. In the case of SPF_FAIL, they have explicitly told us they don't
> want mail to come from a server not listed in their record and I believe we
> should follow their directive. In fact, isn't that the point of SPF; to help us
> reject forged messages coming from unauthorized servers? Why bother even
> dealing with SPF if we're still going to let people get away with poor
> administration? That's partly how we got here in the first place...
> </pedestal>
your server, your rules. I personally don't use SA to police the
network, but to detect spam. In addition, I prefer to let spam slip than
block legitimate mail. I also won't block forwarded mail just because it
fails SPF. but of course, YMMV.
since PSF fail doesn't mean spam (nor spf $success mean legitimate
mail), it's here (in SA) only as an additionnal parameter which value
contributes to a global result.
now if you want to jump in the spf crusade, you should use it in the MTA
and probably not care in a content filter.
RE: SPF test clarification
Posted by Jason Bertoch <ja...@electronet.net>.
> I have seen SEVERAL domains with misconfigured SPF
> values. So, getting SPF_FAILs near required_score would,
> for sure, block some messages coming from misconfigured
> SPF domains which also matches some other rules. False
> positives, I dont like that. Anyway, i have raised my
> SPF_FAILs scores to:
>
> score SPF_NEUTRAL 4
> score SPF_SOFTFAIL 4.5
> score SPF_FAIL 5
> I'm running with required_score 8. Failing SPF will
> raise a lot the message score, but will not reject it only
> because of SPF failing. If it's really a SPAM, it will
> certainly hit several other rules (SARE rules helps a lot
> here) and, adding SPF fail scores to that, will reach
> required score.
Thanks for the input, I now know what to do with my scoring.
<pedestal>
It's my opinion that if an administrator misconfigured his SPF record, or a
number of other things on their side, it is their fault that mail cannot be
delivered. In the case of SPF_FAIL, they have explicitly told us they don't
want mail to come from a server not listed in their record and I believe we
should follow their directive. In fact, isn't that the point of SPF; to help us
reject forged messages coming from unauthorized servers? Why bother even
dealing with SPF if we're still going to let people get away with poor
administration? That's partly how we got here in the first place...
</pedestal>
Re: SPF test clarification
Posted by Leonardo Rodrigues Magalhães <le...@solutti.com.br>.
Jason Bertoch escreveu:
>
> That makes sense but now the scores for these rules have me a little
> confused.
> If a domain administrator indicates that we should fail any message
> not sourced
> from his IP's, why is the score for SPF_FAIL the smallest of the three?
> Shouldn't it be set at or near the required_score, instead?
>
>
I have seen SEVERAL domains with misconfigured SPF values. So,
getting SPF_FAILs near required_score would, for sure, block some
messages coming from misconfigured SPF domains which also matches some
other rules. False positives, I dont like that. Anyway, i have raised my
SPF_FAILs scores to:
score SPF_NEUTRAL 4
score SPF_SOFTFAIL 4.5
score SPF_FAIL 5
I'm running with required_score 8. Failing SPF will raise a lot the
message score, but will not reject it only because of SPF failing. If
it's really a SPAM, it will certainly hit several other rules (SARE
rules helps a lot here) and, adding SPF fail scores to that, will reach
required score.
--
Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br
Minha armadilha de SPAM, NÃO mandem email
gertrudes@solutti.com.br
My SPAMTRAP, do not email it
Re: SPF test clarification
Posted by Matt Kettler <mk...@evi-inc.com>.
Jason Bertoch wrote:
>>>Which case is there a record, but the sending server IP
>>>doesn't match?
>
>
>>That depends what the sender's SPF record is set for in
>>the "all" clause.
>
>
>>If it's ?all you get SPF_NEUTRAL
>>If it's ~all you get SPF_SOFTFAIL
>>if it's -all you get SPF_FAIL.
>
>
>
> That makes sense but now the scores for these rules have me a little confused.
> If a domain administrator indicates that we should fail any message not sourced
> from his IP's, why is the score for SPF_FAIL the smallest of the three?
I don't know about your SA, but on 3.1.0's set 3 it's the middle of the three.
You're trying to apply simple logic to a non-simple system.
Never expect the simple when it comes to SA rule scores, the system is many
orders of magnitude more complex than you think, because it's based on REAL
patterns of REAL email sent by human people.
Let's look at some real-world data:
OVERALL% SPAM% HAM% S/O RANK SCORE NAME
3.437 4.8942 0.0396 0.992 0.80 1.38 SPF_SOFTFAIL
2.550 3.5717 0.1676 0.955 0.53 1.14 SPF_FAIL
2.297 3.2090 0.1695 0.950 0.52 1.07 SPF_NEUTRAL
Note that SPF_FAIL matched had a higher HAM% than SOFTFAIL did..
Just because it in theory should be a better test does not mean it will be.
You've got humans involved here, and human behavior is a lot strange.
My guess is that a careless admin who did not think the implications through
would be prone to immediately go to SPF_FAIL. This careless admin is also more
likely to have omissions from his SPF record.
SOFTFAIL is more likely to be used by conservative admins who think out their
needs more carefully. These sites are much less likely to have omissions in
their records.
But that's just a theory. I'm no psychologist, I just read the numbers.
RE: SPF test clarification
Posted by Jason Bertoch <ja...@electronet.net>.
>> Which case is there a record, but the sending server IP
>> doesn't match?
> That depends what the sender's SPF record is set for in
> the "all" clause.
> If it's ?all you get SPF_NEUTRAL
> If it's ~all you get SPF_SOFTFAIL
> if it's -all you get SPF_FAIL.
That makes sense but now the scores for these rules have me a little confused.
If a domain administrator indicates that we should fail any message not sourced
from his IP's, why is the score for SPF_FAIL the smallest of the three?
Shouldn't it be set at or near the required_score, instead?
Re: SPF test clarification
Posted by Matt Kettler <mk...@evi-inc.com>.
Jason Bertoch wrote:
> Can someone point me in the right direction on exactly what the difference
> between the following SPF tests are, please? I assume that SPF_PASS means the
> sending domain has an SPF record and the sending server IP matches. However,
> the description for SPF_FAIL, SPF_SOFTFAIL, and SPF_NEUTRAL are all the same.
> In which case does the sender domain not have an SPF record?
None of the above.. If the sender domain has no SPF record, there will be no SPF
rules matching at all.
> Which one is there
> a record, but the sending server IP doesn't match?
That depends what the sender's SPF record is set for in the "all" clause.
If it's ?all you get SPF_NEUTRAL
If it's ~all you get SPF_SOFTFAIL
if it's !all you get SPF_FAIL.
>What is the fourth case that
> I'm missing?
There is none.