Hi, Dan -
On 15 December 2016 at 10:58, Dan Liles <dan.liles@???> wrote:
> 1) Putting items directly in the queue was not my first choice and I'm
> certainly open to doing it in a more sustainable way. Can you think of
> another way? Is there a way to do a "local" delivery that I could setup to
> bypass all the other stuff and just try to deliver a message I pass it or
> put it directly in the queue?
Have a look at *The Exim command line* section of the specification: there
are some options in there that might be of use to you — eg,
- -*bm* — This option runs an Exim receiving process that accepts an
incoming, locally-generated message on the standard input.
- *-bS* — This option is used for batched SMTP input, which is an
alternative interface for non-interactive local message submission.
- *-bs* — This option causes Exim to accept one or more messages by
reading SMTP commands on the standard input, and producing SMTP replies on
the standard output.
Make sure you know whether these will be using the SMTP or non-SMTP ACL
when doing their checks!
*A sideways thought…*
At risk of setting of down a wrong path, I've looked out my booklet of
slides from the Exim Course that Cambridge ran in 2007 as a faint memory
was stirring of something you might be able to use.
Philip Hazel, who taught the course, gave the example of wanting to pass an
incoming message through an external program, which processed the message
then returned it to Exim. If this was being done on the same host as Exim
the message was returned using batch SMTP (BSMTP, using the -bS command
line option above) in order to preserve envelopes.
A sneaky trick was to set the *received protocol* so the returned message
could be identified as having been processed by checking the
*$received_protocol* variable's value and wouldn't be processed again. The
received protocol is set with the *-oMr* command line option.
I'm wondering if you could use the feed-back-in step to submit your message
into Exim in a more supported way than by dropping files into the spool
directory.
Here's what the relevant slides said:
====================================================
*Passing messages through external programs*
- Requirements:
Must preserve the envelope sender
Must preserve the recipients
Message must be identifiable afterwards
- If the program runs on a different host:
SMTP preserves the sender and recipients
Processed messages are those that come from that host
- If the program runs on the same host (see example router and transport
below):
Use batch SMTP (BSMTP) to preserve envelopes
Set *batch_max* to ensure many recipients per delivery
Use *$received_protocol* to identify processed messages
- Message is returned to Exim by running
exim -bS -oMr processed
- The scanning program must run as a trusted user
trusted_users = specialuser
- Make this the first router
newmail:
driver = accept
condition = ${if \
!eq {$received_protocol}{processed}}
transport = incoming_processing
no_verify
- The external program can be run as a transport filter
incoming_processing:
driver = pipe
batch_max = 1000
use_bsmtp
command = /usr/sbin/exim -oMr processed -bS
transport_filter = /usr/bin/inmailprocessor
user = specialuser
====================================================
I think the above works something like this:
1. The *newmail* router accepts the message if and only if its received
protocol is not "processed".
2. The router queues the message for, in this case, the
"incoming_processing" transport.
3. The transport feeds the message through the processing program: in
this case /usr/bin/inmailprocessor
4. I think the "command" option is used to get the processed message
back into Exim (the -bS command line option) whilst also setting the
received protocol to "processed" (using the -oMr command line option) so
that the newmail router doesn't promptly pass it back out to the processing
program!
So depending on what form your message data is in that you're wanting to
get into the queue you might be able to just use one of -bm, -bs or -bS to
get it in but through an official channel?
What do people think? Might there be some mileage in Dan investigating this?
Cheers,
Mike B-)
--
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811
Web:
www.york.ac.uk/it-services
Disclaimer:
www.york.ac.uk/docs/disclaimer/email.htm
