You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Victor Sudakov <va...@sibptus.ru> on 2020/11/04 14:47:34 UTC
SPF_FAIL
Dear Colleagues,
Why does SpamAssassin (Debian 10, SpamAssassin 3.4.2) not count an SPF
check fail as a symptom of spam? That's what I see in the spam report:
0.0 SPF_FAIL SPF: sender does not match SPF record (fail)
No spam points for an SPF fail? And it's even a hard fail (a "-all") in
this case.
I can probably bump up the score for SPF_FAIL but would like to know
first why it is a 0.0 by default. This was probably someone's
well-grounded decision?
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
Re: SPF_FAIL
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>Bill Cole skrev den 2020-11-05 04:22:
>>On 4 Nov 2020, at 20:42, Benny Pedersen wrote:
>>
>>>Bill Cole skrev den 2020-11-05 00:21:
>>>
>>>>1. Incorrect SPF records are not rare. Even '-all' records with some
>>>>permitted IPs.
>>>
>>>envelope sender changes on nexthop
>>
>>Irrelevant to the problem cited, which is simply incorrect records
>>that fail to list IPs that they should
On 05.11.20 11:52, Benny Pedersen wrote:
>no its not, its not same domain atleast, more or less people say
>maillists breaks spf and we need srs to resolve it, maybe why more
>maillists does not have spf at all
I don't remember anyone saying that. Maybe you confused forwarding and
mailing lists?
>>Are you maybe thinking of how mailing list managers like Mailman or
>>majordomo operate?
>
>postfix maillist have no spf at all, i still get dmarc pass :=)
>
>can read only accounts be solved in spamassassin maillis ?, i just say
>i have now added rhsoft to rpz localy
dmarc can pass even if SPF does not.
dmarc requires either DKIM or SPF pass, with the domain same as From:.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
- Holmes, what kind of school did you study to be a detective?
- Elementary, Watkins. -- Daffy Duck & Porky Pig
Re: SPF_FAIL
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 5 Nov 2020, at 5:52, Benny Pedersen wrote:
> Bill Cole skrev den 2020-11-05 04:22:
>> On 4 Nov 2020, at 20:42, Benny Pedersen wrote:
>>
>>> Bill Cole skrev den 2020-11-05 00:21:
>>>
>>>> 1. Incorrect SPF records are not rare. Even '-all' records with
>>>> some
>>>> permitted IPs.
>>>
>>> envelope sender changes on nexthop
>>
>> Irrelevant to the problem cited, which is simply incorrect records
>> that fail to list IPs that they should
>
> no its not, its not same domain atleast, more or less people say
> maillists breaks spf and we need srs to resolve it, maybe why more
> maillists does not have spf at all
I believe that we have a language barrier, as I cannot make sense of
that "sentence" and it veers off into the irrelevant issue of mailing
list. I am not up to the task of trying to navigate around that barrier.
I am sorry that we cannot understand each other's words.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: SPF_FAIL
Posted by Benny Pedersen <me...@junc.eu>.
Bill Cole skrev den 2020-11-05 04:22:
> On 4 Nov 2020, at 20:42, Benny Pedersen wrote:
>
>> Bill Cole skrev den 2020-11-05 00:21:
>>
>>> 1. Incorrect SPF records are not rare. Even '-all' records with some
>>> permitted IPs.
>>
>> envelope sender changes on nexthop
>
> Irrelevant to the problem cited, which is simply incorrect records
> that fail to list IPs that they should
no its not, its not same domain atleast, more or less people say
maillists breaks spf and we need srs to resolve it, maybe why more
maillists does not have spf at all
>>> 2. Traditional (/etc/aliases, ~/.forward, etc.) transparent
>>> forwarding
>>> breaks SPF.
>>
>> envelope sender changes on nexthop
>
> That is simply not true, unless one deploys extraordinary measures
> such as SRS. SMTP is not UUCP.
oh uucp breaks spf :=)
spf is breaked on original envelope sender, the nexthop sender domain
can still have no spf, or spf pass or fail
>> nothing is really breaked
>
> But in fact, it is. If you use traditional MTA-based forwarding
> mechanisms such as /etc/aliases and ~/.forward files, the envelope
> sender on an outbound message is the same as it is on the inbound
> message. This is why SRS was invented alongside SPF.
then you forwards forward with orginal domain as sender, this is the
fail then, forwarding mta should still self make valid spf for there own
domain, and not include missing ips into original sender domain in
envelope from
> Are you maybe thinking of how mailing list managers like Mailman or
> majordomo operate?
postfix maillist have no spf at all, i still get dmarc pass :=)
can read only accounts be solved in spamassassin maillis ?, i just say i
have now added rhsoft to rpz localy
Re: SPF_FAIL
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 4 Nov 2020, at 20:42, Benny Pedersen wrote:
> Bill Cole skrev den 2020-11-05 00:21:
>
>> 1. Incorrect SPF records are not rare. Even '-all' records with some
>> permitted IPs.
>
> envelope sender changes on nexthop
Irrelevant to the problem cited, which is simply incorrect records that
fail to list IPs that they should
>
>> 2. Traditional (/etc/aliases, ~/.forward, etc.) transparent
>> forwarding
>> breaks SPF.
>
> envelope sender changes on nexthop
That is simply not true, unless one deploys extraordinary measures such
as SRS. SMTP is not UUCP.
> nothing is really breaked
But in fact, it is. If you use traditional MTA-based forwarding
mechanisms such as /etc/aliases and ~/.forward files, the envelope
sender on an outbound message is the same as it is on the inbound
message. This is why SRS was invented alongside SPF.
Are you maybe thinking of how mailing list managers like Mailman or
majordomo operate?
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Fwd: Re: SPF_FAIL
Posted by Benny Pedersen <me...@junc.eu>.
many thanks for read only accounts :/
-------- Original besked --------
Emne: Re: SPF_FAIL
Dato: 2020-11-05 09:05
Afsender: "Reindl Harald (privat)" <ha...@rhsoft.net>
Modtager: Benny Pedersen <me...@junc.eu>, users@spamassassin.apache.org
Am 05.11.20 um 02:42 schrieb Benny Pedersen:
> Bill Cole skrev den 2020-11-05 00:21:
>
>> 1. Incorrect SPF records are not rare. Even '-all' records with some
>> permitted IPs.
>
> envelope sender changes on nexthop
bullshit
>> 2. Traditional (/etc/aliases, ~/.forward, etc.) transparent forwarding
>> breaks SPF.
>
> envelope sender changes on nexthop
bullshit
> nothing is really breaked
you are an clueless idiot
Re: SPF_FAIL
Posted by Benny Pedersen <me...@junc.eu>.
Bill Cole skrev den 2020-11-05 00:21:
> 1. Incorrect SPF records are not rare. Even '-all' records with some
> permitted IPs.
envelope sender changes on nexthop
> 2. Traditional (/etc/aliases, ~/.forward, etc.) transparent forwarding
> breaks SPF.
envelope sender changes on nexthop
nothing is really breaked
Re: SPF_FAIL
Posted by Bill Cole <sa...@billmail.scconsult.com>.
On 4 Nov 2020, at 9:47, Victor Sudakov wrote:
> Dear Colleagues,
>
> Why does SpamAssassin (Debian 10, SpamAssassin 3.4.2) not count an SPF
> check fail as a symptom of spam? That's what I see in the spam report:
>
> 0.0 SPF_FAIL SPF: sender does not match SPF record (fail)
>
> No spam points for an SPF fail?
Technically that's 0.001, because it is used in 'meta' rules and so must not be scored at 0. With Bayes disabled it gets more weight: 0.919. Those appear to have been determined based on a "GA" rescore run some time ago. The latest network mass-check (https://ruleqa.spamassassin.org/20201031-r1883012-n/SPF_FAIL/detail) indicates that SPF_FAIL is not a very good performer on its own.
> And it's even a hard fail (a "-all") in
> this case.
>
> I can probably bump up the score for SPF_FAIL but would like to know
> first why it is a 0.0 by default. This was probably someone's
> well-grounded decision?
Yes.
1. Incorrect SPF records are not rare. Even '-all' records with some permitted IPs.
2. Traditional (/etc/aliases, ~/.forward, etc.) transparent forwarding breaks SPF.
--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: SPF_FAIL
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>Matus UHLAR - fantomas skrev den 2020-11-11 17:01:
>>>>Martin Gregorie skrev den 2020-11-11 11:02:
>>>>> On Wed, 2020-11-11 at 09:52 +0100, Tobi wrote:
>
>>On 11.11.20 15:41, RW wrote:
>>>Note that without a DKIM pass, SPF is easily spoofed in TxRep.
>>
>>is it? how does that work then?
On 11.11.20 17:20, Benny Pedersen wrote:
>signedby tracking in awl and txrep
>
>but not signed, does just group them as not signed, it still is
>reputition
can you please describe deeper?
how is it spoofed? does it ignore SPF sometimes, and takes for correct
otherwise?
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fucking windows! Bring Bill Gates! (Southpark the movie)
Re: SPF_FAIL
Posted by RW <rw...@googlemail.com>.
On Thu, 12 Nov 2020 12:34:25 +0100
Matus UHLAR - fantomas wrote:
> >On Wed, 11 Nov 2020 17:01:21 +0100
> >
> >> On 11.11.20 15:41, RW wrote:
> On 11.11.20 19:06, RW wrote:
> >These two cases share the same "authenticated" primary reputation:
> >
> > Return-path: ceo@example.com
> > From: ceo@example.com
> >
> > Return-path: someone@somewhereelse.com
> > From: ceo@example.com
> >
> >The benefit of this could be substantial, particularly with
> >txrep_learn_bonus set. All you have to do is make sure the envelope
> >sender passes SPF.
> >
> >To be honest I haven't verified this, but the code looks
> >straightforward. $signedby gets set to the tag DKIMDOMAIN or falls
> >back to the fixed string 'spf' for an SPF pass.
>
> sorry, I'm not into txrep much for now.
>
> Does it mean, that txrep correctly compares Return-Path (or any
> header that is filled by envelope from), but incorrectly adds bonus
> to address in From: header?
When there's a valid DKIM signature TxRep identifies the main reputation
with a combination of "header from" and the signing domain. It doesn't
require DMARC style alignment, but that's not easily exploitable because
signing with a different domain creates a new reputation.
With SPF a pass is simply treated as having authenticated the "header
from" regardless of the "envelope from" that was used in SPF. This
allows an existing good reputation to be exploited easily - even
accidentally.
An improvement would be to handle SPF like DKIM, using the envelope
domain like a signing domain.
Re: SPF_FAIL
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>On Wed, 11 Nov 2020 17:01:21 +0100
>
>> On 11.11.20 15:41, RW wrote:
>> >Note that without a DKIM pass, SPF is easily spoofed in TxRep.
>>
>> is it? how does that work then?
>
>It's implicit in the next bit.
>
>> >DKIM reputations are identified by a combination of header from
>> >address and signing domain. SPF pass reputations are just identified
>> >by header address, without incorporating the envelope domain or
>> >requiring alignment.
On 11.11.20 19:06, RW wrote:
>These two cases share the same "authenticated" primary reputation:
>
> Return-path: ceo@example.com
> From: ceo@example.com
>
> Return-path: someone@somewhereelse.com
> From: ceo@example.com
>
>The benefit of this could be substantial, particularly with
>txrep_learn_bonus set. All you have to do is make sure the envelope
>sender passes SPF.
>
>To be honest I haven't verified this, but the code looks
>straightforward. $signedby gets set to the tag DKIMDOMAIN or falls
>back to the fixed string 'spf' for an SPF pass.
sorry, I'm not into txrep much for now.
Does it mean, that txrep correctly compares Return-Path (or any header that
is filled by envelope from), but incorrectly adds bonus to address in From:
header?
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
WinError #98652: Operation completed successfully.
Re: SPF_FAIL
Posted by RW <rw...@googlemail.com>.
On Wed, 11 Nov 2020 17:01:21 +0100
> On 11.11.20 15:41, RW wrote:
> >Note that without a DKIM pass, SPF is easily spoofed in TxRep.
>
> is it? how does that work then?
It's implicit in the next bit.
> >DKIM reputations are identified by a combination of header from
> >address and signing domain. SPF pass reputations are just identified
> >by header address, without incorporating the envelope domain or
> >requiring alignment.
These two cases share the same "authenticated" primary reputation:
Return-path: ceo@example.com
From: ceo@example.com
Return-path: someone@somewhereelse.com
From: ceo@example.com
The benefit of this could be substantial, particularly with
txrep_learn_bonus set. All you have to do is make sure the envelope
sender passes SPF.
To be honest I haven't verified this, but the code looks
straightforward. $signedby gets set to the tag DKIMDOMAIN or falls
back to the fixed string 'spf' for an SPF pass.
Re: SPF_FAIL
Posted by Benny Pedersen <me...@junc.eu>.
Matus UHLAR - fantomas skrev den 2020-11-11 17:01:
>>> Martin Gregorie skrev den 2020-11-11 11:02:
>>> > On Wed, 2020-11-11 at 09:52 +0100, Tobi wrote:
> On 11.11.20 15:41, RW wrote:
>> Note that without a DKIM pass, SPF is easily spoofed in TxRep.
>
> is it? how does that work then?
signedby tracking in awl and txrep
but not signed, does just group them as not signed, it still is
reputition
Re: SPF_FAIL
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>> Martin Gregorie skrev den 2020-11-11 11:02:
>> > On Wed, 2020-11-11 at 09:52 +0100, Tobi wrote:
>>
>> > I suppose some may find it useful to datestamp entries with the last
>> > time mail was sent to them and remove any addresses that haven't
>> > been sent mail for 'x' days/weeks/months/years but I've never
>> > needed that ability.
>On Wed, 11 Nov 2020 11:14:05 +0100
>Benny Pedersen wrote:
>> amavisd have penpal
>> spamassassin have txrep
On 11.11.20 15:41, RW wrote:
>Note that without a DKIM pass, SPF is easily spoofed in TxRep.
is it? how does that work then?
>DKIM reputations are identified by a combination of header from address
>and signing domain. SPF pass reputations are just identified by header
>address, without incorporating the envelope domain or requiring
>alignment.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"To Boot or not to Boot, that's the question." [WD1270 Caviar]
Re: SPF_FAIL
Posted by RW <rw...@googlemail.com>.
On Wed, 11 Nov 2020 11:14:05 +0100
Benny Pedersen wrote:
> Martin Gregorie skrev den 2020-11-11 11:02:
> > On Wed, 2020-11-11 at 09:52 +0100, Tobi wrote:
>
> > I suppose some may find it useful to datestamp entries with the last
> > time mail was sent to them and remove any addresses that haven't
> > been sent mail for 'x' days/weeks/months/years but I've never
> > needed that ability.
>
> amavisd have penpal
> spamassassin have txrep
Note that without a DKIM pass, SPF is easily spoofed in TxRep.
DKIM reputations are identified by a combination of header from address
and signing domain. SPF pass reputations are just identified by header
address, without incorporating the envelope domain or requiring
alignment.
Re: SPF_FAIL
Posted by Benny Pedersen <me...@junc.eu>.
Martin Gregorie skrev den 2020-11-11 11:02:
> On Wed, 2020-11-11 at 09:52 +0100, Tobi wrote:
> I suppose some may find it useful to datestamp entries with the last
> time mail was sent to them and remove any addresses that haven't been
> sent mail for 'x' days/weeks/months/years but I've never needed that
> ability.
amavisd have penpal
spamassassin have txrep
it require no maintaince at all when configured
but i admit txrep could need more support to this
Re: SPF_FAIL
Posted by Martin Gregorie <ma...@gregorie.org>.
On Wed, 2020-11-11 at 09:52 +0100, Tobi wrote:
> > If I only had a ready-made list of those important domains.
>
> If you filter for customer domains then maybe (depending the customer
> domain) adding the customer domain to spf checks is worth a look too.
>
That's easy: keep a database of addresses you've sent mail to and treat
that as a whitelist. Should work at almost any scale and about the only
essential maintenance it needs is the ability to remove addresses you no
longer want to whitelist.
I suppose some may find it useful to datestamp entries with the last
time mail was sent to them and remove any addresses that haven't been
sent mail for 'x' days/weeks/months/years but I've never needed that
ability.
Martin
Re: SPF_FAIL
Posted by Tobi <ja...@gmx.ch>.
> If I only had a ready-made list of those important domains.
If you filter for customer domains then maybe (depending the customer
domain) adding the customer domain to spf checks is worth a look too.
On 11/11/20 6:29 AM, Victor Sudakov wrote:
> John Hardin wrote:
>>
>>> Moreover, after reading other replies in the thread, I am even begining to
>>> doubt the wizdom of rejecting hard SPF fails in the MTA (which I do in
>>> some installations).
>>
>> "it depends".
>>
>> Doing that for certain domains - like, large banks - would probably be a
>> good idea. By default, for all domains, not so much.
>
> If I only had a ready-made list of those important domains.
>
>
Re: SPF_FAIL
Posted by Victor Sudakov <va...@sibptus.ru>.
John Hardin wrote:
>
> > Moreover, after reading other replies in the thread, I am even begining to
> > doubt the wizdom of rejecting hard SPF fails in the MTA (which I do in
> > some installations).
>
> "it depends".
>
> Doing that for certain domains - like, large banks - would probably be a
> good idea. By default, for all domains, not so much.
If I only had a ready-made list of those important domains.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
Re: SPF_FAIL
Posted by John Hardin <jh...@impsec.org>.
On Thu, 5 Nov 2020, Victor Sudakov wrote:
> Moreover, after reading other replies in the thread, I am even begining to
> doubt the wizdom of rejecting hard SPF fails in the MTA (which I do in
> some installations).
"it depends".
Doing that for certain domains - like, large banks - would probably be a
good idea. By default, for all domains, not so much.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
4 days until The 82nd anniversary of Kristallnacht - disarmament enables genocide
Re: SPF_FAIL
Posted by Victor Sudakov <va...@sibptus.ru>.
Matus UHLAR - fantomas wrote:
> > > Victor Sudakov skrev den 2020-11-04 15:47:
> > >
> > > > 0.0 SPF_FAIL SPF: sender does not match SPF record (fail)
>
> > Benny Pedersen wrote: feel free to add into local.cf
> > > score SPF_FAIL (5) (5) (5) (5)
> > >
> > > this will add 5 points to default score
>
> On 05.11.20 18:54, Victor Sudakov wrote:
> > Is that sarcasm, Benny? I don't deserve it.
> >
> > An SPF fail is by no means a sure sign of spam. It can be some indicator
> > of spamicity (as I thought), but not a decisive sign thereof.
>
> we are aware of that. That's the main reason SPF_FAIL score is not high.
>
> but you can to that and expect other rules to push score back to ham range.
If I get users' complaints about false negatives and see that they could
have been prevented by setting a higher score for SPF_FAIL, I'll do that.
>
> > Moreover, after reading other replies in the thread, I am even begining to
> > doubt the wizdom of rejecting hard SPF fails in the MTA (which I do in
> > some installations).
>
> you can still do that as policy decision.
The practice of SRS is not widely adopted IMHO, so I shall prefer for
SPF_FAIL to be one of the many spamicity factors, and not a decisive
factor for rejection.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
Re: SPF_FAIL
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>> Victor Sudakov skrev den 2020-11-04 15:47:
>>
>> > 0.0 SPF_FAIL SPF: sender does not match SPF record (fail)
>Benny Pedersen wrote: feel free to add into local.cf
>> score SPF_FAIL (5) (5) (5) (5)
>>
>> this will add 5 points to default score
On 05.11.20 18:54, Victor Sudakov wrote:
>Is that sarcasm, Benny? I don't deserve it.
>
>An SPF fail is by no means a sure sign of spam. It can be some indicator
>of spamicity (as I thought), but not a decisive sign thereof.
we are aware of that. That's the main reason SPF_FAIL score is not high.
but you can to that and expect other rules to push score back to ham range.
>Moreover, after reading other replies in the thread, I am even begining to
>doubt the wizdom of rejecting hard SPF fails in the MTA (which I do in
>some installations).
you can still do that as policy decision.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
- Have you got anything without Spam in it?
- Well, there's Spam egg sausage and Spam, that's not got much Spam in it.
Re: SPF_FAIL
Posted by Noel Butler <no...@ausics.net>.
On 05/11/2020 21:54, Victor Sudakov wrote:
> An SPF fail is by no means a sure sign of spam. It can be some indicator
> of spamicity (as I thought), but not a decisive sign thereof.
SPF was never designed to be anti-spam, although on face value it does
have that ability given that spammers impersonate domains, it is one of
many tools required required in that battle.
I was an early adopter of SPF, in its very very early stages, There are
some rare instances in early days where SPF may break in some forwarding
cases, but for well over a decade most forwarders re-write sender so its
not a problem, it's never been a problem with mailing lists for me
either, unlike DKIM, I've never experienced any deliverability problems
due to SPF, but YMMV.
Microsofts SRS however gave a lot of headaches with mailing lists and
was such a flop even Microsoft advises against its use.
> doubt the wizdom of rejecting hard SPF fails in the MTA
Why? Because a handful of people are too clueless to keep their records
up to date? They set those records in first place to prevent spoofing,
they know the risks they know if they change AS's or suppliers they have
to modify those records, I mean FFS, they change all other records to
new IP's don't they, so frankly they get what they deserve if they can't
be bothered.
>> i just think default score is made for spamass milter users with do rejects
>> of spam mails, but why not honner spf fail rejections, hmm
If they set a softfail, they dont really care if that domains is
spoofed, or it just isn't an important domain, I adjust my SA rules to
force softfails as spam , I hard reject hardfails on MTA, and I also
null out any and all whitelisting in SA,
trust must be earned, not assumed.
--
Regards,
Noel Butler
This Email, including attachments, may contain legally privileged
information, therefore at all times remains confidential and subject to
copyright protected under international law. You may not disseminate
this message without the authors express written authority to do so. If
you are not the intended recipient, please notify the sender then delete
all copies of this message including attachments immediately.
Confidentiality, copyright, and legal privilege are not waived or lost
by reason of the mistaken delivery of this message.
Re: SPF_FAIL
Posted by Victor Sudakov <va...@sibptus.ru>.
Benny Pedersen wrote:
> Victor Sudakov skrev den 2020-11-04 15:47:
>
> > 0.0 SPF_FAIL SPF: sender does not match SPF record (fail)
>
> feel free to add into local.cf
>
> score SPF_FAIL (5) (5) (5) (5)
>
> this will add 5 points to default score
Is that sarcasm, Benny? I don't deserve it.
An SPF fail is by no means a sure sign of spam. It can be some indicator
of spamicity (as I thought), but not a decisive sign thereof.
Moreover, after reading other replies in the thread, I am even begining to
doubt the wizdom of rejecting hard SPF fails in the MTA (which I do in
some installations).
>
> i just think default score is made for spamass milter users with do rejects
> of spam mails, but why not honner spf fail rejections, hmm
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
Re: SPF_FAIL
Posted by Benny Pedersen <me...@junc.eu>.
Victor Sudakov skrev den 2020-11-04 15:47:
> 0.0 SPF_FAIL SPF: sender does not match SPF record (fail)
feel free to add into local.cf
score SPF_FAIL (5) (5) (5) (5)
this will add 5 points to default score
i just think default score is made for spamass milter users with do
rejects of spam mails, but why not honner spf fail rejections, hmm
Re: SPF_FAIL
Posted by Victor Sudakov <va...@sibptus.ru>.
RW wrote:
>
> Please don't hijack existing threads.
Oh, sorry about that.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
Re: SPF_FAIL
Posted by RW <rw...@googlemail.com>.
Please don't hijack existing threads.
On Wed, 4 Nov 2020 21:47:34 +0700
Victor Sudakov wrote:
> Dear Colleagues,
>
> Why does SpamAssassin (Debian 10, SpamAssassin 3.4.2) not count an SPF
> check fail as a symptom of spam? That's what I see in the spam
> report:
>
> 0.0 SPF_FAIL SPF: sender does not match SPF record
> (fail)
>
> No spam points for an SPF fail? And it's even a hard fail (a "-all")
> in this case.
>
> I can probably bump up the score for SPF_FAIL but would like to know
> first why it is a 0.0 by default. This was probably someone's
> well-grounded decision?
It was probably set a long time ago when the situation was worse, but
even now it doesn't do well in QA:
https://ruleqa.spamassassin.org/20201031-r1883012-n/SPF_FAIL/detail
With an S/O of 0.651 it's barely a spam indicator on its own. If you
look at the score map it's hitting a lot of ham that's not far below
the threshold (at least in score set 0).