Stan Hoeppner a écrit :
> I finally consolidated all my smtpd_foo_restrictions into
> smtpd_recipient_restrictions, as many have suggested, mainly to get my
> whitelisting working properly/reliably. Since doing so, I've noticed a
> substantial increase in smtpd warnings. Is this smtpd warning increase
> a result of this consolidation, or something unrelated?
>
> Previously, I'd see a half dozen or so of these per day max. This is a
> very low volume (vanity) server, less than 1000 connects/day. I've got
> 42 warnings so far today and there are 7 hours left until midnight.
> This is way above "normal".
>
> Warnings
> --------
> smtpd (total: 42)
> 9 216.245.221.98: hostname 98-221-245-216.reverse.lstn.net
> verifi...
> 4 216.245.221.102: hostname 102-221-245-216.reverse.lstn.net
> veri...
> 2 200.68.116.133: hostname
> customer-static-68-116-133.iplannetwor...
> 2 189.30.140.183: hostname
> 189-30-140-183.dsl.ctame700.brasiltele...
> 2 121.247.196.18: hostname
> 121.247.196.18.Ahmedabad-dynamic-bb.vs...
> 2 71.245.50.36: address not listed for hostname jdtwebhost.com
> ...
> ...
>
these are rdns warnings. the usual stuff. they are good for
"information", because when you get other logs, you'll see "from
unknown[a.b.c.d]", so if you want the PTR, you can consolidate the
warning logs (I do this with a script because I want to see the PTR even
if it doesn't match).
>
> New main.cf relevant section. This Postfix is a firewall/gateway,
> 2.5.5-1-1 Debian. Main.cf sanity check requested.
>
Take a habit of sending the output of 'postconf -n'.
- it will show you what postfix sees, instead of what you think. in
particular, typos and "double defintions", ...
- it's alphabetically ordered. this makes it easier for us to "parse" it
(for example, I want o see relay_recipient_maps. with you message, I'm
forced to check all the lines...).
> myhostname = greer.hardwarefreak.com
> myorigin = hardwarefreak.com
> mydestination =
> local_recipient_maps =
> local_transport = error
> mynetworks = 192.168.100.0/24
> proxy_interfaces = 65.41.216.221
> relay_domains = hardwarefreak.com
> inet_interfaces = all
> disable_vrfy_command = yes
> message_size_limit = 10240000
> parent_domain_matches_subdomains =
> debug_peer_list smtpd_access_maps
> strict_rfc821_envelopes = yes
> header_checks = pcre:/etc/postfix/header_checks
> mime_header_checks = pcre:/etc/postfix/mime_header_checks
> smtpd_helo_required = yes
> cidr=cidr:/etc/postfix/cidr_files
> smtpd_recipient_restrictions =
> permit_mynetworks
> reject_unauth_destination
> # whitelist checks
> check_recipient_access hash:/etc/postfix/whitelist
> check_sender_access hash:/etc/postfix/whitelist
> check_client_access hash:/etc/postfix/whitelist
> # smtpd_client_restrictions =
> check_client_access pcre:/etc/postfix/ptr-tld.pcre
> check_client_access hash:/etc/postfix/blacklist
> check_client_access ${cidr}/countries
> check_client_access ${cidr}/spammer
> check_client_access ${cidr}/misc-spam-srcs
> reject_unknown_client_hostname
> reject_unauth_pipelining
this is useless. there is no "unauth pipelining" at RCPT TO stage.
> # smtpd_sender_restrictions =
> reject_non_fqdn_sender
put this one before. it's cheap and there's no point checking maps and
the like for mail that uses non fqdn addresses. smtp addresses must be
fqdn.
you can consider this start:
smtpd_recipient_retsrictions =
reject_non_fqdn_sender
reject_non_fqdn_recipient
permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
...
after this, you need to decide whether you accept some "misbehaviour"
based on rcpt/client/sender or not.
> # smtpd_helo_restrictions =
> reject_non_fqdn_helo_hostname
> reject_invalid_helo_hostname
> reject_unknown_helo_hostname
> # smtpd_recipient_restrictions =
> reject_unlisted_recipient
> reject_rbl_client zen.spamhaus.org
> check_policy_service inet:127.0.0.1:60000
>
> The comments don't exactly match the previous smtpd_foo_restrictions
> ordering, as I've moved permit_mynetworks and reject_unauth_destination
> to the top to prevent a possible open relay condition Wietse describes
> in the docs (hopefully I understood them correctly). The number and
> location of the whitelist checks has changed dramatically as well (the
> main reason for consolidating).
>
