On 8/22/2010 11:42 AM, p...@alt-ctrl-del.org wrote:
On Sunday, August 22, 2010 at 16:01 CEST,
p...@alt-ctrl-del.org wrote:
So I have,
smtpd_helo_restrictions = reject_non_fqdn_helo_hostname,
check_helo_access regexp:/etc/postfix/heloaccess.cf
If I put the following into heloaccess.cf, for .cc hostnames,
/^.*\.[a-z][a-z]$/ reject_unknown_helo_hostname
Am I adding to the restrictions? Making it,
smtpd_helo_restrictions = reject_non_fqdn_helo_hostname,
check_helo_access regexp:/etc/postfix/heloaccess.cf,
reject_unknown_helo_hostname
Or am I replacing the restrictions? Making it only,
smtpd_helo_restrictions = reject_unknown_helo_hostname
On a hit of the regexp rule, would the existing
smtpd_sender_restrictions and smtpd_recipient_restrictions
still be processed?
Magnus Bäck put forth on 8/22/2010 10:04 AM:
A regexp match will cause the reject_unknown_helo_hostname
restriction
to be evaluated. If it indeed results in a rejection the
mail will be
rejected no matter what.
Stan Hoeppner wrote:
That's not necessarily true. It depends on the order of his
smtpd_*_restrictions and whether he's using delayed
evaluation. If he's
using the multiple section restrictions style with delayed
eval it's
possible he may have an "OK" in a later table that causes
the mail to be
accepted even after the regexp check returned REJECT.
smtpd_delay_reject = on
smtpd_helo/client/recipient/sender_restrictions are all defined.
Reading RESTRICTION_CLASS_README confused me as to whether
adding a Restriction (or a defined smtpd_restriction_classes
group), to the right side of an access table, would be done in
Addition-To or In-Place-Of the already existing
smtpd_helo/client/recipient/sender_restrictions.
Think of a restriction class as a single restriction. If
there is no match for the whole class (or DUNNO), control
returns to the next restriction you've defined; OK skips to
the next smtpd_*_restrictions section; REJECT will reject the
mail.
What i'm getting out of the responses so far is: If there's
not an OK or PERMIT in my additional restriction or class
group, all of the existing
smtpd_helo/client/recipient/sender_restrictions will still be
applied.
Right?
An OK or PERMIT in smtpd_helo_restrictions only skips
additional smtpd_helo_restrictions.
Postfix will always continue on to smtpd_sender_restrictions.
If smtpd_sender_restrictions result in no match or OK,
postfix continues to smtpd_recipient_restrictions. And so on
for data and end-of-data.
If there is a REJECT anywhere in the sequence, the mail is
rejected as soon as postfix evaluates that rule.
So for widely used and well defined domain mail servers like
comcast.net, I could use a more restrictive rule like:
/^.*\.comcast.net$/ reject_unknown_client_hostname
It's unclear from the context, but I assume you mean "if the
HELO says comcast, reject unknown client". Yes, that's valid.
Your regexp can be shortened to
/\.comcast\.net$/ reject_unknown_client
?Or maybe even chain rules together?
check_helo_access regexp:/etc/postfix/heloaccess
/^.*\.comcast.net$/ check_reverse_client_hostname_access
regexp:/etc/postfix/comcast
You can't have an access table directly call another access
table. Use a restriction class when you need nested lookups.
With /etc/postfix/comcast containing:
/qmta01.emeryville.ca.mail.comcast.net/ DUNNO
/qmta02.emeryville.ca.mail.comcast.net/ DUNNO
/etc...mail.comcast.net DUNNO
/.*/ REJECT
IF /\.comcast\.net$/
/\.mail\.comcast\.net$/ DUNNO
/^/ REJECT
ENDIF
(This is only safe as long as comcast consistently identifies
their servers in this manner.)
-- Noel Jones
