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
|
