mouss put forth on 12/16/2009 5:52 PM:
> 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).
Yeah, I know what they are. I'm just curious as to why I'm seeing so
many more of them. I guess it due to the reordering of the smtpd checks?
> 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...).
I posted main.cf instead of postconf -n because my changes are all about
order and location of smtpd_foo_restrictions checks. As you allude to
below, postconf -n reorders the output into alphabetical order. As I
understand it, the order of checks within smtpd_recipient_restrictions
is *critical* once you consolidate all smtpd_foo_restrictions here. If
I am incorrect here, I'll gladly provide postconf -n.
>> 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.
Noted. So, to use reject_unauth_pipelining, I'd still need an
smtpd_client_restrictions section containing this one option? Not all
things can be consolidated under smtpd_recipient_restrictions?
>> # 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.
I have two spam trap addresses in my whitelist. I want all mail to
those addresses sent on through. If I move reject_non_fqdn_sender up
before the whitelist checks, I will potentially reject some spam
destined to the traps, no? In this case, is it better to leave this
check where it is?
> you can consider this start:
>
> smtpd_recipient_retsrictions =
> reject_non_fqdn_sender
> reject_non_fqdn_recipient
> permit_mynetworks
> permit_sasl_authenticated
> reject_unauth_destination
> ...
Is reject_non_fqdn_recipient cheaper than rejecting with
reject_unlisted_recipient? With delayed evaluation, is this check
needed? Also, I don't use sasl authentication.
> after this, you need to decide whether you accept some "misbehaviour"
> based on rcpt/client/sender or not.
I'm not sure what you mean here. Can you elaborate?
Thanks mouss.
--
Stan
