On 10/21/2010 05:16 AM, Steve Jenkins wrote:
Jeroen Geilman said:
Make sure you understand the difference between
smtpd_reject_unknown_helo_hostname and
smtpd_reject_unknown_[reverse_]client_hostname.
Ok -- here's what I understand them each to be:
- reject_unknown_helo_hostname will reject a request if the remote
mail server doesn't have an A or MX record
Not quite.
It will reject the request if the client's HELO doesn't resolve to an
IP, i.e. it doesn't have a DNS A record, or isn't a valid hostname or IP
literal at all.
RFC 5321 details what an EHLO/HELO must look like:
http://tools.ietf.org/html/rfc5321#section-4.1.1
The above simply verifies that the parameter supplied by the client is,
in fact, RFC-compliant - by looking it up.
Postfix will perform many, many DNS lookups for each single message, so
running a nearby - or even local - caching nameserver is not a luxury;
it's highly recommended.
- reject_unknown_client_hostname will reject if a) the remote server
fails a reverse lookup (IP points to name), b) fails a forward lookup
(name resolves to IP), or c) if the published DNS settings for the
hostname state that the IP for the hostname is different than what the
remote server is reporting it to be.
I get a headache trying to read that, but that's not your fault; the
original and similar explanation in postconf(5) also gives me a headache :)
- reject_unknown_reverse_client_hostname is less restrictive and will
reject only if the remove server fails a reverse lookup.
Yup.
reject_unknown_client_hostname is fine for MXen and large providers, but
it will hurt simple relaying with many false positives.
So here are my current "spam fighting" settings, based on the input
from this list:
smtpd_helo_required = yes
disable_vrfy_command = yes
smtpd_recipient_restrictions =
permit_sasl_authenticated,
permit_mynetworks,
reject_unauth_destination,
reject_unknown_reverse_client_hostname,
warn_if_reject reject_non_fqdn_helo_hostname,
warn_if_reject reject_invalid_helo_hostname,
warn_if_reject reject_unknown_helo_hostname,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
check_helo_access hash:/etc/postfix/helo_access,
check_client_access pcre:/etc/postfix/fqrdns.pcre,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client psbl.surriel.com,
reject_rhsbl_client dbl.spamhaus.org,
reject_rhsbl_sender dbl.spamhaus.org,
reject_rhsbl_helo dbl.spamhaus.org,
permit
Looking good - you even ordered them to reject as much as possible as
soon as possible, AND in order of increasing cost.
I noticed Jeroen's smtpd_recipient_restrictions included
reject_unauth_pipelining, but from what I can tell in the docs I'm
supposed to put it in smtpd_data_restrictions. Am I misunderstanding that?
This http://www.postfix.org/postconf.5.html#reject_unauth_pipelining
indicates that older postfix versions needed that to go in the data
restrictions.
You don't have an older version, so that is not required.
Spammers who won't wait for permission to send pipelined commands will
probably do other naughty things as well - why wait to reject them ?
Just put every single restriction you can think of in your
recipient_restrictions, and maybe lower your hard_error_limit a bit,
too, to enforce your stance on unauth pipelining :)
Unauth pipelining will only reject one message at a time (taking the
pipeline sequence into account), but hitting your hard_error limit
disconnects the client - which is probably what you want when a spammer
starts sending megabytes of pipelined crap your way :)
--
J.
