mju@mudos.ann-arbor.mi.us (Marc Unangst) (09/06/90)
shwake@raysnec.UUCP (Ray Shwake) writes: > (we have ODT 1.0) on our system remains truly unreliable. The supplied > documentation helps not at all in decyphering the logging and error messages. This probably has something to do with the fact that the softcover "Open DeskTop Administrator's Guide" doesn't give you the whole picture. If you want complete documentation, you have to hand SCO another $400 for the Extended Documentation Set. I haven't seen this yet, but our company just ordered it. I'll have to see how much better it is when it shows up. -- Marc Unangst | "da-DE-DA: I am sorry, the country you have mju@mudos.ann-arbor.mi.us | dialed is not in service. Please check the ...!umich!leebai!mudos!mju | number and try again." -- Telecom Kuwait
mju@mudos.ann-arbor.mi.us (Marc Unangst) (09/08/90)
We are running SCO Unix/Open Desktop and related utilities on a cluster of machines connected via TCP/IP over Ethernet. There is no TCP/IP link to the rest of the world, though; the only outside link is UUCP. I have set things up so that all the machines on the network send their mail to the main gateway machine for routing over UUCP if it isn't to one of the other LAN machines. The MTA is MMDF as included with SCO Unix. We're having a problem with MMDF. Although it sends the mail to the appropriate machine and it eventually gets where it's supposed to go, the headers aren't correct. First of all, the From_ line lists the mail as from user "mmdf" instead of the user that actually sent the mail. Second of all, MMDF isn't adding Received: headers to the messages, which makes it difficult to track down bounced mail and such. The SCO ODT manuals have been no help at all, which was probably to be expected seeing as how there's no mention of the MTA in the section about UUCP, and only a few pages on UUCP in the section about MMDF. How do we fix these problems? -- Marc Unangst | mju@mudos.ann-arbor.mi.us | Angular momentum makes the world go 'round. ...!umich!leebai!mudos!mju |
david@twg.com (David S. Herron) (09/11/90)
In article <0ae6o2w163w@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >We're having a problem with MMDF. Although it sends the mail to the >appropriate machine and it eventually gets where it's supposed to go, >the headers aren't correct. First of all, the From_ line lists the >mail as from user "mmdf" instead of the user that actually sent the >mail. Usually I see this as coming from "uucp" and usually it only happens on System V machines. I never bothered to understand why it happens, if only because I usually run MMDF on BSD machines. But then it works fine on my Unix PC at home soooo... If I remember I'll ask my cohort about this tomorrow. He has more experience with running MMDF on System V than I do. > Second of all, MMDF isn't adding Received: headers to the >messages, which makes it difficult to track down bounced mail and such. >The SCO ODT manuals have been no help at all, which was probably to be >expected seeing as how there's no mention of the MTA in the section >about UUCP, and only a few pages on UUCP in the section about MMDF. >How do we fix these problems? I don't understand this. MMDF quite carefully puts Received: headers into messages. Are you sure you're seeing what you're seeing? :-) -- <- David Herron, an MMDF & WIN/MHS guy, <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!
ronald@robobar.co.uk (Ronald S H Khoo) (09/12/90)
In article <7921@gollum.twg.com> david@twg.com (David S. Herron) writes: >> the headers aren't correct. First of all, the From_ line lists the >> mail as from user "mmdf" instead of the user that actually sent the >> mail. > Usually I see this as coming from "uucp" and usually it only happens > on System V machines. I never bothered to understand why it happens, > if only because I usually run MMDF on BSD machines. But then it works > fine on my Unix PC at home soooo... I understood the original posting to mean that the From_ line on the RECEIVING machine (by implication _not_ running MMDF) to be wrong in being just "mmdf" and thought it was to do with the fact that the current UUCP channel does not invoke uux with the -aremote.domain!remote-user, (at least at update #43 it doesn't -- VERY sad -- I'm going to have to add it before I switch to MMDF) Was that understanding wrong ? BTW is the mmdf2@relay.cs.net list active ? I haven't seen _any_ messages since I asked for a list expansion address to be added a couple of weeks ago ... I *do* wish that MMDF workers would discuss their work openly in a USENET group, and am always grateful for the artcles on MMDF from DSH. Is there a hysterical reason why MMDF *isn't* discussed on USENET ? Where would be a good place to ask questions about it ? (I have a few burning ones :-) -- my .signature is on holiday
david@twg.com (David S. Herron) (09/13/90)
In article <1990Sep12.122549.21039@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: >In article <7921@gollum.twg.com> david@twg.com (David S. Herron) writes: > >>> the headers aren't correct. First of all, the From_ line lists the >>> mail as from user "mmdf" instead of the user that actually sent the >>> mail. > >> Usually I see this as coming from "uucp" and usually it only happens >> on System V machines. I never bothered to understand why it happens, >> if only because I usually run MMDF on BSD machines. But then it works >> fine on my Unix PC at home soooo... > >I understood the original posting to mean that the From_ line on the >RECEIVING machine (by implication _not_ running MMDF) to be wrong in >being just "mmdf" and thought it was to do with the fact that the >current UUCP channel does not invoke uux with the -aremote.domain!remote-user, >(at least at update #43 it doesn't -- VERY sad -- I'm going to have to add it >before I switch to MMDF) Was that understanding wrong ? I dunno why the -a option wasn't used.. in fact this is the first time I've ever heard of that option and my first thought it was something on a specific version of UUCP that I don't have access to. But I just checked on Sun OS 4.1, SysVr3.2 and 4.3-Tahoe, and it was on all of 'em. Sigh.. I guess that's my new thing to learn for the day, I might as well go home now ;-). As to whether this is a problem? Sendmail sites generally have the UUCP originator be `daemon' so I don't see how that's very different from MMDF sites having the originator be `mmdf'. Can you explain further? Why should the UUCP originator show up in From<space> lines? (Situation which I am imagining at this point: sender at an MMDF site. UUX/UUCP originator is `mmdf'. From<space> at originating site says `user'. Gets delivered elsewhere. In order for From<space> line to say `mmdf' that has to be changed somewhere. But all the rmail's I've seen simply scan through From<space>'s and >From<space>'s and concatenate strings. So where would this change be made?) >BTW is the mmdf2@relay.cs.net list active ? I haven't seen _any_ messages since >I asked for a list expansion address to be added a couple of weeks ago ... Yes.. we've had a little discussion recently (this week) about how the Host Requirements RFC relaxed RFC-822 a bit such that the former requirement for: From: phrase <local@domain> now doesn't require the phrase. (e.g. "From: <local@domain>" is enough). But the address parser won't work with this format because it sees '<' as the beginning of something to read in a list of addresses from a file. So, anyway.. yes, there's been some activity. You should probably contact mmdf2-request@relay.cs.net again.. >I *do* wish that MMDF workers would discuss their work openly in a USENET >group, and am always grateful for the artcles on MMDF from DSH. Is there >a hysterical reason why MMDF *isn't* discussed on USENET ? Where would >be a good place to ask questions about it ? (I have a few burning ones :-) er.. ah.. I *am* an MMDF worker. If I were to forced to come up with a h{i,y}st{e,o}rical reason for it not being discussed out here it would be: -- The previous groups of workers are/were from the Arpanet Mailing List tradition which tends to look down upon Usenet. (Indication: The `send' and `resend' programs (for sending and re-sending mail) in MMDF assume the ~/.signature file is suitable for the `phrase' part of the From: line.. take a look at my .signature below ;-)) -- The traffic on the mailing list has never been heavy enough to justify a newsgroup. -- There is a generally low opinion of MMDF which, as far as I can tell, derives from Olden Days when MMDF was truly buggy. Nowadays it is very unbuggy, except in the documentation which is a bit lacking (sigh) .. at any rate the rep isn't quite deserved. I think I had another reason but it seems to have slipped away.. ohwell. comp.mail.misc is just as good a place as any to talk about MMDF. If the traffic warrants we might just be able to wangle a newsgroup ;-). -- <- David Herron, an MMDF & WIN/MHS guy, <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!
emv@math.lsa.umich.edu (Edward Vielmetti) (09/13/90)
In article <1990Sep12.122549.21039@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes:
I *do* wish that MMDF workers would discuss their work openly in a USENET
group, and am always grateful for the artcles on MMDF from DSH. Is there
a hysterical reason why MMDF *isn't* discussed on USENET ? Where would
be a good place to ask questions about it ? (I have a few burning ones :-)
There's a 'bit.listserv.pmdf-l' group, but I don't see any mmdf lists on
a bit.* distribution. No discussion of mmdf on pmdf-l to speak of, not
surprising.
Suggest that you agitate for a while, do a call for discussion, then a
call for votes. In 2 months time you'll have a group.
--Edmju@mudos.ann-arbor.mi.us (Marc Unangst) (09/14/90)
david@twg.com (David S. Herron) writes: > MMDF quite carefully puts Received: headers into messages. Are you sure > you're seeing what you're seeing? :-) Well, it quite carefully puts a Received: header in the message when it receives the message from another host. But there's never a Received: header added for the local host, which I feel it should do. I've also another question: We have a TCP/IP LAN set up using ODT-NET with two machines so far, but probably more on the way (and maybe a direct Internet connection coming sometime). I'd like MMDF to use SMTP to deliver to machines on the network, but I don't want to have to make up a /usr/mmdf/table/smtp.chn file that includes every machine on the network. I'd rather have it ask the nameserver (yes, there's one running) to translate the name into an IP address, and send it to our main gateway machine if the nameserver doesn't know about that domain name. There doesn't appear to be a way to do this. Is there? (I also consider it somewhat slimey for MMDF to install its own version of /usr/lib/sendmail that isn't command-line-compatible with Berkeley sendmail. I hope that won't cause problems when I try to install PD MUAs later on.) -- Marc Unangst | "da-DE-DA: I am sorry, the country you have mju@mudos.ann-arbor.mi.us | dialed is not in service. Please check the ...!umich!leebai!mudos!mju | number and try again." -- Telecom Kuwait
mju@mudos.ann-arbor.mi.us (Marc Unangst) (09/14/90)
david@twg.com (David S. Herron) writes: > As to whether this is a problem? Sendmail sites generally have the > UUCP originator be `daemon' so I don't see how that's very different > from MMDF sites having the originator be `mmdf'. Can you explain further? Let's say that site A runs MMDF and talks to site B via UUCP. Site B is a dumb UUCP site that doesn't run a smart-mailer, and consequently can't handle RFC-822 headers. The MUA there is the /bin/mail distributed with the system, which also doesn't understand RFC-822 headers. User "user1" on site A sends mail to "user2" on site B. MMDF mangles the From_ line so it reads "From siteb!mmdf ... remote from sitea". user2 tries to reply to the message using /bin/mail's <r>eply command. The reply is sent to "siteb!mmdf", which is where the From_ line says the message came from. Do you understand now? -- Marc Unangst | "da-DE-DA: I am sorry, the country you have mju@mudos.ann-arbor.mi.us | dialed is not in service. Please check the ...!umich!leebai!mudos!mju | number and try again." -- Telecom Kuwait
ronald@robobar.co.uk (Ronald S H Khoo) (09/14/90)
In article <7927@gollum.twg.com> david@twg.com (David S. Herron) writes: [ I wrote ] >> that the >> current UUCP channel does not invoke uux with the >> -aremote.domain!remote-user, > in fact this is the first time > I've ever heard of that option Maybe *that*'s why the option isn't exercised :-) Of course, for people like me who don't have an MMDF source license, but only binary from SCO ... :-) Ooops, actually I Steve K *did* write a license for my other site, so I suppose that's my excuse gone -- damn :-) Who's maintaining the uucp channel nowadays anyway ? > As to whether this is a problem? Sendmail sites generally have the > UUCP originator be `daemon' so I don't see how that's very different > from MMDF sites having the originator be `mmdf'. Can you explain further? Erm. I think I've had the From_ line be the -a user before in one weird configuration once, but I can't remember what it was. I do remember it happening though, which is why I thought it was the asme problem as the original poster's problem -- though I may be wrong on that point. > But all the rmail's I've seen simply scan > through From<space>'s and >From<space>'s and concatenate strings. So > where would this change be made?) I can't remember how it happened,, though I think that the delivery was done in a most peculiar way. Sorry :-( I can't make it happen anymore ... >>BTW is the mmdf2@relay.cs.net list active ? > Yes.. we've had a little discussion recently (this week) > So, anyway.. yes, there's been some activity. You should probably contact > mmdf2-request@relay.cs.net again.. Sigh. Perhaps I agitate for it to be gatewayed (one-way to avoid the wrath of the MMDF workers :-) into a newsgroup :-) > er.. ah.. I *am* an MMDF worker. The only one I've ever seen in comp.mail :-) ? :-( ? > MMDF assume > the ~/.signature file is suitable for the `phrase' part of the From: > line.. take a look at my .signature below ;-)) I've come across news posters that do that too :-( >-- The traffic on the mailing list has never been heavy enough to justify > a newsgroup. But having it there would inform bulk of MMDF using lurkers, which I think would be valuable. Other than in the UK, EUNet is generally against MMDF, which I think is a shame. I recently suggested that the new Egyptian backbone should look at using MMDF (which *I* consider the only viable option for use by beginner backbones) instead of smail 2.5, and people said MMDF ? Uggggghhhhhh! or words to that effect. Sigh. Information about the current mmdf work should help to keep the balance. I don't really see people using PP for quite a while yet -- I'd have to buy a new disc to unpack it :-) >-- There is a generally low opinion of MMDF which, as far as I can tell, > derives from Olden Days when MMDF was truly buggy. I was only a user in the days just about when MMDF II just came out, so I guess I'm too young to remember the bad old buggy days :-) > the documentation which is a bit lacking (sigh) .. And the sample tables which don't work at update #43 (flags=partial) Sigh. But then again, UCL only distributes update #21 -- I know, I only got a tape from them a couple of months ago :-( Then again, that's what the UK academic community use :-( > comp.mail.misc is just as good a place as any to talk about MMDF. If the > traffic warrants we might just be able to wangle a newsgroup ;-). We need a few more MMDF gurus. One David Herron isn't enough, really. Anyone else volunteering to help answer questions ? I'll volunteer to ask them :-) and I know a couple of others who would as well :-) -- my .signature is on holiday
shwake@raysnec.UUCP (Ray Shwake) (09/14/90)
david@twg.com (David S. Herron) writes: >-- There is a generally low opinion of MMDF which, as far as I can tell, > derives from Olden Days when MMDF was truly buggy. Nowadays it is very > unbuggy, except in the documentation which is a bit lacking (sigh) .. > at any rate the rep isn't quite deserved. Tell us another one, David! (Nothing personal... David *did* try to help solve *our* problem.) The "officially supported" MMDF II found in SCO UNIX (we have ODT 1.0) on our system remains truly unreliable. The supplied documentation helps not at all in decyphering the logging and error messages. Indeed, the only mail handled reliably here is that handled by our parallel mailer (FXmail).
bernie@DIALix.UUCP (Bernd Felsche) (09/15/90)
In article <7927@gollum.twg.com> david@twg.com (David S. Herron) writes: [...deleted...] >-- There is a generally low opinion of MMDF which, as far as I can tell, > derives from Olden Days when MMDF was truly buggy. Nowadays it is very > unbuggy, except in the documentation which is a bit lacking (sigh) .. > at any rate the rep isn't quite deserved. Some time ago, I posted a request for information on the SCO Unix MMDF channel interface, because I need to customise it. I've had not replies, other than suggestions to get smail. Doc's aren't good either, but you do get the source, don't you. :-) My main reason for tinkering with MMDF is to stop the uucp channel "banging up" the address on everything that goes out via that channel (all external mail). Due to the lack of doc's, I can't even define my own channels because the MMDF-channel interface is ill-defined. Where shall I go to seek wisdom? (I can't afford a source licence.) bernie
ronald@robobar.co.uk (Ronald S H Khoo) (09/16/90)
In article <74@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: [ David Herron wrote: ] > >-- There is a generally low opinion of MMDF which, as far as I can tell, > > derives from Olden Days when MMDF was truly buggy. Nowadays it is very > > unbuggy, except in the documentation which is a bit lacking (sigh) .. > Tell us another one, David! (Nothing personal... David *did* try to help > solve *our* problem.) The "officially supported" MMDF II found in SCO UNIX > (we have ODT 1.0) on our system remains truly unreliable. Yup, it's certainly not David's fault -- I think he's even given SCO free help -- the world needs more DSHs, but then this *is* the first time SCO have done anything with MMDF, and I would argue that when they get it right, it will prove to have been the right choice. And this brings up another point, The shipping of MMDF by a major vendor like SCO is one other reason to draw the MMDF discussion on USENET together, especially since anyone who tries to muck with SCO's mailers may well get bitten by their nasty so-called "security" <expletive deleted> and would be well advised to stick with MMDF for that reason. Mail suppliers like Ray, of course are free to do whatthey like, but we aren't all in that business! My suggestion for an MMDF group has met with some positive and no negative response, so I'll probably send out an official CALL FOR DISCUSSION sometime in the next wek or two -- I need a few days to read the official guidelines first :-) Any mail on that issue will be very welcome, whether +ve or -ve. -- my .signature is on holiday
david@twg.com (David S. Herron) (09/17/90)
In article <oowgP1w163w@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >david@twg.com (David S. Herron) writes: >> MMDF quite carefully puts Received: headers into messages. Are you sure >> you're seeing what you're seeing? :-) > >Well, it quite carefully puts a Received: header in the message when >it receives the message from another host. But there's never a >Received: header added for the local host, which I feel it should do. er.. ah.. the Received: header lists both the sending and receiving host, so therefore the `local' host is appearing in the header somewhere. If I were to change the Received: header additions I'd make it a bit more verbose listing what channel it came from, the return address, one or more of the forward addresses, and (if known at that time) the outgoing channel. >I've also another question: We have a TCP/IP LAN set up using ODT-NET >with two machines so far, but probably more on the way (and maybe a >direct Internet connection coming sometime). I'd like MMDF to use >SMTP to deliver to machines on the network, but I don't want to have >to make up a /usr/mmdf/table/smtp.chn file that includes every machine >on the network. I'd rather have it ask the nameserver (yes, there's >one running) to translate the name into an IP address, and send it to >our main gateway machine if the nameserver doesn't know about that >domain name. There doesn't appear to be a way to do this. Is there? If SCO's version of MMDF was compiled with NAMESERVER undefined then there's no-way-no-how you can do nameserver queries. NAMESERVER was there in the version SCO used (update 32). A good strategy to use with nameservers is to have a seperate database from which you generate nameserver files /etc/hosts /usr/mmdf/table/smtp.chn etc. The database can be a simple file and processed with an awk script. That's what we started with at the U of Kentucky before one of the guys changed it into a distributed database system in the process of earning a Masters Thesis. (results are in the Usenix large-systems workshop proceedings from September '89). de-digressing: If you use this seperate-database-and-generate-needed files-from-awk-script approach you make sure that *all* those files are up to date in one fell swoop. Yes, theoretically, the desire is to only use nameservers. I'm definitely one to campaign for more and stronger nameserver use (& abuse even..). But I also know quite well the needs of having a system be usable when part of it uses nameservers and part doesn't. >(I also consider it somewhat slimey for MMDF to install its own >version of /usr/lib/sendmail that isn't command-line-compatible with >Berkeley sendmail. I hope that won't cause problems when I try to >install PD MUAs later on.) er.. ah.. the /usr/lib/sendmail that MMDF installs *is* command-line-compatible with Berzerkeley sendmail. At least enough-compatible to do the job of posting mail, and possibly a couplea other things. (Starting up an smtpd for instance..) It works fine for posting mail from mush, for instance. I've also used it from shell scripts w/o problem. -- <- David Herron, an MMDF & WIN/MHS guy, <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!
ronald@robobar.co.uk (Ronald S H Khoo) (09/18/90)
In article <568@DIALix.UUCP> bernie@DIALix.oz.au (Bernd Felsche) writes: > My main reason for tinkering with MMDF is to stop the uucp channel > "banging up" the address on everything that goes out via that > channel (all external mail). If I read you right, I think the banging has been taken out of MMDF uucp channel at update #43. You just got to wait for SCO to ship update #43 in a few years' time :-) -- my .signature is on holiday
mju@mudos.ann-arbor.mi.us (Marc Unangst) (09/19/90)
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. MMDF doesn't do this. For example, let's say that I have two hosts: tech.dsc.com and mudos.ann-arbor.mi.us. I send mail from mudos, which runs Waffle v1.63 under MS-DOS, to tech, which runs MMDF under SCO ODT. When the mail arrives on tech and is delivered to the user there, it will have two Received: headers; one that was put in by mudos that just says "Received: by mudos.ann-arbor.mi.us ...", and one that was put in by tech that says "Received: from mudos.UUCP by tech.dsc.com ...". This is the way, IMHO, things should work. However, if you try sending mail the other way around -- from tech to mudos -- the mail arrives on mudos and is delivered to the user there with only ONE Received: header, which reads "Received: from tech.UUCP by mudos.ann-arbor.mi.us ...". What I'm wondering is why, in the second case (tech->mudos), tech isn't adding a Received: header for itself. > If SCO's version of MMDF was compiled with NAMESERVER undefined then > there's no-way-no-how you can do nameserver queries. NAMESERVER was > there in the version SCO used (update 32). That's strange, because I talked to SCO technical support and they said that the version of MMDF that was shipping with the current version of ODT was not capable of nameserver queries. They did say that when the next release of ODT comes out, it will include a nameserver-capable MMDF. Perhaps this is what you're talking about? > the /usr/lib/sendmail that MMDF installs *is* command-line-compatible > with Berzerkeley sendmail. At least enough-compatible to do the job > of posting mail, and possibly a couplea other things. (Starting up > an smtpd for instance..) 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. Under MMDF, that yields an "unknown option" error message from MMDF. IMHO, if you're going to install something called /usr/lib/sendmail, make sure everything about the interface with other programs is exactly the same as the de facto standard sendmail. Otherwise, please don't call your program "sendmail", because it isn't. One note that may have some effect here -- we are a SCO dealer and are setting up this ODT network partially to help support customers who purchase SCO ODT products. 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. -- Marc Unangst | "da-DE-DA: I am sorry, the country you have mju@mudos.ann-arbor.mi.us | dialed is not in service. Please check the ...!umich!leebai!mudos!mju | number and try again." -- Telecom Kuwait
david@twg.com (David S. Herron) (09/28/90)
In article <568@DIALix.UUCP> bernie@DIALix.oz.au (Bernd Felsche) writes: >In article <7927@gollum.twg.com> david@twg.com (David S. Herron) writes: >[...deleted...] >>-- There is a generally low opinion of MMDF which, as far as I can tell, >> derives from Olden Days when MMDF was truly buggy. Nowadays it is very >> unbuggy, except in the documentation which is a bit lacking (sigh) .. >> at any rate the rep isn't quite deserved. > >Some time ago, I posted a request for information on the SCO Unix >MMDF channel interface, because I need to customise it. I've had >not replies, other than suggestions to get smail. Doc's aren't good >either, but you do get the source, don't you. :-) The channel interface is a group of subroutine calls.. documented in a man page and in source. >My main reason for tinkering with MMDF is to stop the uucp channel >"banging up" the address on everything that goes out via that >channel (all external mail). Due to the lack of doc's, I can't even >define my own channels because the MMDF-channel interface is >ill-defined. > >Where shall I go to seek wisdom? (I can't afford a source >licence.) > >bernie Need source? ftp and/or uucp it from either gatekeeper.dec.com or from uunet.uu.net. Both places have it there even though it isn't clear to me that it is rightful for it to be there. U of Delaware owns the source, I simply maintain it out of the goodness of my heart or something like that. People who are CSNET members or received the 4.3-BSD distribution have rights to MMDF source, as do Army sites. Others are "supposed" to approach U of Delaware, but that Dave Farber takes care of the liscense detail and he's not at Delaware anymore. Instead he's at UPENN (farber@dsl.cis.upenn.edu). Something that is there right now which you might be able to use to do what you want is the "prog" channel. It is intended for interfacing MMDF to odd software in circumstances where the people don't want to use (or cannot use) the full channel interface. -- <- David Herron, an MMDF & WIN/MHS guy, <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!
david@twg.com (David S. Herron) (09/28/90)
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, <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!
jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) (09/28/90)
In article <8006@gollum.twg.com> david@twg.com (David S. Herron) writes: >You're not likely to hear me say "use Sendmail" ... :-) Not many of us have as good a reason as you do... :-) Even so, I don't do sendmail like I don't do COBOL. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jmaynard@thesis1.hsch.utexas.edu | adequately be explained by stupidity. "It's a hardware bug!" "It's a +--------------------------------------- software bug!" "It's two...two...two bugs in one!" - _Engineer's Rap_