>> 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