Re: [exim] Forwarding of delivery error messages to non-exis…

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: W B Hacker
Fecha:  
A: exim users
Asunto: Re: [exim] Forwarding of delivery error messages to non-existent local users' aliases fails
My BSD wrote:
> Good day!
>
> Set up v. 4.69 (compiled from source) on Ubuntu Hardy box with a fully
> qualified domain name (with proper RDNS) for the purpose of delivering
> outgoing business mail from local users.
>
> Local users do not have local accounts, instead, they have accounts on
> an external E-Mail host with corresponding entries in the aliases file
> pointing to their external accounts, as follows:
>
> user1:    user1@???
> user2:    user2@???
>  ,,,

>
> Messages from one local user to another are forwarded to the local user's
> external account without incident.
>
> But local delivery error messages are frozen with the following log entries:
>
> -----------------------------------------------------------------------------------------------------------
> 2009-05-26 04:16:49 1M8rq5-0003kh-LJ ** [user@???]
> <[user@???]>: Unknown user
>
> 2009-05-26 04:16:49 1M8rq5-0003kh-LJ Frozen (delivery error message)"
> -----------------------------------------------------------------------------------------------------------
>
> Any ideas?
>


" Local users do not have local accounts, "

Look at your routers and the transports they call.

- why would one of those ID's - by definition, with '..no local account'
be latched-on-to for local delivery at all?

- and if/as/when it is, *where* would Exim expect to deliver it?

NOT having 'local accounts' as in shell login, a /home/<usrname> dirtree, or
an mbox or maildir under /var/mail/<username> is fine.

But if the the only 'virtualization' you do is driven by /etc/[mail]/aliases.
you must either insure those addresees are NOT taken up by a local delivery
router/transport in the first instance, OR provide it with a place to drop 'em
or the privs to create such on-the-fly if you DO allow it.

'The aliases file' BTW does not have to be the *system* aliases file, either.

Sometimes easier to manage if it is of the same structure, but otherwise separate.

HTH,

Bill