Philip Hazel writes ("Re: [EXIM] no reliable way to use batch-smtp input"):
> On Wed, 3 Feb 1999, Ian Jackson wrote:
> > I seem to remember some discussion about this before, but I can't find
> > it in the mail archives.
>
> I don't recall it, but my memory isn't as good as it was.
>
> > The problem is that if Exim wants to return an error in response to a
> > bsmtp message it sends a message to postmaster containing the error
> > response that would have been given. Missing are any other details,
> > including the erroneous message. Exim then exits with status zero.
>
> It sends the error to postmaster only if the caller is trusted.
> Otherwise it sends it to the caller.
>
> I believe the idea was not to delay a whole batch of messages just
> because of a problem with one of them.
In nearly all applications of BSMTP there is very little opportunity
for returning a bad message to its real sender other than by
generating a new bounce message and hoping you'll be able to deliver
it. Giving the message to the local postmaster to deal with is not
the right thing to do, because the local postmaster is almost
certainly not the person responsible.
Therefore, the only sensible way to use BSMTP is to try to have the
receiving MTA accept all the messages in the batch just so long as it
can figure out what the messages are. If they later need to be
bounced, so be it, and turning them into bounced bounces later is
certainly no worse than sending the message to the local
postmaster straight away.
Furthermore, if errors are detected during BSMTP processing it's not
safe to continue, because some errors could lead to desynchronisation
between Exim's BSMTP parser and the file, so that (for example)
message data might be interpreted as SMTP commands.
> Not quite sure what you mean by
> "missing are any other details". The code appears to be written so as to
> include any envelope sender, recipients and header lines that it has
> read before detecting the error.
It doesn't, in fact, seem to do this. In any case, including just
that data wouldn't be enough. The entire message body should be sent
- otherwise, the system as a whole can lose mail. However, this can't
be done reliably because of the parsing problems I mention.
> > 1. sender_verify_batch is turned off by default.
>
> Incompatible change. I don't like incompatible changes. Some
> unsuspecting person always gets bitten.
I suggest that of people using BSMTP without setting this option
either way, currently more of them would benefit from having it turned
off. I imagine that there are several sites where errors due to
verify rejection result in messages to postmaster which are routinely
ignored (because there's nothing else that can be done), resulting in
the complete loss of mail that might have been successfully delivered.
> > 2. If Exim finds itself wanting to return an SMTP error code during
> > batch SMTP input it prints an error message to stderr which gives the
> > text of the SMTP error _and the line number_ (or some indication of
> > where in the input the error occurred), and exits immediately with a
> > nonzero status. The calling program can then know that the input was
> > not successful and take some appropriate action.
>
> This would have to be optional, because it is an incompatible change.
> Note that an error code would mean that *some* of the input was not
> successful. Earlier messages in the batch would have been sent.
This suggestion is _not_ an incompatible change. Currently there is
no way to safely rely on the behaviour of Exim when fed an erroneous
BSMTP input file. In fact, Exim might well swallow the entire file,
effectively discard all the message data in it, and then exit with
status zero. This is no way to proceed !
It is a bug, pure and simple, that Exim handles BSMTP errors the way
it does.
Consider: currently, on most systems, there might be other errors
which would cause Exim not to work properly. Eg, there might be an
error of some kind in exim.conf, or the system might be out of
resources temporarily, or something. In many of these situations, the
called program will appear to print a message to stderr and exit with
a nonzero status (this being implemented by system software which Exim
has no control over).
Therefore any software which wants to make reliable use of BSMTP
already has to check the exit status of -bS and ask for some kind of
human intervention if something goes wrong, so it won't be broken if
you make the changes I'm suggesting.
Exim needs to adopt an exit status and error message convention
compatible with this.
In general, any program which calls another on Unix is entitled to
assume that exit status 0 means successful completion, and must be
prepared to handle at least an exit status of 255 meaning complete
(but possibly temporary) failure.
I therefore suggest that Exim's exit status from -bS be defined as
follows:
0: all commands and messages processed successfully
no output on stdout or stderr
1: some messages processed, but an SMTP dialogue error occurred
to stdout: print the line number and SMTP error message in
machine-readable format. The line number of the last
successful HELO, RSET or end of message would be very
useful if it is conveniently available.
to stderr: print a human-readable error message giving the above
information, and the number of messages processed
successfully if available.
This should stop processing immediately.
any other: complete failure
to stderr: an error message
no output on stdout
This could be implemented quite easily, by having the BSMTP error
handling print the relevant information to stdout/err and exit with
status 1.
> I do not make any use of BSMTP; it was very much a bolted-on facility
> for UUCP users who wanted to use it. What do other BSMTP users think of
> this idea? I need additional opinions!
I'm not sure how to say this without being rude, which I don't want to
be because I do respect Phil. However, I think that lack of
experience with BSMTP may be contributing to the situation ...
Ian.
--
*** Exim information can be found at
http://www.exim.org/ ***
