Re: [exim] Best way to copy incoming mails for specific doma…

Page principale
Supprimer ce message
Répondre à ce message
Auteur: W B Hacker
Date:  
À: exim users
Sujet: Re: [exim] Best way to copy incoming mails for specific domain to another server?
Emmanuel Noobadmin wrote:
> I'm trying to copy incoming emails for a specific domain to another
> server for archival purposes.
> e.g. mails to adam@??? needs to go to adam@???
>
> The only method I've found so far that works is through the user of
> the system filter, checking for matches in $h_to, $h_cc and $h_bcc
> before doing a deliver unseen.
>
> The problem with this is that I am not able to automatically copy the
> email based on the user. I can only specify a single destination
> mailbox for all users on that domain. Trying to use $local_part does
> not work and the documentation seems to be saying that the information
> is not available at this stage of delivery.
>
> So I started looking at shadow transport but the documentation seems
> to indicate that it cannot be use for remote delivery. Nevertheless, I
> experimented and it seem to be possible to call a shadow transport
> which uses the smtp driver. Except then I run into smtp authentication
> problem where server1archive refuses to accept the email.
>
> Somehow I feel like I am going about this the wrong way. I'd
> appreciate it greatly if anybody point me in the right direction, or
> is archiving on a per user basis simply not possible?
>


Eminently possible. Many ways, partly dpending on what your relationship
is to the destination(s) and the users(s).

- perhaps the least-hassle is user MUA script forwarding a copy and no
Mailadmin involvement.

- perhaps the easiest is use of the system /etc/aliases file or an
Exim-readable functional equivalent

- perhaps the 'best' is lmtp - but the destination pretty well has to be
yours or working with you.

- perhaps the most powerful might involve address re-writing.

My 'weapon of choice' in any case is neither system filter nor the
shadow transport, but rather chaining of 'unseen' routers.

That lets me apply SQL, which is not needed, but is as flexible as you
care to make it.

HTH,

Bill


--
韓家標