Path: utzoo!attcan!uunet!midway!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!mips!twg.com!david From: david@twg.com (David S. Herron) Newsgroups: comp.mail.uucp Subject: Re: Problems with MMDF and UUCP mail Message-ID: <8006@gollum.twg.com> Date: 27 Sep 90 22:25:48 GMT References: <7950@gollum.twg.com> <0F7PP1w163w@mudos.ann-arbor.mi.us> Reply-To: david@twg.com (David S. Herron) Organization: The Wollongong Group, Palo Alto, CA Lines: 76 In article <0F7PP1w163w@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >david@twg.com (David S. Herron) writes: >> er.. ah.. the Received: header lists both the sending and receiving >> host, so therefore the `local' host is appearing in the header somewhere. > >I'm probably not being too clear here, so I'll try to elaborate on >what exactly I mean. > >On most of the other MTA systems I've worked with (which includes >sendmail, smail 3.1.19, smail 2.5, "dumb UUCP", and various MS-DOS >packages), mail that originates on the local host and is delivered >elsewhere is given a Received: header by the local host. ... [Long story which reduces to: ... ] Messy-DOS with Waffle (mudos) -> SCO/MMDF (tech.dsc.com) 2 Received: headers -- by mudos.ann-arbor.mi.us -- from mudos.UUCP by tech.dsc.com SCO/MMDF (tech.dsc.com) -> Messy-DOS with Waffle (mudos) 1 Received: header -- from tech.UUCP by mudos.ann-arbor.mi.us Hmm, interesting.. I hadn't noticed this before but you're right. (I just repeated it here.) To an extent this is just a stylistic matter similar to complaining about the lack of interesting values in the Message-ID: header. :-) It's halfway superfluous to add a Received: header like you're saying since the header already says where the mail originated. But there's also cases with host hiding where you wouldn't be certain of where the message *physically* originated at just by looking at the value in the From: header. >Try, for example, "/usr/lib/sendmail -bt". Under Berkeley sendmail, >as well as smail 3.1.19 (which installs itself as /usr/lib/sendmail, >among other things), this will get you an "address test mode" where >you can type in an address and it will show you the motions it goes >through to figure out what to do with mail to that address. It's very >useful for debugging routing files without sending a lot of test >messages. er.. ah.. I don't see how this would help since MMDF doesn't use anything that even *slightly* resembles rule sets. The closest equivalent with MMDF is "checkaddr -w". This starts up submit and talks to it giving it addresses you type in, the submit checks the address out, and returns information about whether it will work and where it would be routed to. Fixing the sendmail emulator so that "-bt" would start checkaddr might be what you mean. But it wouldn't work "EXACTLY" the same and therefore would fail, according to your definition. >... Therefore, we are attempting to stay as >close as possible to the stock SCO distribution, and suggestions such >as "junk MMDF and go with {smail 3.1.19, IDA Sendmail, pick a favorite >MTA}" will probably be politely declined. You're not likely to hear me say "use Sendmail" ... :-) -- <- David Herron, an MMDF & WIN/MHS guy, <- Formerly: David Herron -- NonResident E-Mail Hack <- <- Sign me up for one "I survived Jaka's Story" T-shirt!