irv@happym.wa.com (Irving Wolfe) (07/31/90)
The mail program is smart enough to notice new mail that arrives while the
user is looking at existing mail; it notifies him with an "h"-type line for
the new message. Unfortunately, it does not appear to be smart enough to
handle a second piece of mail arriving while processing of the first piece is
taking place:
If two messages arrive from another system in the same uucp session for a user
while he is in mail, one of the messages can get lost. The uucp logs on both
ends show successful passing of both pieces of mail, but the user is only
notified of the first piece and the second piece goes to never-never-land (at
least sometimes).
Has anyone else experienced this problem?
Does anyone know of a solution, short of dumping SCO's mail program and
replacing it with something more reliable?
--
Irving Wolfe Happy Man Corp. irv@happym.wa.com 206/463-9399 ext.101
4410 SW Point Robinson Road, Vashon Island, WA 98070-7399
SOLID VALUE, the investment letter for Benj. Graham's intelligent investors
Information (not sample) free: email patty@happym.wa.com with US mail addr.shwake@raysnec.UUCP (Ray Shwake) (08/02/90)
irv@happym.wa.com (Irving Wolfe) writes: >If two messages arrive from another system in the same uucp session for a user >while he is in mail, one of the messages can get lost. The uucp logs on both >ends show successful passing of both pieces of mail, but the user is only >notified of the first piece and the second piece goes to never-never-land (at >least sometimes). Regrettably, we continue to experience such problems. They're traceable to MMDF-II. If you look in /usr/spool/mmdf/lock/home/*/* you'll likely find the lost mail. Fortunately for us, we market our own email software (FXMAIL) which provides drop-in replacements for most of the SCO mail components. Replacing their rmail (which feeds into MMDF) with our own (which writes directly to the mailboxes or interfaces to uux) eliminated all problems with remotely posted mail. Only system-generated messages (which use 'mail') continue to be a problem. uunet!media!ka3ovk!raysnec!rsxtech!shwake shwake@rsxtech
terry@iti.org (Terry Hull) (08/03/90)
shwake@raysnec.UUCP (Ray Shwake) writes: [SCO Lost mail problem deleted] > Regrettably, we continue to experience such problems. They're > traceable to MMDF-II. If you look in /usr/spool/mmdf/lock/home/*/* > you'll likely find the lost mail. > Fortunately for us, we market our own email software (FXMAIL) > which provides drop-in replacements for most of the SCO mail > components. Replacing their rmail (which feeds into MMDF) with > our own (which writes directly to the mailboxes or interfaces > to uux) eliminated all problems with remotely posted mail. Only > system-generated messages (which use 'mail') continue to be a > problem. I trashed mmdf and replaced it with smail3. Things seemed to work OK then. I used local mail as well as mail via uucp with no hassles. smail3 is available on uunet.uu.net. -- Terry Hull Department of Electrical and Computer Engineering, Kansas State University Work: terry@eece.ksu.edu, rutgers!ksuvax1!eecea!terry Play: terry@tah386.manhattan.ks.us, rutgers!ksuvax1!eecea!tah386!terry
aab@cichlid.com (Andrew A. Burgess) (08/04/90)
In article <17@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: >irv@happym.wa.com (Irving Wolfe) writes: > >>If two messages arrive from another system in the same uucp session for a user >>while he is in mail, one of the messages can get lost. The uucp logs on both >>ends show successful passing of both pieces of mail, but the user is only >>notified of the first piece and the second piece goes to never-never-land (at >>least sometimes). > > Regrettably, we continue to experience such problems. They're > traceable to MMDF-II. If you look in /usr/spool/mmdf/lock/home/*/* > you'll likely find the lost mail. Thanks for the valuable information Ray. Everyone with SCO UNIX still running mmdf should do: vi /usr/spool/mmdf/lock/home/msg/* right now. You'll be amazed at all the mail you never saw! Smail here I come! Andy -- Andy Burgess Consulting Software Engineer uunet!silma!cichlid!aab aab@cichlid.com
david@twg.com (David S. Herron) (08/13/90)
In article <17@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: >irv@happym.wa.com (Irving Wolfe) writes: > >>If two messages arrive from another system in the same uucp session for a user >>while he is in mail, one of the messages can get lost. The uucp logs on both >>ends show successful passing of both pieces of mail, but the user is only >>notified of the first piece and the second piece goes to never-never-land (at >>least sometimes). As as been said before ... this is *NOT* a problem except in the configuration you run. MMDF, as do all other mail systems, puts out a lock on the mailbox wile delivering mail. The lock is there so that you don't have >= two processes scribbling on the file and making a mess of things. Now .. at some point, before I got involved with MMDF, a decision was made that the local channel will simply exit when it see's the mailbox is locked (and exit in a way which tells the deliver controlling it that there's a temporary problem, rather than a permanent problem for which it should bounce the mail back to the sender) Part of this decision was an assumption that the system had a deliver running in the background controlling mail traffic on one-or-more channels. The command line to do this is: deliver -cchan,chan,chan -b (for instance): deliver -cuucp,local,list -b I have no idea why a simple heuristic wasn't used to, when the open+lock failed, simply wait a little while and try again. It's something I plan to do with the version of MMDF which I maintain. I have no idea what SCO plans to do with the version of MMDF they maintain ... -- <- David Herron, an MMDF weenie, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!