From: Jorey Bump (listjoreybump.com)
Date: Fri May 25 2007 - 13:21:34 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I've CC'd to the list, so others can pick up on the correction.

LuKreme wrote:
>
> On 25-May-2007, at 07:09, Jorey Bump wrote:
>
>> You'll have to decide which of those options cause problems for you,
>> and weigh the pros & cons (preface them with warn_if_reject if you
>> want to monitor the effect without actually rejecting messages).
>> However, once you do, you should avoid letting your users violate
>> policies you've set for everyone else.
>>
>> For example, why let an authenticated user send mail with a
>> non_fqdn_sender if the recipient can't use that address when replying?
>
> Well, I had it before permit and at least two people on the list
> suggested it should be later along with reject_invalid_hostname.
>
>
> For example, Noel said:
>>> reject_invalid_hostname,
>>> reject_non_fqdn_sender,
>>> reject_non_fqdn_recipient,
>>> reject_unknown_sender_domain,
>>> reject_unauth_pipelining,
>>> permit_mynetworks,
>>> reject_unlisted_recipient,
>>> permit_sasl_authenticated,
>>
>> You intend to reject your own users for invalid hostname or unauth
>> pipelining? Usually these restrictions are only applied to outsiders.
>
> :/

This shows how one policy may not be suitable for all user classes. I
enforce one policy on outsiders for port 25 (incoming mail), and another
for authenticated users on submission port 587 (outgoing mail). In some
cases, I enforce yet another policy on an arbitrary port (like 2525) to
  support legacy applications within mynetworks.

You'll have to understand thoroughly what each directive does, as it's
true that some will cause problems for your own clients, and must be
placed after permit_sasl_authenticated (this just one reason why
reject_rbl_client belongs at the end, since your users might connect
from an IP in a DUL or from a network/IP poisoned by previous spam
activity).

In any case, Noel was referring to reject_invalid_hostname (now
reject_invalid_helo_hostname), and he's right, you *must* put that after
permit_sasl_authenticated because many email clients aren't in a
position to HELO properly (I overlooked this, because I don't use it and
wasn't referring to a working configuration that did). The problem I was
pointing out was that you exempted your authenticated users from
reject_non_fqdn_sender, but didn't exempt their recipients from the
corresponding reject_non_fqdn_recipient when replying. Unless you really
need to allow your authenticated users to use non_fqdn_sender addresses,
you should prevent them from doing so.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]