|Main Archive Page > Month Archives > postfix-users archives|
On 10/20/2010 05:41 AM, Steve Jenkins wrote:
> Jeroen said:
> My personal server uses:
> smtpd_recipient_restrictions = permit_mynetworks,
> check_helo_access hash:/etc/postfix/helo_access,
> Out of curiosity, does anyone see any drawbacks (such as possibly
> rejecting valid mail) to adding "reject_invalid_hostname" to those
I can think of one: you already have it, as a warning, which is smart.
This is the pre-2.3 setting for reject_invalid_HELO_hostname, which you
Given hostnames (i.e. from PTR records) obviously can't be "invalid" -
they come from DNS.
Make sure you understand the difference between
> Also, some other reading I've been doing suggest adding
> "smtpd_helo_required = yes" to the main.cf file. Is that
> helpful/necessary, or would I already be covered there with the
> "reject_invalid_helo_hostname" in the above recipient restrictions?
No, you definitely want that set to "yes".
Not requiring HELO means the helo tests are skipped altogether as
there's nothing to match them against.
> I've also read another suggestion to add "smtpd_sender_restrictions =
> reject_unknown_address" to reject mail that doesn't have any return
Yes, that's the trouble with tutorials - they often get things wrong.
Again, that's not a valid restriction - it's either
reject_unknown_sender_domain, or reject_[unlisted|unverified]_sender.
The smtpd_*_restrictions never talk about "address" because it's
ambiguous - they are always specified to be senders or recipients.
Take a look at http://www.postfix.org/ADDRESS_VERIFICATION_README.html
if you want to know more.
> I've moved all my checks to the recipient restrictions, so if I added
> this, it would be my only sender restriction. Am I wrong in thinking
> this check is superfluous because of the "reject_non_fqdn_sender"
> already in the above recipient restrictions?
Well, as I already said, because of one of the above, but yes.
Note that rejecting non-fqdn senders is a trivial check; sender or
recipient address verification is much more expensive as it has to
initiate an SMTP session to a (possibly slow or unresponsive) remote server.
> It's slowly starting to make more sense.
It's going to continue to do so for a while :)