Hi,
>> I've just set up a fedora14 box with postfix v2.7.3, and would like
>> to use procmail as the delivery agent.
>
> First let's ask, why procmail? This fall will mark a decade since the
> last procmail release in 2001. It appears that you only want to
I didn't realize dovecot had the sieve plugin. I have quite a few old
procmail recipes I'll need to convert.
> One comment: that's a long "postconf -n". Do you need all those
> settings?
I've spent nearly all of the last eight hours going through my
configuration and making sure I understand as much of it as possible.
This was a configuration ported from an older system that I'm finally
upgrading. It relays mail for several virtual domains, as well as
delivers some mail locally.
>> header_checks = pcre:/etc/postfix/header_checks.pcre
>
> Why header_checks? They don't do much.
I use it to reject some content based on the headers outright, but I
definitely don't use it like I used to. Amavis is better suited for
that, but rejecting nasty subjects without the spam processing
overhead is advantageous sometimes.
>> html_directory = no
>> inet_interfaces = all
>> mail_owner = postfix
>> mailbox_command = /usr/bin/procmail
>> mailbox_size_limit = 2000000000
>> mailq_path = /usr/bin/mailq
>> manpage_directory = /usr/share/man
>> maximal_queue_lifetime = 5d
>> message_size_limit = 10240000
>> mydestination = $myhostname, localhost.$mydomain
>
> Your mydestination does not include example.com, so the munged logs
> are not in agreement with the postconf output.
Yes, I've fixed that. I've move all of the virtual domains from
relay_domains as per the docs (except for the few that are actually
being relayed to another host), and created a virtual_alias_map for
them.
>> mydomain = inside.example.com
>> myhostname = mail02t.example.com
>> mynetworks = 127.0.0.0/8, 192.168.1.0/24, 192.168.6.0/24
>> newaliases_path = /usr/bin/newaliases
>> queue_directory = /var/spool/postfix
>> rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps}
>> readme_directory = /usr/share/doc/postfix-2.7.3/README_FILES
>> relay_domains = $mydestination, $transport_maps
>
> This is potentially dangerous, such as if you get the idea to use
> transport_maps as intended, to override DNS lookups for selected
> remote domains. If for example you list hotmail.com in your
> transport_maps, wham, now you accept all mail for hotmail.com!
I'm using the transport maps like this:
mydomain.org smtp:192.168.1.100
It's forwarding mail for domains that it's responsible for to a
private mail server for delivery, through a vpn which isn't directly
accessible on the Internet.
>> zen.spamhaus.org=127.0.0.10 reject_rbl_client
>> zen.spamhaus.org=127.0.0.11 reject_rbl_client
>> zen.spamhaus.org check_client_access
>
> Why the .10 and .11 Zen rejections, when you go ahead and use any
> other Zen result anyway?
I was wondering that too, but I found it on postfix.org:
1 /etc/postfix/main.cf:
2 smtpd_client_restrictions =
3 permit_mynetworks
4 reject_rbl_client zen.spamhaus.org=127.0.0.10
5 reject_rbl_client zen.spamhaus.org=127.0.0.11
6 reject_rbl_client zen.spamhaus.org
Maybe I'm just misinterpreting how that should be read, and the
reject_rbl_client lines are individual examples?
In any case, I've removed the 10 and 11, but now I have messages like this:
Apr 19 21:47:33 mail02t postfix/smtpd[10892]: connect from
ema3rlyip01.turner.com[157.166.236.73]
Apr 19 21:47:34 mail02t postfix/smtpd[10892]: warning:
73.236.166.157.zen.spamhaus.org: RBL lookup error: Host or domain name
not found.
Name service error for name=73.236.166.157.zen.spamhaus.org type=A:
Host not found, try again
turner.com obviously won't be in the zen database. Is that the normal
response when a host is not listed?
> You're doing check_client_access twice on
> hash:/etc/postfix/client_checks, why? Also, typically you'd want
> these local lookups ahead of DNSBL lookups.
I've fixed that (like I said, after it was migrated from an old
system) and have listed my smtpd_recipient_restrictions again here:
smtpd_recipient_restrictions =
permit_sasl_authenticated,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_unauth_pipelining,
reject_unauth_destination,
permit_mynetworks,
check_recipient_access pcre:/etc/postfix/relay_recips_access,
check_recipient_access pcre:/etc/postfix/relay_recips_maillistusers,
check_client_access hash:/etc/postfix/client_checks,
reject_rbl_client zen.spamhaus.org
reject_invalid_hostname,
reject_non_fqdn_hostname,
check_helo_access hash:/etc/postfix/helo_checks,
check_sender_access hash:/etc/postfix/sender_checks,
permit
rbl_reply_maps = ${stress?hash:/etc/postfix/rbl_reply_maps}
It is the ordering that I'm not sure is completely correct.
In client_checks I have a few domains that I'd like to reject
outright, as well as a few that should always be permitted:
.workforpbp.com 554 clientspam
workforpbp.com 554 clientspam
192.168.1.100 OK
192.168 554 Take a hike!
64.1.16.3 OK
Thanks so much for spending the time. You've given me some great advice.
Thanks again,
Alex
