>> UUCP mailers, like Internet mailers, send rejection messages to the return
>> address in the envelope.  This address will have been derived from the
>> MAIL FROM:<> address in the BSMTP envelope at the gateway.  The proper,
>> standard solution is to avoid having the rejection note sent back to the
>> list altogether by including an envelope return address which points
>> elsewhere.
>>
>> LISTSERV, unfortunately, does not follow this standard practice.  Instead
>> it sends messages with the envelope address pointing back at the list and
 
> The "standardized" meaning of SENDER: has two subtly different meanings that
> in this case need two separate addresses.  There are not enough standardized
> field names for all the needs.
 
I think we are misunderstanding each other.  The error messages you
get back are typically from what pass for MTA's in UUCPland.  As such,
a traditional, old style UUCP site could not care less what address
is in the Sender: header, or the From: header, or anything else inside
the letter.  What it does care about are the addresses in the envelope.
While a UUCP envelope is not BSMTP, the return address in the UUCP envelope
should have been derived from the MAIL FROM:<> address in the BSMTP
envelope on the bitnet side if the gateway is functioning properly.  This
is more-or-less analogous to the processing of mail by Internet sites as
well.
 
Note that this has nothing to do with what's in the Sender: field.  I
assume by your response that you feel that the MAIL FROM:<> and the
Sender: addresses must be identical, yet I know of nothing which implies
this must be so.  The Sender: address, along with all the other RFC822
headers, are something for the mail reading program, or whatever else is
acting as a User Agent, to look at.  And, yes, the exact function of the
Sender: address could be argued to be ambiguous.  The MAIL FROM:<> address,
however, has exactly one unambiguous function.  It is the address to which
MTA's return error notifications.
 
Thus the solution I was referring to, that of pointing the envelope return
address at something besides the list, has little to do with the Sender:
address.  Make the Sender: address what you want, but point the MAIL FROM:<>
address away from the list (at the bit bucket if necessary), make sure the
gateways transmit the information and you'll have a whole lot less trouble
with error rejections from both UUCP and internet sites.
 
Thus the problem is not LISTSERV's.  I like LISTSERV, it does what it does
quite effectively and is a pleasant piece of software to deal with from a
user's point-of-view (comments about "fast and loose with RFC822" not
withstanding).  The problem is that any mailer to be used for tasks as
demanding as supporting mailing list distribution should at least have a
simple way for trusted User Agents to set the envelope address independent
of the contents of the headers.  The Crosswell mailer, which I am told was
never intended for the kind of use it has seen, does not.
 
No more kludges to LISTSERV, it's better to keep it as lean and mean as
possible.  Just give it a mailer of equivalent functionality and you'll
have an excellent combination.
 
Dennis Ferguson
University of Toronto