I hear this kind of statements ("software X must be changed because, let's face it, software Y is not going to change in the next 5 years at best so the only way is to change X") quite often. This makes sense if software Y is something that impacts everyone in an unavoidable way - for instance, if the operating system LISTSERV is running on has some bug which IBM refuses to fix, LISTSERV should be fixed to work around that bug or everyone will suffer. Now, there are a number of sites running mail software in which the REPLY function forwards a complete copy of the original posting back to the person you reply to, RFC822 headers included. These users suffer considerable inconvenience from LISTSERV's refusal to process such mail, and let's face it this mail software is not going to change (especially as it's doing REPLY the way God meant it to be, if you see what I mean), so let's remove this check from LISTSERV. There is an operating system where the standard vendor-supplied tools for editing and then sending a command file to LISTSERV causes serial numbers to be placed in columns 73-80 and they're not going to change this (default) option any time soon because it would break zillions of other applications, so let's have LISTSERV blank out columns 73-80 (like NETSERV does). Let's change SMTP to stop using 'MAIL FROM:<>' on delivery error notices, it breaks the standard bsd Unix (tm) mail system! A node administrator complained to me about this, agreed that it was allowed by the specs, but told me that since it creates problems with the standard bsd config and let's face it, there are thousands of sites running bsd and not knowing about it, I ought to change SMTP to put something there - anything, as long as it's not empty. I realize I have not mentioned PROFS yet, well of course since PROFS is not moving to RFC822 any time soon and there is a considerable amount of PROFS users in the network we should have LISTSERV generate PROFS notes instead of RFC822, otherwise they can't reply easily, and since PROFS users know very little about computers, it's easier for RFC822 techies to adapt to PROFS than the other way around :-) Well I could go on forever. As I see it, these are all examples of situations where the problem only impacts this subset of LISTSERV users running the software causing the problem, while the rest of the world doesn't even know the problem exists. If they are happy suffering from the design of their software, fine with me. If they want to fix it, even better. But I'm not going to let anyone convince me that it's MY problem. Eric