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
