On Wed, 12 May 1999, James Fidell wrote:
> Digging about in the source, this appears to be because at the start of
> smtp_start_session (smtp_in.c) the value of received_protocol is reset
> to one of "smtp", "local-bsmtp" or "local-smtp" despite the fact that it
> was already set on the command line and has the correct value on entering
> the function.
>
> Is this a bug ?
Well, it is documented! Under -oMr it says "It applies only to non-SMTP
and batched SMTP input." On that basis, I'm *not* going to rush to make
a last minute change to the 3.00 release (which is imminent). If you
read the code further, you will see that the protocol value can get
changed as a result of receiving an EHLO command (to "esmtp"), so this
is fairly involved.
I cannot remember why I implemented it the way I did. I suspect I was
thinking about the case where you want to inject a local message that
looks as if it has come from elsewhere - that's that all the -oM options
were conceived for. I didn't think of them being relevant for SMTP
input. Indeed, for all the other options such as -oMa, etc. a real
incoming call overrides the value set on the command line, so the
behaviour of -oMr is consistent with that.
I know that people have started using -oMr to "tag" messages that have
been processed in some special way. This is a useful feature, but is in
some sense a "wrong" use of -oMr. Was this what you wanted it for?
Perhaps I should implement something completely new, for example,
-oMx <string> which can only be set from the command line and which will
never be set otherwise (and some variable to make its value available).
Would this cover your case?
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
--
*** Exim information can be found at
http://www.exim.org/ ***
