Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Jorey Bump (listjoreybump.com)
Date: Thu Jul 05 2007 - 09:45:34 CDT
> smtpd_recipient_restrictions =
> # reject_unverified_recipient,
> (1) reject_non_fqdn_hostname,
> (2) check_helo_access hash:/etc/postfix/helo_access
> OK so if I use the above order I have the following questions:
> (1) this should be removed as it is replaced in
> reject_non_fqdn_helo_hostname right?
Correct. Only use one form. The new form is available in Postfix 2.3 and
higher. My rule of thumb is that I use the new forms if they are
compatible with all of the installations I manage, which makes my
configuration more portable. The Postfix developers have always
deprecated configuration directives on a sensible schedule.
I still recommend logging a warning for this (and
reject_invalid_helo_hostname), though. You've solved the problem for
your users, but not for misconfigured sites. I've been burned by this
restriction, and prefer to get more specific in a check_helo_access map.
> (2) the helo_access is to reject people saying they are me, file contains:
> 220.127.116.11 REJECT Helo Check
> localhost REJECT Helo Check
> Should I move helo_access check up higher in my list?
I probably would move it right after reject_unauth_destination, but in
your current configuration, it's useful to position it wherever it gives
you the best feedback for the restrictions you're trying to evaluate.
IOW, you'll see if the earlier restrictions prevent your map from ever
being used. Later, you can move it ahead of those restrictions to see if
it has the same effect on them. Then you can make an informed decision
about which ones to keep. Note that this is only true if the map
continues to contain only REJECT (or effectively similar) statements.