SPF

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

SPF

richard lucassen
Why is "policyd-spf":

smtpd_recipient_restrictions =
  reject_unauth_destination
  reject_unverified_recipient
  check_policy_service unix:private/policyd-spf

set under smtpd_recipient_restrictions and not under
smtpd_sender_restrictions? It works fine when set under
smtpd_recipient_restrictions but did I miss something crucial somewhere?

R.

--
richard lucassen
http://contact.xaq.nl/
Reply | Threaded
Open this post in threaded view
|

Re: SPF

Scott Kitterman-4


On February 4, 2017 7:44:07 AM EST, richard lucassen <[hidden email]> wrote:

>Why is "policyd-spf":
>
>smtpd_recipient_restrictions =
>  reject_unauth_destination
>  reject_unverified_recipient
>  check_policy_service unix:private/policyd-spf
>
>set under smtpd_recipient_restrictions and not under
>smtpd_sender_restrictions? It works fine when set under
>smtpd_recipient_restrictions but did I miss something crucial
>somewhere?
>
>R.

http://www.postfix.org/SMTPD_ACCESS_README.html#timing

Scott K
Reply | Threaded
Open this post in threaded view
|

Re: SPF

richard lucassen
On Sat, 04 Feb 2017 15:29:10 +0000
Scott Kitterman <[hidden email]> wrote:

> >Why is "policyd-spf":
> >
> >smtpd_recipient_restrictions =
> >  reject_unauth_destination
> >  reject_unverified_recipient
> >  check_policy_service unix:private/policyd-spf
> >
> >set under smtpd_recipient_restrictions and not under
> >smtpd_sender_restrictions? It works fine when set under
> >smtpd_recipient_restrictions but did I miss something crucial
> >somewhere?
>
> http://www.postfix.org/SMTPD_ACCESS_README.html#timing

Ok, so there is no reason anymore to use all these separate
smtpd_*_restrictions, I will just use smtpd_recipient_restrictions
as clearly stated here:

http://www.akadia.com/services/postfix_uce.html

That's right isn't it?

R.

--
richard lucassen
http://contact.xaq.nl/
Reply | Threaded
Open this post in threaded view
|

Re: SPF

richard lucassen
On Sat, 4 Feb 2017 18:04:22 +0100
richard lucassen <[hidden email]> wrote:

> > http://www.postfix.org/SMTPD_ACCESS_README.html#timing
>
> Ok, so there is no reason anymore to use all these separate
> smtpd_*_restrictions, I will just use smtpd_recipient_restrictions
> as clearly stated here:
>
> http://www.akadia.com/services/postfix_uce.html
>
> That's right isn't it?

Apparently not:

http://www.postfix.org/SMTPD_ACCESS_README.html#danger

--
richard lucassen
http://contact.xaq.nl/
Reply | Threaded
Open this post in threaded view
|

Re: SPF

Peter Ajamian
On 05/02/17 07:00, richard lucassen wrote:

>> Ok, so there is no reason anymore to use all these separate
>> smtpd_*_restrictions, I will just use smtpd_recipient_restrictions
>> as clearly stated here:
>>
>> http://www.akadia.com/services/postfix_uce.html
>>
>> That's right isn't it?
>
> Apparently not:
>
> http://www.postfix.org/SMTPD_ACCESS_README.html#danger

The issue happens when you have a PERMIT result before other tests that
you want to run that might result in REJECT.  The PERMIT bypasses
further tests.

There are many solutions to this.  One is to make sure not to use PERMIT
unless you really do mean to bypass further restriction tests.  Use
DUNNO instead.

Another thing that helps is to keep your restrictions separate from your
port 25 MX traffic vs your port 587 submission traffic.  Don't put
submission restrictions such as permit_sasl_authenticated or
permit_mynetworks in main.cf or your smtp line in master.cf, and don't
put restrictions that are meant for port 25 such as
reject_unauth_destination in your submission line for master.cf.  When
you keep these separate then things become much easier to manage.


Peter

Reply | Threaded
Open this post in threaded view
|

Re: SPF

richard lucassen
On Sun, 5 Feb 2017 12:44:07 +1300
Peter <[hidden email]> wrote:

> > http://www.postfix.org/SMTPD_ACCESS_README.html#danger
>
> The issue happens when you have a PERMIT result before other tests
> that you want to run that might result in REJECT.  The PERMIT bypasses
> further tests.
>
> There are many solutions to this.  One is to make sure not to use
> PERMIT unless you really do mean to bypass further restriction
> tests.  Use DUNNO instead.

ok

> Another thing that helps is to keep your restrictions separate from
> your port 25 MX traffic vs your port 587 submission traffic.  Don't
> put submission restrictions such as permit_sasl_authenticated or
> permit_mynetworks in main.cf or your smtp line in master.cf, and don't
> put restrictions that are meant for port 25 such as
> reject_unauth_destination in your submission line for master.cf.  When
> you keep these separate then things become much easier to manage.

These are incoming mailservers, no MUA's connecting to these servers. I
have these particular settings now:

smtpd_relay_restrictions =
  permit_mynetworks
  reject_unauth_destination

smtpd_recipient_restrictions =
  reject_unauth_destination
  reject_unverified_recipient
  check_policy_service unix:private/policyd-spf

smtpd_sender_restrictions =
  reject_non_fqdn_sender
  reject_unknown_sender_domain
  check_sender_access hash:/etc/postfix/hash-tables/sender_access



Apart from that, I deinstalled postgrey and started to use postscreen,
which seems to be a good deal :) I use these settings, maybe someone
can comment these:

postscreen_greet_action = ignore
postscreen_greet_banner = Spammers may talk now :)

postscreen_access_list =
  permit_mynetworks
  cidr:/etc/postfix/hash-tables/postscreen_access

postscreen_blacklist_action = enforce
postscreen_dnsbl_action = drop
postscreen_dnsbl_threshold = 1
postscreen_dnsbl_whitelist_threshold = -1
postscreen_dnsbl_sites =
  zen.spamhaus.org*2
  bl.spamcop.net*2
  list.dnswl.org=127.0.[0..255].0*-1
  list.dnswl.org=127.0.[0..255].1*-2
  list.dnswl.org=127.0.[0..255].2*-3
  list.dnswl.org=127.0.[0..255].3*-4

postscreen_pipelining_action = enforce
postscreen_pipelining_enable = yes

postscreen_non_smtp_command_action = enforce
postscreen_non_smtp_command_enable = yes

postscreen_bare_newline_action = enforce
postscreen_bare_newline_enable = yes

R.

--
richard lucassen
http://contact.xaq.nl/
Reply | Threaded
Open this post in threaded view
|

Antispamming with header checks and regexp

Istvan Prosinger
In reply to this post by richard lucassen
Hi All, and Happy New Year with a little delay :)

Comming to spam, header checks are one tool that I use frequently to
prevent it.

So, amongst all, I have this:

if !/^Subject: (.*)[Aa]liexpress/
/^Subject:(.*)% [Oo][Ff][Ff]/ REJECT Go away spammer
endif

And this worked fine until _today_, when I got one email (and it wasn't
from Ali) that had a subject:

You’re In Luck | Up to 70% Off

As for the regexp, I think this should definitely be a hit, but it got
thru. First I thought that something bugged because of the | sign, but no.
I've sent several tests from an external account and it's geting thru.

I need a 4-eye method - what the heck am I missing here?

Best,
Istvan



Reply | Threaded
Open this post in threaded view
|

Re: Antispamming with header checks and regexp

Dominic Raferd


On 6 February 2017 at 21:23, Istvan Prosinger <[hidden email]> wrote:
Hi All, and Happy New Year with a little delay :)

Comming to spam, header checks are one tool that I use frequently to prevent it.

So, amongst all, I have this:

if !/^Subject: (.*)[Aa]liexpress/
/^Subject:(.*)% [Oo][Ff][Ff]/ REJECT Go away spammer
endif

And this worked fine until _today_, when I got one email (and it wasn't from Ali) that had a subject:

You’re In Luck | Up to 70% Off

As for the regexp, I think this should definitely be a hit, but it got thru. First I thought that something bugged because of the | sign, but no.
I've sent several tests from an external account and it's geting thru.

I need a 4-eye method - what the heck am I missing here?


​Try removing the round brackets...​

Reply | Threaded
Open this post in threaded view
|

Re: Antispamming with header checks and regexp

Noel Jones-2
In reply to this post by Istvan Prosinger
On 2/6/2017 3:23 PM, Istvan Prosinger wrote:

> Hi All, and Happy New Year with a little delay :)
>
> Comming to spam, header checks are one tool that I use frequently to
> prevent it.
>
> So, amongst all, I have this:
>
> if !/^Subject: (.*)[Aa]liexpress/
> /^Subject:(.*)% [Oo][Ff][Ff]/ REJECT Go away spammer
> endif
>
> And this worked fine until _today_, when I got one email (and it
> wasn't from Ali) that had a subject:
>
> You’re In Luck | Up to 70% Off
>
> As for the regexp, I think this should definitely be a hit, but it
> got thru. First I thought that something bugged because of the |
> sign, but no.
> I've sent several tests from an external account and it's geting thru.
>
> I need a 4-eye method - what the heck am I missing here?
>
> Best,
> Istvan
>
>
>

Oy, what an awkwardly awkward redundant expression that is up there
above.

Postfix regular expressions are case-insensitive by default, so the
[Aa] nonsense is unnecessary.  Encapsulating the wildcards with ()
is unnecessary unless you plan to use the result later.  The generic
"go away spammer" is useless for debugging your header_checks

much better:
if /^Subject: /
if !/aliexpress/
/% off/  REJECT percent off
endif
endif

and that could probably be further improved...

That said, your expression probably mostly works.

Remember that header_checks won't match encoded subjects, and only
one action is allowed per header, so if this header hits any prior
rules (such as a WARN, INFO, DUNNO) then it won't be rejected.




  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Antispamming with header checks and regexp

Istvan Prosinger
In reply to this post by Dominic Raferd
On 2017-02-06 22:56, Dominic Raferd wrote:

> On 6 February 2017 at 21:23, Istvan Prosinger <[hidden email]>
> wrote:
>
>> Hi All, and Happy New Year with a little delay :)
>>
>> Comming to spam, header checks are one tool that I use frequently to
>> prevent it.
>>
>> So, amongst all, I have this:
>>
>> if !/^Subject: (.*)[Aa]liexpress/
>> /^Subject:(.*)% [Oo][Ff][Ff]/ REJECT Go away spammer
>> endif
>>
>> And this worked fine until _today_, when I got one email (and it
>> wasn't from Ali) that had a subject:
>>
>> You’re In Luck | Up to 70% Off
>>
>> As for the regexp, I think this should definitely be a hit, but it
>> got thru. First I thought that something bugged because of the |
>> sign, but no.
>> I've sent several tests from an external account and it's geting
>> thru.
>>
>> I need a 4-eye method - what the heck am I missing here?
>
> ​Try removing the round brackets...​

Why?
Reply | Threaded
Open this post in threaded view
|

Re: Antispamming with header checks and regexp

Istvan Prosinger
In reply to this post by Noel Jones-2
On 2017-02-06 23:19, Noel Jones wrote:

> On 2/6/2017 3:23 PM, Istvan Prosinger wrote:
>> Hi All, and Happy New Year with a little delay :)
>>
>> Comming to spam, header checks are one tool that I use frequently to
>> prevent it.
>>
>> So, amongst all, I have this:
>>
>> if !/^Subject: (.*)[Aa]liexpress/
>> /^Subject:(.*)% [Oo][Ff][Ff]/ REJECT Go away spammer
>> endif
>>
>> And this worked fine until _today_, when I got one email (and it
>> wasn't from Ali) that had a subject:
>>
>> You’re In Luck | Up to 70% Off
>>
>> As for the regexp, I think this should definitely be a hit, but it
>> got thru. First I thought that something bugged because of the |
>> sign, but no.
>> I've sent several tests from an external account and it's geting thru.
>>
>> I need a 4-eye method - what the heck am I missing here?
>>
>> Best,
>> Istvan
>>
>>
>>
>
> Oy, what an awkwardly awkward redundant expression that is up there
> above.
>
> Postfix regular expressions are case-insensitive by default, so the
> [Aa] nonsense is unnecessary.  Encapsulating the wildcards with ()

This doesn't matter at all.

> That said, your expression probably mostly works.

Ha! That helped a lot. I aleady know that it "mostly works", it just
doesn't work in this case. I do respect your work on this list, bit you
have completely missed my point. I'm trying to understand what happend,
not looking for a "better suggestion".

> Remember that header_checks won't match encoded subjects, and only
> one action is allowed per header, so if this header hits any prior
> rules (such as a WARN, INFO, DUNNO) then it won't be rejected.

It didn't hit anything else prior to this rule.
Reply | Threaded
Open this post in threaded view
|

Re: Antispamming with header checks and regexp

Ralph Corderoy
Hi Istvan,

> Noel Jones wrote:
> > Remember that header_checks won't match encoded subjects

We need to see the raw Subject header from the email that failed to
match.  It was probably encoded.

    $ scan -forma '%{subject}' .
    =?UTF-8?B?VGhpcyBpcyBzcGFtLgo=?=
    $ scan -forma '%(decode{subject})' .
    This is spam.
    $ grep -i '^subject:' `mhpath .`
    Subject: =?UTF-8?B?VGhpcyBpcyBzcGFtLgo=?=
    $

It's to allow non-ASCII characters in the some of the headers, e.g.
Subject.

--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
Reply | Threaded
Open this post in threaded view
|

Re: Antispamming with header checks and regexp

Istvan Prosinger
On 2017-02-07 10:12, Ralph Corderoy wrote:

> Hi Istvan,
>
>> Noel Jones wrote:
>> > Remember that header_checks won't match encoded subjects
>
> We need to see the raw Subject header from the email that failed to
> match.  It was probably encoded.
>
>     $ scan -forma '%{subject}' .
>     =?UTF-8?B?VGhpcyBpcyBzcGFtLgo=?=
>     $ scan -forma '%(decode{subject})' .
>     This is spam.
>     $ grep -i '^subject:' `mhpath .`
>     Subject: =?UTF-8?B?VGhpcyBpcyBzcGFtLgo=?=
>     $
>
> It's to allow non-ASCII characters in the some of the headers, e.g.
> Subject.


Thanks for this. It's UTF-8, and indeed, it's encoded.
Now this puts on some limits on how to fight it.

Best,
Istvan