Re: [exim] how to change a recipient in a transport?

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: W B Hacker
Data:  
Para: exim users
Assunto: Re: [exim] how to change a recipient in a transport?
Matthew Byng-Maddick wrote:

> On Tue, Oct 10, 2006 at 07:07:51PM +0200, Marten Lehmann wrote:
>
>>unfortunately changing the transports doesn't help me. You are using an
>>appendfile-transport and you are defining a target-directory. I'm using
>>an smtp-transport and I need to set _my_ "target-directory" -> which is
>>the recipient address. But I still don't know how to do this.
>
>
> I'm not sure I understand why you think that doing this at transport time
> is the right thing to do.


Works for us, where the purpose here is archiving, but note that the 'target
directory' seems to be of the same sort Marten needs (dynamically determined),
and local for what is shown here. Remote, via smtp or lmtp is no more difficult
- largely just a driver & transport change:

The routers:
====

# Route 2_C normal remote DNS lookup
#
dnslookup:
driver = dnslookup
domains = !+local_domains : !+ml_domains
transport = remote_smtp
ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8
unseen

# ROUTE_2D REMOTE: archiving of outbound traffic.
#
sentarchiver:
driver = dnslookup
domains = !+local_domains : !+ml_domains
transport = sent_archive_delivery
ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8

====

The transports:

====

# TRANSPORT_0 REMOTE: Deliver off-box over SMTP connections.
#
remote_smtp:
driver = smtp
helo_data = <an expansion variable or lookup - redacted to reduce tangentials>

# TRANSPORT_3A REMOTE Remote smtp delivery archiving
#
sent_archive_delivery:
driver = appendfile
user = mailnull
group = mail
delivery_date_add
envelope_to_add
return_path_add
maildir_format = true
mode = 0770
directory = /data/mail/archive/${domain}/${local_part}/Maildir/.Sent/
## N.B. - directory may be list, lookup, or complex-expansion-variable driven
create_directory = true
directory_mode = 0770
no_mode_fail_narrower

====

> Surely the right thing is to do this at message
> routing time? - it means you have to be a bit cleverer about your routers,
> and you can't just use the accept router you had before, but...
>
> Cheers
>
> MBM
>


Yes, that works well also.

But is it any/enough more efficient? As easy to code and debug?

Rather handier, IMNSHO, to be able to see *immediately* in a 'tail'-ed log just
which 'single purpose' router and transport handled the delivery, than it is to
equip a multi-purpose router with the debug messages to log which of several
parts was activated on any given delivery.

Likewise, when one of these breaks, it doesn't break everything.

Clever use of 'unseen' lets one test selectively with 'extra' copies and
duplicated deliveries while a production server is under live load.

YMMV,

Bill Hacker