On Tue, Apr 19, 2011 at 11:09:07PM -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
>
> I didn't realize dovecot had the sieve plugin. I have quite a few
> old procmail recipes I'll need to convert.
AFAIK procmail still works fine. I moved away from it for server use
(as mailbox_command) a very long time ago, and for personal use (it
was invoked from .forward) at least 2 years ago. I found that I was
able to do everything I needed without procmail's bells and whistles
(specifically by using recipient_delimiter and .forward+foo files.)
So don't give it up just because I said so, but again, you might
consider not using it server-wide. Are all your users doing fancy
procmail filtering?
> > 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
But did you understand that most settings have defaults? For example
(from your own postconf -n) "inet_interfaces = all". That's the same
thing as having omitted the inet_interfaces setting.
> 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.
This was not reflected in your postconf output, however.
> >> 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.
That's fine. However you snipped my comment upthread about being a
backscatter spam source. You must either maintain a list of valid
recipients in relay_recipient_maps, or use recipient address
verification for relay_domains. See yesterday's Address Class README
link, and also these:
http://www.postfix.org/postconf.5.html#relay_recipient_maps
http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient
http://www.postfix.org/BACKSCATTER_README.html#wtf
(The latter is merely to explain the problem of backscatter spam. The
former two and yesterday's link tell you how NOT to be a backscatter
spammer.)
> >> 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?
I don't think Wietse tries to put forth any specific antispam
recommendations in the documentation, so it's dangerous to read
examples like that too literally. Well, perhaps not dangerous, as
nothing was harmed by that except a few of your CPU cycles.
What *is* dangerous is to use a DNSBL without being familiar with its
policies. Zen is an excellent resource, but do take the time to know
how to use it:
http://www.spamhaus.org/zen/
For me, as probably for most sites, a single "reject_rbl_client
zen.spamhaus.org" restriction is adequate.
> 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?
No, but that is not related to having removed the .10 and .11
lookups. It means that at Apr 19 21:47:33 for some reason your lookup
of 73.236.166.157.zen.spamhaus.org failed.
> 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.
Refer back to my comments yesterday about ordering. There's nothing
dramatically wrong here, but not completely ideal.
> 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
This is safe enough as you have it here. However, you should review
this document:
http://www.postfix.org/SMTPD_ACCESS_README.html#danger
(the whole thing, but particularly the #danger anchor.) The gist of
that being that check_client_access and other checks in
smtpd_recipient_restrictions should not result in "OK" if called
before reject_unauth_destination.
Two safe approaches:
1. A different restriction stage, such as smtpd_client_restrictions
2. Use "permit_auth_destination" in place of "OK" in your maps.
Also worth spending some time here:
http://www.postfix.org/access.5.html
--
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header
