OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Postfix Archives: Re: interaction of relocated table and early

Re: interaction of relocated table and early local user detection

Subject: Re: interaction of relocated table and early local user detection
From: Wietse Venema (wietseporcupine.org)
Date: Sun Jan 02 2000 - 11:08:33 CST

Drew Derbyshire:
> It would appear use of the line:
>
> local_recipient_maps = $alias_maps, unix:passwd.byname
>
> Disables use of the relocated table support for those users no longer in
> /etc/passwd, as the users don't pass this first. I presume this could be
> corrected by adding hash:/etc/postfix/relocated to the above list, which
> would effectively pass the users to the internal component which does the
> bounce. If so, please point this out in the documentation.

Good point. If people use relocated maps, the recommended use is:

    local_recipient_maps = $alias_maps, unix:passwd.byname, $relocated_maps

I'll fix the docs and sample files.

> In my case, I chose to use documented alternative, the
> smtpd_recipient_restrictions with hand tuned error messages. This prevents
> the mail from ever being accepted on the local system, which I prefer (and
> also lets the bounce messages go to banned hosts, which keeps them from
> beating on the door further.)
>
> Also, am I correct that the relocated table does not require a trailing at
> sign () on local users such as 'ed' but that the
> smtpd_recipient_restrictions table does? I had to append the at-sign when
> I migrated the entries over:

Whoa. That would reject mail for edany.domain.

According to my access map manual page,

       user Matches all mail addresses with the specified user
              part.

> One final comment is that you can see from my sample table I tend to add a
> boiler plate suffix with contact information to the error messages. If
> this could be done via variable substitution into the various error
> responses in a future release it would be useful. ($contact_information?)

Not a problem as long as you generate the file from some template.

        Wietse

This archive was generated by hypermail 2b27 : Sun Jan 02 2000 - 11:11:32 CST