On 10/2/2009 11:51 AM, Stan Hoeppner wrote:
Noel Jones put forth on 10/2/2009 10:54 AM:
On 10/2/2009 10:05 AM, Stan Hoeppner wrote:
Hi all,

I just had a viagra spam from gprs4f7a24e6.pool.t-umts.hu
(gprs4f7a24e6.pool.t-umts.hu [79.122.36.230] sneak past both of my pcre
checks which should have killed it.  Until today they've been working
flawlessly, or so I believe, and I have ample log entries showing
they've been working.  Here are my checks, both performed via
smtpd_client_restrictions but without explicit check_client_access:

smtpd_client_restrictions =
          pcre:/etc/postfix/access.pcre,
          pcre:/etc/postfix/check_client_fqdn.pcre

Better to use the proper syntax (although that's not the problem).

Acknowledged.

smtpd_client_restrictions =
   check_client_access pcre:/etc/postfix/access.pcre
   check_client_access pcre:/etc/postfix/check_client_fqdn.pcre

Any good excuse why these can't be combined into one pcre file?

Probably not.  I copy/pasted from examples I found at different points
in time.  I guess it just made sense at the time to start a new file for
the 2nd one.  Good idea though, I'll consolidate them.

/etc/postfix/access.pcre
/^.*?(lv|ec|id|ph|at|hu|tr|ee|pl|ro|my|co|tw|br|za|do|cz|bg|by|kr|jp|fr|cn|ru)$/i

550 We do not accept mail from .$1 domains

/\.(lv|ec|...|ru)$/  REJECT ...

Don't specify useless leading wildcards. Don't use the /i flag unless
you really need it - this might be why it didn't match.

I'll read up on regexes and see if I can clean that up.

And both your maps would be more effective if you use them with
check_reverse_client_hostname_access rather than check_client_access -
this might also be why it didn't match.  Requires postfix 2.6 or newer.
http://www.postfix.org/postconf.5.html#check_reverse_client_hostname_access

I'm on 2.3.8.  I always stick with my distro's packages, so my next rev
will only be up to 2.5.5-1.1 when I upgrade to Lenny (I'm running
Debian).  I've got some issues I need to work out before upgrading to
Lenny though.

/etc/postfix/check_client_fqdn.pcre
/\.?(dhcp|dialup|dynamic|ppp|pool)\.?/       REJECT
Dynamic/DSL/Residential not allowed
/\.(dsl|\d+dsl|dsl\d+)\./                    REJECT
Dynamic/DSL/Residential not allowed
<snip>>
test maps with postmap -q
http://www.postfix.org/postmap.1.html

# postmap -q key pcre:/etc/postfix/access.pcre

The key postfix used is in the mail log.

Thank you for the command Noel.  Using the current pcre's, testing shows:

greer:/etc/postfix# postmap -q gprs4f7a24e6.pool.t-umts.hu
pcre:/etc/postfix/access.pcre
550 We do not accept mail from .hu domains

greer:/etc/postfix# postmap -q gprs4f7a24e6.pool.t-umts.hu
pcre:/etc/postfix/check_client_fqdn.pcre
REJECT Dynamic/DSL/Residential not allowed

Just as I thought.  It should have been working.  Any ideas on why I'd
have a temp failure with pcre checks?  As I said before, this is the
first and only time this has happened.  I've got 74 rejects in the mail
log for check_client_fqdn.pcre, and I've got 112 for access.pcre.  The
most recent reject I have for either is early this morning:

Oct  2 03:35:42 greer postfix/smtpd[23597]: NOQUEUE: reject: RCPT from
94-43-142-94.dsl.utg.ge[94.43.142.94]: 554 5.7.1
<94-43-142-94.dsl.utg.ge[94.43.142.94]>: Client host rejected:
Dynamic/DSL/Residential not allowed; from=<s...@hardwarefreak.com>
to=<s...@hardwarefreak.com>  proto=SMTP helo=<94.43.142.94>

so we know at least one pcre check was working as of 3:35am CDT today
Oct 2.  The mail that sneaked through was at 6:39am CDT today Oct 2.

I'll keep an eye on the log throughout the day to see if the PCREs are
working.  My mail flow is small and sporadic, so it may take a bit to
see evidence of what is, or is not, happening.

Has anyone ever head of temporary pcre processing failures?

This issue has really got me stumped...

--
Stan



Was the mail addressed to postmaster? The postmaster address gets a free ride in some versions of postfix. To disable that loophole, set in main.cf:
address_verify_sender = $double_bounce_sender

If you need further help, show "postconf -n" output, logging of the offending mail passing through postfix, and headers from the mail.


  -- Noel Jones

Reply via email to