> There does seem to be a lot of confusion caused by the different sender_*
> parameters, with their varying formats and effects. I think this has a lot to
> do with the overloading of the word "sender", to indicate variously the sending
> host and the sending RFC 822 address ("envelope sender", a.k.a. "return path").
> The fact that "sender_reject" refers to the latter isn't obvious to those
> who have not R'dTFM with due diligence. The alphabetical list in section 10
> becomes very much not ordered by function, with many cross-references.
>
This is to some extent true, but I must accept the blame for not reading the
manual sufficiently closely in this instance. With so much to do (replacing
our PP system), and so little time...things tend to get a bit rushed. The
distinction between *which* sender (header/envelope/network/whatever) is
confusing at times. However, the distinction of the options by the words
"net" and "host" tend to make the sender distinction clearer (especially the
latter) when read in conjunction with "sender_reject". "Diligence" is the
word.
As just mentioned to Philip Hazel it is really nice to have such a quick
response to a problem. Thanks to all.
John.
***************************************************************************
John Horne, E-mail: J.Horne@???
Computing Service, Phone : +44 (0) 1752 233911
University of Plymouth, UK. Fax : +44 (0) 1752 233919
--
* This is sent by the exim-users mailing list. To unsubscribe send a
mail with subject "unsubscribe" to exim-users-request@???
* Exim information can be found at http://www.exim.org/
