david@twg.com (David S. Herron) (11/27/90)
[Cross-posted & followups-to comp.mail.misc since this isn't TCP/IP specific] In article <9011190759.aa12077@ssmct62.ssc.af.mil> hutch@ssmct62.ssc.af.mil ("Capt E. Lee Hutchins") writes: > MMDF is the supported mail system for SCO UNIX. MMDF does not come >with an ideal set of documentation. (At least I >can't make heads or tails out of it). If any one has some ideas on Docs for >this system which are NOT in troff form I'd appreciate them. Configuring MMDF >without real documentation is a real *&^%$! Yes, I agree .. that would be rather hard. Docs for MMDF IIb update 43 (as well as sources) are available via anonymous ftp from louie.udel.edu. Both uunet.uu.net & gatekeeper.dec.com keep the sources available. I don't remember path names, but it was pretty obvious .. There's two mailing lists you should be interested in: eurmmdf@zweibrucken-emh1.army.mil is Army people (I suppose that since they let me be on the list, they'll let Air Force people be on it ;-)) working with MMDF. Though the discussion seems to be more generic Unix problems than MMDF problems .. eurmmdf-request@zweibrucken-emh1.army.mil, of course, for administrivia mmdf2@relay.cs.net The "official" mailing list for MMDF support. It manages to focus on MMDF pretty well. mmdf2-request@relay.cs.net, of course, for administrivia > I can recieve mail from other UNIX platforms, but we have another >mail system running which is based on 10NET, called "COURIER MAIL". It has >an "SMTP" gateway working and other UNIX boxes (AT&T 3B2 600G's) can >receive and send mail fine. My box on the other hand, does >not work with it. The mail ends up in a queue on the "COURIER SERVER" and is >never returned to me or the originator. Anybody ever experienced this???? This sounds like the "no background deliver" as described below .. > By the way my machine does not always accept: > > telnet machinename.domain 25 > >When tried manually from other hosts it often closes the connection before it >askes for the identification. The MMDF SMTP server can be configured to do this if the IP address does not have a known IP->host_name mapping. Usually, though, it's configured to give the "foo, you are a charlatan" message .. >In fact it seems the more mail sent to my >machine, the less I actually receive. I am on *several* mailing lists and I >expected my mail volume to be much higher than it is. This sounds like the SCO fumble where they made some bad suggestions in their manuals. Specifically -- that channels be configured for "immediate" delivery & that no deliver daemon be run to handle background delivery. Theoretically it sounds nice .. if it gets delivered immediately then it doesn't make sense to have a deliver running since it will "never" see any mail. But in practice -- if lots of mail arrives at once -- then some of the messages will drop into a queue and then never get delivered. This is especially noticeable with the local channel. If the mailbox is locked (for instance, it's being delivered to by another local channel process) the channel will exit with a "temporary failure" status & the deliver controlling that channel will go away. The assumption was that a background channel would take up the slack. Rather than simply wait around for a little while -- you don't know how long this "temporary" condition will exist -- exiting works given a background deliver. But SCO recommended *against* using a background deliver. Fortunately they've seen the error of their ways and currently suggest using "mod=reg", which pushes all delivery through the background deliver, and run deliver -b -clocal & or deliver -b -clocal,list,uucp,smtp & In update 43 you can abbreviate that to deliver -b -c & and that daemon will work with *all* channels in the system. > Finally, one other tidbit, I am running the latest version of "ELM" as >my front end to mail. This shouldn't make any difference -- unless ELM keeps the mailbox locked all the time. -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Use the force Wes!
fitz@wang.com (Tom Fitzgerald) (12/04/90)
david@twg.com (David S. Herron) writes: > But SCO recommended *against* using a background deliver. Fortunately > they've seen the error of their ways and currently suggest using > "mod=reg", which pushes all delivery through the background deliver, Why do you want mod=reg here? It seems like, with mod=imm and a background demon running, you'll get immediate delivery if the channel's idle, and delayed delivery only if the channel's busy. The only flaw should be that messages arrive out-of-sequence. By the way, people should be aware that the MMDF released with SCO has some other real problems - it bounces mail that has perfectly valid destination addresses but a bad return address; it rewrites addresses improperly when bouncing mail, and often sends it to the wrong place; and it sends out a copy of a message for each recipient, even at times when it could send a single copy to multiple recipients. Rumor has it that much newer versions of MMDF exist, and are far better. --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz