On 11/12/2009 10:09 PM, Alex wrote:
Hi,
If you don't want to whitelist the IP address completely but instead just
want to allow it to bypass your HELO checks, then check_helo_access will
work. However, you should first understand that the type of lookup performed
depends on the name of the restriction, NOT where the restriction is placed.
For example, as was mentioned before, check_client_access looks up the
"client" (hostname, IP address,...). Likewise, check_sender_access looks up
the envelope sender, domain, etc. In this case, check_helo_access is going
to look up the HELO hostname of the client.
But helo is a component of the envelope, no? Wouldn't it then make
sense to have it in sender_checks?
On 11/13/2009 1:30 AM, LuKreme wrote:
> On 12-Nov-2009, at 21:09, Alex wrote:
>> But helo is a component of the envelope, no?
>
> No.
>
Technically, the envelop is only the sender and receiver.
However, for purposes of this list we commonly also include
the client IP/hostname and HELO in discussions of envelope data.
So you do finely get that "yes and no" answer you've been
looking for. ;)
At any rate, you miss the point.
The smtpd_{client, helo, sender, recipient}_restrictions are
about *when* a check takes place, corresponding to the {client
connection, HELO, MAIL FROM, RCPT TO} stage of the SMTP
transaction.
(The *when* is altered by the smtpd_delay_reject (default yes)
which delays all those restrictions from running until the
client sends RCPT TO. This was added as a feature and as a
default after it was discovered that some clients react badly
to being rejected prior to RCPT TO. It also has the
beneficial side effect that you get more complete logging of
rejected transactions. But this is distracting from your issue.)
The check_{client, helo, sender, recipient}_access tests look
for something in a list, and if the something is found, do
that function. You have to tell postfix /what/ to look for by
specifying client, helo, sender, or recipient.
So, for example, if you tell postfix to look for the client IP
in a table by using check_client_access, you don't want to put
a HELO name or a sender address in the table -- it will never
match.
Okay, just tried that from a test network, and it doesn't work for me.
In helo_checks.pcre I have:
/^inside.testdomain.com$/ DUNNO
/./ reject_invalid_helo_hostname
There is no reject_invalid_helo_hostname in postfix 1.1. If
that table was used, you would have received a server
configuration error and the mail would have been deferred with
a 421 code.
I've reloaded postfix and performed the same steps as I have
previously, and it produces this in the logs:
Nov 12 22:48:51 smtp01 postfix/smtpd[6860]: reject: RCPT from albert.testdomain
.com[192.168.1.99]: 504<alex>: Helo command rejected: need fully-qualified hos
tname; from=<a...@testdomain.com> to=<a...@testdomain.com>
To follow up with Noel's post,
You use check_client_access because your table contains a client IP. If your
table
contained the actual bad HELO name you could use check_helo_access, but
generally
it's better to whitelist by client address.
Does that conflict with what Michael was saying about not allowing IP
addresses in access files, or am I misunderstanding what Michael was
saying?
Eh? I didn't see anything about not allowing IPs.
Assuming we do know that the helo would consistently be "alex123" for
test purposes, I could somehow configure the helo_access to permit
based on that string?
Yes, you can whitelist the specific bad helo. However, it's
generally better to whitelist a client (verified property
unique to that client) rather than a helo or sender address
(something easily forged).
Below is the postconf -n. Thanks very much for analyzing it for me.
Actually, I didn't want to be presumptuous, but it probably would have
been quicker in the end :-)
alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
alternate_config_directories = /etc/postfix_f
always_bcc =
biff = no
body_checks = regexp:/etc/postfix/body_checks
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
default_process_limit = 120
delay_warning_time = 0
disable_mime_input_processing = yes
disable_vrfy_command = yes
enabled = yes
fallback_relay =
header_checks = pcre:/etc/postfix/header_checks
mail_owner = postfix
mailbox_command = /usr/bin/procmail
mailbox_size_limit = 256000000
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maps_rbl_domains =
zen.spamhaus.org
cbl.abuseat.org
sbl.spamhaus.org
pbl.spamhaus.org
zen.spamhaus.org already includes both sbl.spamhaus.org and
pbl.spamhaus.org.
maximal_queue_lifetime = 5d
message_size_limit = 13312000
mime_header_checks =
minimal_backoff_time = 800s
mydestination = $myhostname, localhost.$mydomain
myhostname = smtp01.testdomain.com
mynetworks = 127.0.0.0/8, 192.168.161.45/32, 192.168.174.45/32, 192.168.227.0/24
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
queue_run_delay = 800s
No good reason for 800s unless you routinely have thousands of
deferred messages.
readme_directory = /etc/postfix/README_FILES
relay_domains = $mydestination, testdomain.com
Do you really want $mydestination in relay_domains? It's a
default setting for compatibility, but usually should be removed.
relayhost =
sample_directory = /etc/postfix/samples
sender_canonical_maps =
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_recipient_restrictions =
reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unknown_sender_domain
reject_unknown_recipient_domain
reject_unauth_pipelining
Probably should move reject_unauth_pipelining after
permit_mynetworks. You generally don't want to reject mail
from authorized users just because they have a crappy mail client.
permit_mynetworks
This is where your check_client_access whitelist should go --
before reject_non_fqdn_hostname.
reject_invalid_hostname
reject_non_fqdn_hostname
reject_unauth_destination
check_helo_access hash:/etc/postfix/helo_checks
check_recipient_access pcre:/etc/postfix/recipient_checks
check_sender_access hash:/etc/postfix/sender_checks
check_client_access hash:/etc/postfix/client_checks
reject_maps_rbl
transport_maps = hash:/etc/postfix/transport
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
virtual_maps = hash:/etc/postfix/virtual
Looks reasonable. I think you're simply putting the
restrictions in the wrong order, and when it didn't work you
focused on your client/helo/sender confusion. After that, you
tried so many bogus things you didn't know which way was up.
Restrictions within each smtpd_*_restrictions section are
evaluated in the order you give, so the whitelist table must
go before whatever would reject the mail.
Use a check_client_access table at the position I indicated
above. (using your example log entry from above):
> Nov 12 22:48:51 smtp01 postfix/smtpd[6860]: reject: RCPT
from albert.testdomain
> .com[192.168.1.99]: 504<alex>: Helo command rejected: need
fully-qualified hos
> tname; from=<a...@testdomain.com> to=<a...@testdomain.com>
The whitelist would contain
192.168.1.99 OK
-- Noel Jones
