On Mon, Apr 18, 2011 at 10:23:36PM -0400, Alex wrote:
> 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
deliver to mbox in $mail_spool_directory, not using any fancy filter
features of procmail. If so, Postfix's own local(8) delivery agent
should do all you need. Any user wanting procmail filtering could
activate it by means of a .forward file. See here for more:
http://www.postfix.org/local.8.html
http://www.postfix.org/aliases.5.html
Next, it appears that you are using Dovecot IMAP. Dovecot ships a
modern delivery agent called "deliver". It can also do filtering like
procmail in conjunction with a sieve plugin. See the Dovecot wiki for
information.
> In previous systems I've set up, procmail was setuid root, but on
> this one it is not. Without it, it seems it can't write the spool
> file:
>
> Apr 18 21:39:58 mail02t postfix/local[12142]: 3B07E60053:
> to=<mu...@example.com>, relay=local, delay=0.26,
> delays=0.13/0.01/0/0.12, dsn=5.2.0, status=bounced (can't create user
> output file. Command output: procmail: Couldn't create
> "/var/spool/mail/munin" )
> Apr 18 21:39:58 mail02t postfix/local[12130]: 3AA966006D:
> to=<r...@example.com>, orig_to=<root>, relay=local, delay=20987,
> delays=20987/0.01/0/0.12, dsn=5.2.0, status=bounced (can't create user
> output file. Command output: procmail: Couldn't create
> "/var/spool/mail/nobody" )
>
> What is the proper way to enable procmail to deliver mail? I've seen
> too many varied answers when searching. I've set mailbox_command to
> procmail. In case it's necessary, I've included my postconf below. I'd
> sure appreciate any ideas you may have.
One comment: that's a long "postconf -n". Do you need all those
settings?
> alias_database = hash:/etc/postfix/aliases
> alias_maps = hash:/etc/aliases
> biff = no
> command_directory = /usr/sbin
> config_directory = /etc/postfix
> daemon_directory = /usr/libexec/postfix
> data_directory = /var/lib/postfix
> delay_warning_time = 4h
> disable_vrfy_command = yes
> header_checks = pcre:/etc/postfix/header_checks.pcre
Why header_checks? They don't do much.
> 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.
> 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!
If you're not using relay_domains, unset it. If you are, you need
relay_recipient_maps to avoid being a backscatter spammer. For more
information:
http://www.postfix.org/ADDRESS_CLASS_README.html#relay_domain_class
> sample_directory = /usr/share/doc/postfix-2.7.3/samples
> sendmail_path = /usr/sbin/sendmail
> setgid_group = postdrop
> smtp_tls_CAfile = /etc/pki/tls/cacert.pem
> 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, reject_rbl_client
> 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?
> hash:/etc/postfix/client_checks, reject_invalid_hostname,
> reject_non_fqdn_hostname, 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, permit
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.
> smtpd_sasl_auth_enable = yes
> smtpd_sasl_authenticated_header = yes
> smtpd_sasl_local_domain = $myhostname, mail02t.example.com
> smtpd_sasl_path = private/auth
> smtpd_sasl_security_options = noanonymous, noplaintext
> smtpd_sasl_tls_security_options = noanonymous
> smtpd_sasl_type = dovecot
> smtpd_sender_restrictions = reject_sender_login_mismatch
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/pki/dovecot/certs/dovecot.pem
> smtpd_tls_key_file = /etc/pki/dovecot/private/dovecot.pem
> smtpd_tls_received_header = yes
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_database =
> btree:/var/lib/postfix/smtpd_tls_session_cache
> tls_random_source = dev:/dev/urandom
> transport_maps = hash:/etc/postfix/transport
What's in there, and why?
I'd suggest that you tear it down and start over using this:
http://www.postfix.org/BASIC_CONFIGURATION_README.html
and add on as needed, such as the SASL and TLS.
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
