However, MHonArc will not archive a piped message from standard input --
it gets as far as creating a mhonarc.lck folder in the output directory,
but does not archive the message. SMTP does not hang, no closesocket
errors occur, and other members of the test list receive the message. The
command line I've entered for the robot is:
perl mhonarc -add -msgsep "^.$" -outdir <archive.dir> -- -
perl mhonarc -add -outdir archive.dir -- -
Actually, for a single message, the "-- -" part should be eliminated.
If not, mhonarc treats stdin as a source of a mailbox (which can
contain separate message and the MSGSEP resource is applicable).
1. Is any message actually being fed to MHonarc?
Is STDIO redirection available on commands invoked via the "robot", or
have to use something like
I agree on checking for this. Microsoft seems to be inclined not
to do things properly or in screwing ways from the rest of the world.
There was a post to c.l.p.m on what one has to do get standard I/O
redirection to work for IIS 4.0. So I would expect that other
MS products will have similiar issues.
In sum, always check that a MS product is doing its part of the
job in the way you expect.
2. Is the message being fed in a standard SMTP format? header, blank line,
body ? Headers are of form "field: value". Continuation lines for the
begin with whitespace.
Capture verbatim a message being fed to MHonArc into a text file, and
examine it for format. If it looks okay, feed it to mhonarc manually
A good suggestion by Steve, and a good practice when debugging problems.
I.e. Make sure MHonArc is get the data in a format it expects.
See RFC 822 for detailed information on mail message syntax.
3. Is MHonArc being invoked with the correct options to process the message?
See above about "-- -".
Note, when reading mailbox files, mhonarc first reads the mailbox until
the first MSGSEP. Hence, if no line matches MSGSEP, the entire input
could be ignored. If input is to be a single message, do not tell
mhonarc it is a mailbox.