LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Leonard D Woren <[log in to unmask]>
Sun, 5 May 1991 00:30:00 PDT
text/plain (79 lines)
On Sat, 4 May 91 19:05:40 +0200, Eric Thomas <[log in to unmask]> got
up on his soapbox and said:
 
> {tirade mostly deleted}
 
> 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,
 
Irrelevant.  There is no reason to cater to PROFS because the network
standard is RFC 822 format mail.  Personally, if it was up to me, I
would refuse to register new nodes unless the site management
certifies that they have installed an RFC 822 compliant mailer.  And I
think that existing sites that don't have such should be required to
get one or be blocked from all network services, *including* LISTSERV
lists.  And CMS NOTE should be banned from Bitnet.  Apparently so
should the vanilla DEC VMS mailer.
 
I wrote a file server (which will eventually handle lists) that runs
on MVS.  I originally had it generating "Reply-To: <>", which I claim
is legal, but *ix chokes on it.  So I changed it.  I wasn't happy
about doing so.  Once I check the standard and convince myself that
it's legal, I'll probably go back to generating an obnoxious message
in the Reply-To which states that I'm putting in this stupid Reply-To
because the stupid mailer on unix drops mail with null reply-to on the
floor.
 
> {stuff about requests to change listserv for various reasons}
> This  makes sense if
> software Y is something that impacts everyone in an unavoidable way
 
Well, if you get a mail loop between LISTSERV and an Acces/MVS
recipient, that impacts lots of people, not just the ones on the list
or at the Acces/MVS site.
 
> If they are happy  suffering from
> the design of their software, fine with  me.
 
At the time we first got Acces/MVS, it was pretty much the only game
in town for MVS.  When our director expressed concern as to whether it
would work in *our* environment, ACC responded "If it doesn't work,
we'll make it work."  See below.  When we ran Acces/MVS, the vendor
demonstrated that they were incapable of fixing the problems we had.
We junked it.  Not everyone is in a position to do that.  It took us
new hardware and many many months to convert to the IBM product.
 
> If they want to fix it, even better.
 
We certainly wanted things fixed.  They couldn't do it.  I invested a
lot of my time and went through a lot of aggravation trying to get
them to fix some things.  In fact, ACC often didn't know which version
of the source was current.  And then it took them over a year to admit
that they didn't have any source at all to the SMTP modules.  So how
could I possibly have asked them to change X-TO/X-FROM to BSMTP, which
is clearly better?  (BTW, ACC has since unloaded the product on
Interlink.)
 
> But I'm not going to let anyone convince me that it's MY problem.
 
It's NOT your problem.  I didn't actually say that it was.  But since
it has the potential to cause mail loops (it did at least once that I
saw), and the cost of changing to something other than "X-To:" is
tiny, and the impact is *ZERO*, I don't understand your resistance.
But then again I have never seen anyone convince you to change your
mind about anything.  I don't even know why I bother trying.  I will
often take a stand on principle, which is what I suppose you're doing
with this.  But there are known cases of people convincing me that I'm
wrong.  Of course everyone knows that you're always right, and that we
should all be groveling at your feet because otherwise you'll threaten
to drop support or start charging for this perfect piece of software.
 
No smilies here.
 
/Leonard
 
P.S.  There's probably no point in continuing this argument.  Of
course, if both of us are the type that has to have the last word...

ATOM RSS1 RSS2