Mailing List Archive: SpamAssassin: users

Spamassassin and SPF records with "+all"

1 2

View All

Index | Next | Previous | View Threaded

martin at gregorie

Jul 12, 2012, 1:37 PM

Post #26 of 36 (503 views)
Permalink

Re: Spamassassin and SPF records with "+all" [In reply to]

On Thu, 2012-07-12 at 12:17 -0700, John Hardin wrote:
> On Thu, 12 Jul 2012, Martin Gregorie wrote:
>
> > I'd suggest that any SPF record containing '+all' and possibly '?all'
> > too, should trigger an SPF_PERMISSIVE rule rather than SPF_PASS so we
> > can distinguish an authorised server in a tightly controlled domain from
> > servers claiming to be part of a domain that doesn't give a damn.
>
> ...which is pretty much where we started. :)
>
True enough. I just wanted to provide a concrete example of extra stuff
the plug-in could do and why that could be useful. It hadn't occurred to
me until just now that SPF_PASS can be triggered by slovenly and/or
careless SPF configurations as well as by careful set-ups and that this
fact prevents you assigning any spam-related value to an SPF_PASS
indication and reinforces my argument about SPF being useful against
backscatter and not much else.

Martin

dfs at roaringpenguin

Jul 13, 2012, 1:57 AM

Post #27 of 36 (499 views)
Permalink

Re: Spamassassin and SPF records with "+all" [In reply to]

On Thu, 12 Jul 2012 21:37:36 +0100
Martin Gregorie <martin [at] gregorie> wrote:

> True enough. I just wanted to provide a concrete example of extra
> stuff the plug-in could do and why that could be useful. It hadn't
> occurred to me until just now that SPF_PASS can be triggered by
> slovenly and/or careless SPF configurations as well as by careful
> set-ups and that this fact prevents you assigning any spam-related
> value to an SPF_PASS indication and reinforces my argument about SPF
> being useful against backscatter and not much else.

SPF has *never* been advocated as an anti-spam measure by the people
who developed it.

And looking for +all or ?all is not enough; you can easily simulate
+all with ip4:0.0.0.0/1 ip4:128.0.0.0/1 or countless other combinations.

So I think my stance will be proven correct: In general, one should
only ever penalize domains for failing SPF. You should never treat an
SPF "pass" as something good except for specific trusted domains.

Regards,

David.

Bowie_Bailey at BUC

Jul 13, 2012, 7:04 AM

Post #28 of 36 (509 views)
Permalink

Re: Spamassassin and SPF records with "+all" [In reply to]

On 7/13/2012 4:57 AM, David F. Skoll wrote:
> On Thu, 12 Jul 2012 21:37:36 +0100
> Martin Gregorie <martin [at] gregorie> wrote:
>
>> True enough. I just wanted to provide a concrete example of extra
>> stuff the plug-in could do and why that could be useful. It hadn't
>> occurred to me until just now that SPF_PASS can be triggered by
>> slovenly and/or careless SPF configurations as well as by careful
>> set-ups and that this fact prevents you assigning any spam-related
>> value to an SPF_PASS indication and reinforces my argument about SPF
>> being useful against backscatter and not much else.
> SPF has *never* been advocated as an anti-spam measure by the people
> who developed it.
>
> And looking for +all or ?all is not enough; you can easily simulate
> +all with ip4:0.0.0.0/1 ip4:128.0.0.0/1 or countless other combinations.
>
> So I think my stance will be proven correct: In general, one should
> only ever penalize domains for failing SPF. You should never treat an
> SPF "pass" as something good except for specific trusted domains.

An SPF pass should not be generally treated as good, but in this case,
an SPF pass on a domain with an overly-permissive SPF record could be
treated as bad. Of course, it would need to be mass-checked to make
sure it doesn't hit too many hams.

Looking for +all could be a starting place. Other patterns could be
added as they are found in spammy domains.

--
Bowie

jhardin at impsec

Jul 13, 2012, 7:33 AM

Post #29 of 36 (503 views)
Permalink

Re: Spamassassin and SPF records with "+all" [In reply to]

On Fri, 13 Jul 2012, David F. Skoll wrote:

> SPF has *never* been advocated as an anti-spam measure by the people
> who developed it.

Agreed, but that does not mean under certain circumstances it cannot be
useful as a spam indicator.

> And looking for +all or ?all is not enough; you can easily simulate
> +all with ip4:0.0.0.0/1 ip4:128.0.0.0/1 or countless other combinations.

If checking for +all is justified then checking for */1 through */8 would
probably also be justified, perhaps with firing different rule so that a
different score could be applied.

> So I think my stance will be proven correct: In general, one should
> only ever penalize domains for failing SPF. You should never treat an
> SPF "pass" as something good except for specific trusted domains.

So does that mean it may be legitimate to treat an SPF PASS as "something
bad" if the SPF rule is defined in an "abusive" manner?

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin [at] impsec FALaholic #11174 pgpk -a jhardin [at] impsec
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Activist: Someone who gets involved.
Unregistered Lobbyist: Someone who gets involved with something
the MSM doesn't approve of. -- WizardPC
-----------------------------------------------------------------------
3 days until the 67th anniversary of the dawn of the Atomic Age

dfs at roaringpenguin

Jul 13, 2012, 8:02 AM

Post #30 of 36 (502 views)
Permalink

Re: Spamassassin and SPF records with "+all" [In reply to]

On Fri, 13 Jul 2012 07:33:34 -0700 (PDT)
John Hardin <jhardin [at] impsec> wrote:

> So does that mean it may be legitimate to treat an SPF PASS as
> "something bad" if the SPF rule is defined in an "abusive" manner?

Absolutely. If you do not want to receive mail from a certain
domain and it passes SPF, then there's pretty good evidence the
mail really *is* from that domain and that you can apply your
domain policy.

Regards,

David.

me at junc

Jul 13, 2012, 8:48 AM

Post #31 of 36 (504 views)
Permalink

Re: Spamassassin and SPF records with "+all" [In reply to]

Den 2012-07-13 16:33, John Hardin skrev:

> So does that mean it may be legitimate to treat an SPF PASS as
> "something bad" if the SPF rule is defined in an "abusive" manner?

meta __META_DNSWL_ANY (RCVD_IN_DNSWL_HI || RCVD_IN_DNSWL_MED ||
RCVD_IN_DNSWL_LOW)

meta META_SPF_DNSWL (__META_DNSWL_ANY && SPF_PASS)
describe META_SPF_DNSWL Meta: spf pass and listed in dnswl safe
score META_SPF_DNSWL -0.5
# optional disable autolearn bayes on this rule

feel free to test SPF_HELO_PASS aswell

i left out RCVD_IN_DNSWL_NONE this is intended here

me at junc

Jul 13, 2012, 8:51 AM

Post #32 of 36 (503 views)
Permalink

Re: Spamassassin and SPF records with "+all" [In reply to]

Den 2012-07-13 17:02, David F. Skoll skrev:

> Absolutely. If you do not want to receive mail from a certain
> domain and it passes SPF, then there's pretty good evidence the
> mail really *is* from that domain and that you can apply your
> domain policy.

bingo, if more recipients do this +all will change to -all soon :=)

martin at gregorie

Jul 13, 2012, 9:08 AM

Post #33 of 36 (505 views)
Permalink

Re: Spamassassin and SPF records with "+all" [In reply to]

On Fri, 2012-07-13 at 07:33 -0700, John Hardin wrote:
>
---->snippage

> If checking for +all is justified then checking for */1 through */8 would
> probably also be justified, perhaps with firing different rule so that a
> different score could be applied.
>
---->more snippage

> So does that mean it may be legitimate to treat an SPF PASS as "something
> bad" if the SPF rule is defined in an "abusive" manner?
>
I think we'd get more flexibility by calling these something like
SPF_PERMISSIVE rather than lumping them into an existing 'bad' category,
but it could have the same default score as SPF_FAIL and be linked to
the same standard meta-rules. This way the change wouldn't affect
default SA behaviour but, if they wish, people can still adjust its
score and/or use it as a more specific component meta-rules.

Martin

jhardin at impsec

Jul 13, 2012, 10:33 AM

Post #34 of 36 (506 views)
Permalink

Re: Spamassassin and SPF records with "+all" [In reply to]

On Fri, 13 Jul 2012, Martin Gregorie wrote:

> On Fri, 2012-07-13 at 07:33 -0700, John Hardin wrote:
>>
> ---->snippage
>
>> If checking for +all is justified then checking for */1 through */8 would
>> probably also be justified, perhaps with firing different rule so that a
>> different score could be applied.
>>
> ---->more snippage
>
>> So does that mean it may be legitimate to treat an SPF PASS as "something
>> bad" if the SPF rule is defined in an "abusive" manner?
>
> I think we'd get more flexibility by calling these something like
> SPF_PERMISSIVE rather than lumping them into an existing 'bad' category,

Agreed. I was speculating that multiple variants of SPF_PERMISSIVE might
be justified, e.g. SPF_PERMISSIVE_ALL, SPF_PERMISSIVE_1, SPF_PERMISSIVE_8,
etc. However, it is only speculation; I have no data to support that
level of complexity being useful.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin [at] impsec FALaholic #11174 pgpk -a jhardin [at] impsec
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Liberals love sex ed because it teaches kids to be safe around their
sex organs. Conservatives love gun education because it teaches kids
to be safe around guns. However, both believe that the other's
education goals lead to dangers too terrible to contemplate.
-----------------------------------------------------------------------
3 days until the 67th anniversary of the dawn of the Atomic Age

Giampaolo at Tomassoni

Jul 13, 2012, 10:44 AM

Post #35 of 36 (500 views)
Permalink

RE: Spamassassin and SPF records with "+all" [In reply to]

> From: John Hardin [mailto:jhardin [at] impsec]
>
> Agreed. I was speculating that multiple variants of SPF_PERMISSIVE
> might be justified, e.g. SPF_PERMISSIVE_ALL, SPF_PERMISSIVE_1,
> SPF_PERMISSIVE_8, etc. However, it is only speculation; I have no
> data to support that level of complexity being useful.

Why not use Net::CIDR::Lite for this?

Our hypothetic plugin could merge together CIDRs via Net::CIDR::Lite->add()
and get the resultant merged, non-overlapping CIDRs via ->list(), then count
the size of the allowed addresses (via something like 2^(32 - cidr_prefix))
and fire rules like the ones you suggest.

Giampaolo

me at junc

Jul 13, 2012, 10:56 AM

Post #36 of 36 (501 views)
Permalink

RE: Spamassassin and SPF records with "+all" [In reply to]

Den 2012-07-13 19:44, Giampaolo Tomassoni skrev:

> Our hypothetic plugin could merge together CIDRs via
> Net::CIDR::Lite->add()
> and get the resultant merged, non-overlapping CIDRs via ->list(),
> then count
> the size of the allowed addresses (via something like 2^(32 -
> cidr_prefix))
> and fire rules like the ones you suggest.

so it fire if more then one ip is in spf ?, lets say more points if
more ips ?

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads