Hello,
I want to test a pipe transport. How could this be done without
disturbing the running exim daemon?
My "normal" testing setup
exim -d -C /dbg/eximdbg.conf -bh 1.2.3.4 < intest 2dbglog
does not perform real transport functionality.
Greetings,
Peter

on 2006-05-12 11:07 Tony Finch wrote:
Thu, 11 May 2006, Peter Velan wrote:

>exim -d -C /dbg/eximdbg.conf -bh 1.2.3.4 < intest 2dbglog
>does not perform real transport functionality.

The -bh option is mostly for testing ACLs. If you want to test transports,
you can just submit the message locally with
exim -d -C /dbg/eximdbg.conf recipient@address <intest 2>dbglog

Thanks a lot!
Peter

Thu, 11 May 2006, Peter Velan wrote:

My "normal" testing setup

exim -d -C /dbg/eximdbg.conf -bh 1.2.3.4 < intest 2dbglog

does not perform real transport functionality.

The -bh option is mostly for testing ACLs. If you want to test transports,
you can just submit the message locally with
exim -d -C /dbg/eximdbg.conf recipient@address <intest 2>dbglog

Tony.

am 2006-05-12 11:07 schrieb Tony Finch:
Thu, 11 May 2006, Peter Velan wrote:
>>
>My "normal" testing setup
>>
>exim -d -C /dbg/eximdbg.conf -bh 1.2.3.4 < intest 2dbglog
>>
>does not perform real transport functionality.

The -bh option is mostly for testing ACLs. If you want to test transports,
you can just submit the message locally with
exim -d -C /dbg/eximdbg.conf recipient@address <intest 2>dbglog

Thank you Tony its perfect (as I wrote earlier). But now I need a
combination of both: a locally injected "intest" which is run through
ACL, routers and transports. Is it possible?

Peter

Thu, 18 May 2006, Peter Velan wrote:

Thank you Tony its perfect (as I wrote earlier). But now I need a
combination of both: a locally injected "intest" which is run through
ACL, routers and transports. Is it possible?

Take a look at the -N option. It does everything except actually deliver
the message. If you want to run through the SMTP ACLs, you have to
inject the message using local SMTP, of course.

am 2006-05-19 10:13 schrieb Philip Hazel:
Thu, 18 May 2006, Peter Velan wrote:

>Thank you Tony its perfect (as I wrote earlier). But now I need a
>combination of both: a locally injected "intest" which is run through
>ACL, routers and transports. Is it possible?

Take a look at the -N option. It does everything except actually deliver
the message. If you want to run through the SMTP ACLs, you have to
inject the message using local SMTP, of course.

Aah, "-N" looks like the perfect switch for my needs.

Thanks a lot,
Peter

Thu, 18 May 2006, Peter Velan wrote:

But now I need a combination of both: a locally injected "intest" which
is run through ACL, routers and transports. Is it possible?

Sounds to me like you want to do a normal delivery with debugging turned
on. -N tests the transport setup but not the delivery (i.e. in your case
piping to a program).

Tony.

am 2006-05-19 12:12 schrieb Tony Finch:
Thu, 18 May 2006, Peter Velan wrote:
>>
>But now I need a combination of both: a locally injected "intest" which
>is run through ACL, routers and transports. Is it possible?

Sounds to me like you want to do a normal delivery with debugging turned
on. -N tests the transport setup but not the delivery (i.e. in your case
piping to a program).

You are right on this and its the actual way I'm doing testing now.

What I want to accomplish is this:

A robot sends a mail to exim, which target is a real external address.
Exim has to detect it as a special one (by means of ACLs) and routes it
to a perl script via pipe transport. My perl script creates a totally
new message and injects this locally to exim.

It works very well, but one thing should never happen (in the testing
phase): the message is not detected as special one and is delivered to
the original external address.

So what I want is this: inject message locally to exim with debugging
turned on and use eximtest.conf, but whatever happens, never deliver to
original real address, instead deliver to a local test account. For
sure, if - but only if! - after I made my job, then no message will
leave exim.

BTW: The mentioned injection of the new message by my perlscript always
targets a defined testing account, so there's no problem with this.

Peter

am 2006-05-19 14:09 schrieb Tony Finch:
Fri, 19 May 2006, Peter Velan wrote:
>>
>A robot sends a mail to exim, which target is a real external address.
>Exim has to detect it as a special one (by means of ACLs) and routes it
>to a perl script via pipe transport. My perl script creates a totally
>new message and injects this locally to exim.

Address-related things should be done by routers, not ACLs. ACLs are for
client-related stuff.

Hmm, may be my explanation was confusing. A message comes in. By means
of acl_smtp_data I do some checking stuff and set a variable, indicating
special or normal message (no messing with address related stuff here).
The first router selects the piping transport if variable says "special"
and ends with 'no_more'.

After thinking about my testing concept, its evident that I'm doing too
much at once - thats's bad practice! First debug ACLs, then - and only
then! - do next testing steps (router, transport, etc.).

>So what I want is this: inject message locally to exim with debugging
>turned on and use eximtest.conf, but whatever happens, never deliver to
>original real address, instead deliver to a local test account. For
>sure, if - but only if! - after I made my job, then no message will
>leave exim.

I'd suggest using a macro for this. e.g. I have the following; you might
want to use something similar to change your routing in debug mode.

.ifdef DEBUG
log_selector= +all
.else
log_selector= -retry_defer -skip_delivery -host_lookup_failed \
+incoming_interface +incoming_port +smtp_confirmation \
+sender_on_delivery +return_path_on_delivery +delivery_size \
+received_recipients +all_parents +address_rewrite \
+tls_certificate_verified +tls_peerdn \
+smtp_protocol_error +smtp_syntax_error \
+deliver_time +queue_time \
-lost_incoming_connection
.endif

yes! Never thought about using conditionals in config. I could
conditionally add a special router following the (possibly failed 1st
one) which routes anything received to my testing account! A very
helpfull hint, Tony.

Exim is a phantastic piece of software, with superb documentation and a
lot of skillfull helping hands around!

Thanks all, I've learned (and going to learn) a lot,
Peter

Fri, 19 May 2006, Peter Velan wrote:

A robot sends a mail to exim, which target is a real external address.
Exim has to detect it as a special one (by means of ACLs) and routes it
to a perl script via pipe transport. My perl script creates a totally
new message and injects this locally to exim.

Address-related things should be done by routers, not ACLs. ACLs are for
client-related stuff.

So what I want is this: inject message locally to exim with debugging
turned on and use eximtest.conf, but whatever happens, never deliver to
original real address, instead deliver to a local test account. For
sure, if - but only if! - after I made my job, then no message will
leave exim.

I'd suggest using a macro for this. e.g. I have the following; you might
want to use something similar to change your routing in debug mode.

ifdef DEBUG
log_selector= +all
else
log_selector= -retry_defer -skip_delivery -host_lookup_failed \
+incoming_interface +incoming_port +smtp_confirmation \
+sender_on_delivery +return_path_on_delivery +delivery_size \
+received_recipients +all_parents +address_rewrite \
+tls_certificate_verified +tls_peerdn \
+smtp_protocol_error +smtp_syntax_error \
+deliver_time +queue_time \
-lost_incoming_connection
endif

Tony.