jmm@skivs.ski.org (04/14/89)
Has anyone noticed the following bug in the version of mailx distributed with RTU-3.1A: When a message is sent to an internet address, eg: mail someone@host.domain and also copied to a local user, eg: Cc: friend the sender gets mailed an error message, saying that /usr/bin/lmail couldn't mail to "friend". In the cases I have checked, however, the warning is spurious, and "friend" actually got the copy. Does this bug exist in the newest mailx release? Joel M Miller Smith-Kettlewell Institute 2232 Webster St; San Francisco, CA 94115 UUCP: jmm@skivs.ski.org OR uunet!skivs!jmm BITNET: jmm%skivs.ski.org@uunet.uu.net VOICE: 415/561-1703 FAX: 415/561-1610 The MASSCOMP USERS' SOCIETY newsgroup is comp.sys.masscomp. Articles to: masscomp@soma.bcm.tmc.edu or uunet!soma.bcm.tmc.edu!masscomp Administrative stuff: masscomp-request@soma.bcm.tmc.edu Stan Barber, Moderator
mazer@bek-owl.caltech.edu (Jamie Mazer) (04/16/89)
In article <1486@gazette.bcm.tmc.edu> jmm@skivs.ski.org writes: >Has anyone noticed the following bug in the version of mailx distributed >with RTU-3.1A: When a message is sent to an internet address, eg: Sorry, but I didn't notice this when we were running 3.1 or now under 4.0, but I have noticed another interesting mail bug I could use help with... Our sendmail seems to periodically get confused while recieving SMTP mail, but instead of reporting its error to a log file or the console, if writes it back out over the network connection, causing the other end to think an error has occured. Note that the mail IS received normally - the message is just a warning. The end result is that the other end assumes mail has failed since it detected a SMTP protocol error - i.e. rtu has messed up, and will retry after some time-delay. This means that the masscomp user recieves a copy of the letter on a regular basis (say every 1/2 hour) for days (until sendmail is restarted). Our sysop has no idea what is causing this; in fact there seems to be no obvious trigger that starts sendmail on this death spin! So, has anyone else seen this problem? The network gurus here claim that RTU is violating the STMP and tcp/ip protocols by reporting errors to the network socket (instead of a logfile); they say masscomp should fix it. Thanks for any help, /Jamie -------- UUCP: {rutgers,ames}!cit-vax!bek-owl!mazer ARPA: mazer@bek-owl.caltech.edu BITNET: jmazer@caltech.bitnet "Michael J. Fox has no Elvis in him." UUCP: {rutgers,ames}!cit-vax!bek-owl!mazer ARPA: mazer@bek-owl.caltech.edu BITNET: jmazer@caltech.bitnet "Michael J. Fox has no Elvis in him." The MASSCOMP USERS' SOCIETY newsgroup is comp.sys.masscomp. Articles to: masscomp@soma.bcm.tmc.edu or uunet!soma.bcm.tmc.edu!masscomp Administrative stuff: masscomp-request@soma.bcm.tmc.edu Stan Barber, Moderator
dale@ldgo.columbia.edu (dale chayes) (04/26/89)
In response to the recent postings about problems with the unsupported
versions of sendmail that were available from Masscomp (which often
appear as bugs in mail or mailx to users):
Concurrent (the new company) has finaly (after an excessive delay) begun
to ship release 1.0 of RT-MAIL. This is MH and MMDF with the HM user
interface. You have to be running RTU-4.0 to install RT-MAIL.
>From the users perspective, it offers a much better interface with
many options for user-specific and site-specific adaptation. From the
system managment perspective, one need not be an M4 adept to install or
modifiy the delivery layers.
There will be sessions at the upcomming Masscomp Users Socitey annual
meeting on MMDF, so make your plans now.
- --
Dale Chayes Lamont-Doherty Geological Observatory of Columbia University
Route 9W, Palisades, N.Y. 10964 dale@lamont.ldgo.columbia.edu
voice: (914) 359-2900 extension 434 fax: (914) 359-6817
------- End of Forwarded Message
The MASSCOMP USERS' SOCIETY newsgroup is comp.sys.masscomp.
Articles to: masscomp@soma.bcm.tmc.edu or uunet!soma.bcm.tmc.edu!masscomp
Administrative stuff: masscomp-request@soma.bcm.tmc.edu
Stan Barber, Moderator