SCO Unix 3.2.4 MMDF UUCP to SMTP gateways ???
Mark Bixby
Internet <--56kb router--> localsite <--uucp modem--> remotesite
I'm localsite, directly connected to the Internet, on an HP 9000/817 running
HPUX 8.02. Remotesite only has uucp modem connectivity with us, and is
running SCO Unix 3.2.4.
I want localsite to act as a mail gateway for remotesite to reach the Internet.
Localsite is the designated MX for remotesite's domain name, and is using
sendmail successfully to send mail TO remotesite.
The problem is when remotesite tries to send mail through localsite. What
appears to be happening is remotesite's MMDF is queueing an rmail command
with a destination address not considered "standard" (a loaded word, for sure)
by localsite. For example:
us...@internet.host ---> internet.host!user
remotesite!user%internet.host ---> internet.host!remotesite!user
When localsite receives the rmail command with "!" addressing, it thinks
"Aha! This is a UUCP address. Send it to our UUCP gateway at CERFnet.".
CERFnet doesn't expect Internet domain names with "!" addressing, tries to do
a UUCP path lookup and fails, bouncing the message all the way back through
the chain.
The sysadmin at remotesite has asked SCO about this problem, and SCO "hotly"
insists that MMDF is queueing proper rmail commands. But the sysadmin also has
a DOS-based UUCP package, which queues rmail commands using "@" addressing...
My questions are as follows:
1) Should remotesite be able to know that "internet.host!user" is really a
SMTP address? Is this the standard interpretation? If it is standard,
which RFCs proclaim this?
2) Is there any way to convince MMDF at remotesite to queue rmail commands
using "us...@internet.host" or "user%internet.host" addressing even if the
rmail command is going to be sent via a UUCP modem link? Be specific. I am
not a SCO sysadmin.
3) Is MMDF desirable as a Mail Transport Agent (MTA)? Should I suggest that
remotesite install a more powerful MTA such as sendmail or smail?
Any answers or suggestions would be greatly appreciated by a large community
of users! Thank you.
Tom Fitzgerald
> >3) Is MMDF desirable as a Mail Transport Agent (MTA)? Should I suggest that
> > remotesite install a more powerful MTA such as sendmail or smail?
If you go with sendmail, get IDA sendmail from one of the many possible
archive sites. It's MUCH easier to configure, and has works correctly in a
wider set of circumstances than the vanilla sendmail (or the sendmail that
SCO ships).
I really like sendmail - I'd recommend it if you have any problems at all
with MMDF.
dav...@golem.waterloo.on.ca (David J. Fiander) writes:
> MMDF is just as powerful as sendmail or smail.
This isn't quite true, sendmail does do some things that MMDF doesn't. You
can initiate phonecalls to *some* UUCP neighbors immediately when mail
arrives for them; but queue it for later with others. You can do arbitrary
header rewriting. (Many people don't need this. We do.) Sendmail can
deliver a single mailmessage to multiple UUCP recipients; MMDF will send
one message per recipent. Sendmail generally moves the mail out much
faster than MMDF. Sendmail's log is much easier to interpret.
On the other hand, MMDF makes it easier to deliver mail to processes
running as arbitrary users, or to files owned by arbitrary users. MMDF
also makes it easier to flush some, but not all, messages in the queue. I
kinda miss these....
> The difference
> between sendmail and MMDF is that humans can read MMDF
> configuration files,
IDA sendmail's m4 files are easier to read than MMDF's table files.
sendmail.cf is harder to read - but not a lot. MMDF's table files have a
fairly steep learning curve themselves.
> and MMDF conforms to RFC 822.
I believe IDA sendmail does also.... if you want to compare old MMDF's
against old sendmails, old MMDF's had serious problems with DECNET-style
addresses with :: delimiters in them.
--
Tom Fitzgerald Wang Labs fi...@wang.com "I went to the universe today;
1-508-967-5278 Lowell MA, USA It was closed...."
Mark Bixby
"some.domain.name!someuser" are legal and should be handled the same
way as addresses of "some...@some.domain.name".
I was able to modify my sendmail.cf on the gateway machine to handle this
properly.
I showed HP how they were not compliant with RFC976, and they agreed to enhance
their default sendmail.cf to provide this functionality in the future.
The Steph
fi...@wang.com (Tom Fitzgerald) writes:
>dav...@golem.waterloo.on.ca (David J. Fiander) writes:
>> MMDF is just as powerful as sendmail or smail.
>This isn't quite true, sendmail does do some things that MMDF doesn't.
I would advise caution here -- I distinctly remember David doing a comparitive analysis
of both MTA's (several weeks of effort as I recall), and it came out almost a dead heat.
Sendmail is better in some situations, and MMDF is better in others.
>You can initiate phonecalls to *some* UUCP neighbors immediately when mail
>arrives for them; but queue it for later with others.
This is easily configurable within the UUCP system. A MTA has no business managing my
modems or my polling rates. For you this may be a "feature" for me, it is crossing a
modularity boundary which confuses system administration.
>You can do arbitrary header rewriting. (Many people don't need this. We do.)
You wretched awful person! May my headers never traverse your systems. (religion can be ugly)
>Sendmail can deliver a single mailmessage to multiple UUCP recipients;
>MMDF will send one message per recipent.
Great! I hope you only talk to systems whose rmail's know how to handle this. If you
talk to a V7 based UUCP system only the first recipient will get your mail. Have people
been complaining about not getting important mail? Look carefully at this.
>Sendmail generally moves the mail out much faster than MMDF.
Hmmm, how often are you scanning your queues? I question the validity of your statement.
>Sendmail's log is much easier to interpret.
I'd buy that.
On the whole, I'd have to say that without additional tools to help the naive, both MTA's are
pretty awful. But I think that world-wide e-mail is not a game to be played by the uninitiated;
not yet at least. We're getting there. MMDF was designed well, and coded awfully. Sendmail
was designed by and for the initiated, and works just peachy for those folks. Both have
steep learning curves, and knowledge of of does not help you very much in learning the other.
IMHO, MMDF is better for systems with a large number of delivery channels, while sendmail is
better for the more simplistic and/or static configurations. Either way, they're both a long
way from usable by the great unwashed masses.
--
Steph Marr ...!{uunet, ucscc}!sco!steph
SCO Network Engineering (MX Handlers) st...@sco.COM
#include <std/disclaimer.h>
#include <random/quote.h>
Leslie Mikesell
>>Sendmail is better in some situations, and MMDF is better in others.
>Well it was a joint effort by me and somebody working for a
>company that really likes sendmail (I don't know if I can say
>what company, so I won't). The SCO version of MMDF and a
>recent IDA sendmail were about the same. sendmail won when it
>came to dealing with the kinds of broken addresses that large
>gateways need to cope with; MMDF won when it came it
>implementing policy-based routing.
Don't forget that smail3 can do all of this stuff too, and it's
relatively easy to install and configure.
>Steph, you're being facetious. There are very few systems out
>there which can't handle multiple recipients on the rmail
>command line, and sendmail can be configured to generate single
>recipient rmail commands.
Smail lets you control the grouping of multiple recipients by setting
a maximum number of addresses and a maximum length for the associated
command, and it will send only the number of messages necessary to
stay within the limits. This is configurable within a transport
definition, and you can set up mail to different sites to use different
transports if necessary to avoid having to match your most restrictive
neighbor's requirements for everyone else.
Les Mikesell
l...@chinet.chi.il.us
Jon Robinson
[A whole lot of stuff deleted.]
>
>recipient rmail commands. A more appropriate response would
>have been to say that _SCO_ MMDF _can_ be configured to pass
>multiple addresses to a single rmail invocation. In fact, then
>SCO MMDF solution is better, since sendmail can't take into
>account the fact that the maximum command line length on the
>remote end might be (dramatically) shorter that the command
>line length on the local end.
>
Oh ?!? David, can you please supply more information on this. We
here at BST provide LISTSERV like mailing list and file server
services to numerous organizations. We also do some listserv->netnews
gatewaying. One of the things I've always disliked is that when one
message comes in, literally dozens get sent out. Not good for the
UUCP modem's phone bill. What magic incantations do I need to chant?
We connect with a SunOS system for upstream mail delivery and provide
downstream feeds to numerous FIDO based networks in the tristate area
(Montana, Idaho, and Wyoming). BTW, we're running 3.2.2 if that makes
a difference.
TIA
-Jon
--
Jon Robinson @ Big Sky Telegraph, Western Montana College of the UM
INTERNET: jo...@bigsky.dillon.mt.us / VOICE:406-6837870 / FAX:406-6837493
"Sometimes yes, sometimes no. The staff usually forgets." - Fletch
David J. Fiander
>>recent IDA sendmail were about the same. sendmail won when it
>>came to dealing with the kinds of broken addresses that large
>>gateways need to cope with; MMDF won when it came it
>>implementing policy-based routing.
>
>Don't forget that smail3 can do all of this stuff too, and it's
>relatively easy to install and configure.
No. Smail can't do policy based routing either.
>Smail lets you control the grouping of multiple recipients by setting
>a maximum number of addresses and a maximum length for the associated
>command, and it will send only the number of messages necessary to
>stay within the limits. This is configurable within a transport
>definition, and you can set up mail to different sites to use different
>transports if necessary to avoid having to match your most restrictive
>neighbor's requirements for everyone else.
Smail also compiles to an enormous binary that has to be loaded
for every single mail message passing through a machine. MMDF
is a collection of smaller programs, each with a specific task.
- David
Larry Snyder
>Don't forget that smail3 can do all of this stuff too, and it's
>relatively easy to install and configure.
I really like smail3 release 28. We are on the internet
directly and are MXing for maybe 4 sites using smail3 and
everything is working very well except for one problem.
I do have one problem -- traffic for indycms.iupui.edu gets
returned as "missing domain". I don't understand this -- I
can ping the machine. We are using the bind router with a
nameserver so we know the direct route to the machine. Does
anyone have any ideas?
--
Larry Snyder internet: la...@gator.rn.com
keeper of the Gator uucp: uunet!gator!larry
David J. Fiander
>
>IDA sendmail uses dbm style data bases to allow specific policy
>based routing (pathtable, mailertable, domaintable.) It is *VERY*
>easy to gateway SMTP-->uucp-->SMTP with a variety of addressing
>conventions. I haven't worked much with MMDF II but from my
>original MMDF days, IDA-sendmail is a big win over MMDF. I can think
So, IDA sendmail can select the route to use based on
originator's machine, destination machine, or the method by
which the message arrived? Then I withdraw all my statements
about MMDF being better than sendmail. However, I do think
that you are confused. MMDF allows one to enforce
Administrative policies defined by external sources which do
not have any technical basis (for example, PSI not allowing
downstreaming). In fact, MMDF allows one to select among
multiple redundant routes based on the policy.
- David
David J. Fiander
>Oh ?!? David, can you please supply more information on this. We
>here at BST provide LISTSERV like mailing list and file server
>services to numerous organizations. We also do some listserv->netnews
>gatewaying. One of the things I've always disliked is that when one
>message comes in, literally dozens get sent out. Not good for the
>UUCP modem's phone bill. What magic incantations do I need to chant?
This is exactly why we did this.
>(Montana, Idaho, and Wyoming). BTW, we're running 3.2.2 if that makes
>a difference.
Yes it does. You should upgrade to 3.2.4, or get the MMDF TLS
(I forget the number). The TLS contains the same version of
MMDF as that in ODT 2.0 and UNIX 3.2.4. The TLS is reported as
being for ODT 1.2, but it works fine with UNIX 3.2.2 too (after
all, that's what I developed it on).
The TLS uucp channel supports confstr parameters which allow
you to set the maximum number of address that UUCP hosts on the
channel can process. See the documentation for details.
- David
Leslie Mikesell
>No. Smail can't do policy based routing either.
What's "policy based"?. Smail can do just about anything you would want
to do in terms of routing based on the destination address. If you
want to base the routing on something else you can construct a
program that does what you want and use the "queryprogram" router
to run it.
>Smail also compiles to an enormous binary that has to be loaded
>for every single mail message passing through a machine. MMDF
>is a collection of smaller programs, each with a specific task.
Mine's about 190K (w/SMTP and debugging compiled out) which is hardly
enormous these days. Besides if you have demand paging (and who
doesn't?) the size of a binary doesn't matter. If you want efficiency
you can set "queue-only" mode and run a daemon for the actual delivery.
On shared text machines if you arrange for "rmail", "runq", etc. to
be links to the daemon program you never actually load another copy
of the binary. I have slow, busy machines and I pay attention to this
kind of thing. In particular it smooths the load on machines where
batches of mail come in at once via uucp.
Les Mikesell
l...@chinet.chi.il.us
John R MacMillan
|
|This isn't quite true, sendmail does do some things that MMDF doesn't.
And MMDF does some things sendmail can't. The two are approximately
as powerful as each other; they just have slightly different strengths
and weaknesses.
|You
|can initiate phonecalls to *some* UUCP neighbors immediately when mail
|arrives for them; but queue it for later with others.
It's been a while, but I believe you could do this with MMDF by
putting the different hosts on different channels, one configured with
mode=imm, the other mode=reg.
|You can do arbitrary
|header rewriting. (Many people don't need this. We do.)
Sort of religious; I believe in header rewriting is usually Evil,
except for some gatewaying. I'm not very familiar with IDA sendmail
but the sendmail shipped with the UNIXes I've had to use made it
incredibly difficult _not_ to rewrite the header, which I find more
objectionable than MMDF.
|Sendmail can
|deliver a single mailmessage to multiple UUCP recipients; MMDF will send
|one message per recipent.
SCO's current MMDF does this even better than sendmail because it's
more configurable. Sendmail as I recall has no way to limit the
generated command length (either in characters or by number of hosts)
based on the _remote_ site's ability to handle it.
|Sendmail generally moves the mail out much
|faster than MMDF.
Generally introducing a higher load on the machine; MMDF is generally
better for passing a high volume of mail.
|Sendmail's log is much easier to interpret.
But you can change the level of logging info easier with MMDF.
|On the other hand, MMDF makes it easier to deliver mail to processes
|running as arbitrary users, or to files owned by arbitrary users. MMDF
|also makes it easier to flush some, but not all, messages in the queue. I
|kinda miss these....
On the other hand, it's possible to add new mailers with sendmail
without recompiling...
Of course on chance I don't use either, I use smail3.1, which is
another story entirely.
Roger Cornelius
>
> The TLS uucp channel supports confstr parameters which allow
> you to set the maximum number of address that UUCP hosts on the
> channel can process. See the documentation for details.
If this is in the documentation I can't find it. I have 3.2v4 and
the mmdftailor(F) man page says about confstr:
confstr a channel-specific configuration string. See the
individual manual pages for the channel for more
information.
There is no documentation on the uucp channel (or any channel)
that I can find. I've also looked through the chapter on mmdf in
the System Administrator's Guide with no luck.
I posed this same question to SCO support back when I had a support
contract and this was the reply:
--- cut here ---
Received: from uunet by sherpa.UUCP id aa26702; 26 Feb 92 18:10 EST
Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA10581; Wed, 26 Feb 92 16:10:19 -0500
Received: from sco.UUCP by uunet.uu.net with UUCP/RMAIL
(queueing-rmail) id 160951.16169; Wed, 26 Feb 1992 16:09:51 EST
Received: from uscopia.sco.COM by sco.sco.COM
id aa26347; Wed, 26 Feb 92 12:25:35 PST
From: Greg Oetting <gr...@sco.com>
To: sco!sherpa!r...@uunet.UU.NET
Subject: Re: r#456267 mmdf problem
X-Mailer: SCO Office Portfolio (version 2.0)
Date: Wed, 26 Feb 1992 12:21:50 -0800 (PST)
Message-Id: <920226122...@uscopia.sco.COM>
Status: OR
Roger,
Regarding ref#456267 - MMDF and multiple messages
In speaking with the most senior mmdf engineer, I got the following
information. I don't know if this will work, but you can try and
see. If it does, I'd appreciate knowing it does for future reference.
Here's the info I got:
This is an issue with the rmail program. Currently the rmail program only
accepts one address per message. In 3.2v4, the rmail program can accept
multiple addresses. This is a historical issue, many rmails out there only
accept one address on the command line.
Additionally, MMDF in 3.2v4 can be configured so as to set up the UUCP
channel so that the rmail command executed at the other end will be
given multiple addresses on one command line, and hence only one UUCP
job for that site will be sent....
The issue arises as to whether or not the remote site's rmail program
accepts more than one address. You need to know the answer to this
prior to setting up MMDF to "batch" rmail requests into one.
In 3.2.4, just add to the UUCP channel entry:
naddr=#, where # is the number the remote site can reasonably take...
i.e.
MCHN uucp, ..., ap=822, naddr=10, mod=imm....
Hope this helps.
Gregory Oetting
SCO Technical Support
--- cut here ---
I never was able to make this work. Doing a strings on ~mmdf/chans/uucp
reveals "naddrs=", leading me to believe that the keyword to use is
"naddrs" rather than "naddr" but that doesn't work either.
If this is indeed in the docs somewhere, how about pointing us in the
right direction.
--
Roger Cornelius sherpa!r...@uunet.uu.net ...!uunet!sherpa!rac
David J. Fiander
>> The TLS uucp channel supports confstr parameters which allow
>> you to set the maximum number of address that UUCP hosts on the
>> channel can process. See the documentation for details.
>
>
>If this is in the documentation I can't find it. I have 3.2v4 and
>the mmdftailor(F) man page says about confstr:
>
> confstr a channel-specific configuration string. See the
> individual manual pages for the channel for more
> information.
>
Well, I worked on the code, not the documentation.
>Here's the info I got:
>
>This is an issue with the rmail program. Currently the rmail program only
>accepts one address per message. In 3.2v4, the rmail program can accept
>multiple addresses. This is a historical issue, many rmails out there only
>accept one address on the command line.
>
True. In particular XENIX rmail can't handle more than one
address.
>In 3.2.4, just add to the UUCP channel entry:
>
>naddr=#, where # is the number the remote site can reasonably take...
>
>i.e.
>
>MCHN uucp, ..., ap=822, naddr=10, mod=imm....
Close. Try confstr="naddrs=#"
Robert Story
> According to ma...@spock.dis.cccd.edu (Mark Bixby):
> > remotesite install a more powerful MTA such as sendmail or smail?
>
> between sendmail and MMDF is that humans can read MMDF
> think sendmail conforms, then I suggest you read RFC 822 and try
> passing conforming messages with group addresses or BCC headers
> through sendmail.)
Aw, come on David, while at X/Open, I used group addresses and bcc
headers quite successufully with sendmail (HP/UX 9000/817 8.02).
Perhaps you are burying all sendmails for the limitations that you
found in one!?
Personally I'm not *keen* on MMDF. Its documentation leaves a great deal
to be desired (it doesn't work as documented). I've been thinking of
switching to IDA sendmail.
-Robert.
--
_________________________________________________________________________
Robert...@Elegant.COM Elegant Communications Inc.
Tel: +1 416 362 9772 4 King Street West Suite 1101
Fax: +1 416 362 8324 Toronto, Ontario; CANADA M5H 1B6
David J. Fiander
>enough to include it in the documentation. Or maybe the engineering
>and documentation departments should communicate more often :-(.
Well, they are communicating better than they have in the past
(see the ODT 1.0 MMDF documentation, for example), but this
isn't documented for a couple of reasons. First, it was a
relatively late addition, and second, there isn't anyplace to
put it in the University distribution, and we didn't have time
to write manpages for all the channels.
- David
David J. Fiander
>
>Aw, come on David, while at X/Open, I used group addresses and bcc
>headers quite successufully with sendmail (HP/UX 9000/817 8.02).
>Perhaps you are burying all sendmails for the limitations that you
>found in one!?
Well, it is possible to get group headers to work, but the
problem is that they are processed by the sendmail.cf file.
This means that every single sendmail administrator has to have
all of RFC 822 at her fingertips before attempting to change
the configuration, because well formed sendmail.cf that does
what she wants may not conform any more.
Bcc headers are different. What sendmail does with them is
_wrong_, and there is no way to fix it without major hacking on
the code. RFC822 allows for a mail message to look like
From: "David J. Fiander" <dav...@golem.waterloo.on.ca>
Subject: this is a test message
Bcc:
Hi guys. None of you know who any of the others are.
This should be delivered as-is, and untouched by the MTA, but
the first sendmail to see this will strip out the Bcc header.
The second sendmail that sees it will discover that there are
no valid recipient headers, so it will add an "Apparently-To"
header which lists all of the recipients that that sendmail
knows about (basically all the recipients on the same machine,
or on the far side of the same gateway). So much for _blind_
carbon copies.
>
>Personally I'm not *keen* on MMDF. Its documentation leaves a great deal
>to be desired (it doesn't work as documented). I've been thinking of
>switching to IDA sendmail.
>
The documentation is better than it used to be, and is getting
better. The sendmail documentation isn't much better; at least
now people are writing books (or chapters in books) about how
to configure sendmail. Hopefully, the same sort of thing will
happen with MMDF soon.
- David
George Farris
: David J. Fiander (dav...@golem.waterloo.on.ca) wrote:
: [A whole lot of stuff deleted.]
: >
: >recipient rmail commands. A more appropriate response would
: >have been to say that _SCO_ MMDF _can_ be configured to pass
: >multiple addresses to a single rmail invocation. In fact, then
: >SCO MMDF solution is better, since sendmail can't take into
: >account the fact that the maximum command line length on the
: >remote end might be (dramatically) shorter that the command
: >line length on the local end.
: >
: Oh ?!? David, can you please supply more information on this. We
: here at BST provide LISTSERV like mailing list and file server
: services to numerous organizations. We also do some listserv->netnews
: gatewaying. One of the things I've always disliked is that when one
: message comes in, literally dozens get sent out. Not good for the
: UUCP modem's phone bill. What magic incantations do I need to chant?
: We connect with a SunOS system for upstream mail delivery and provide
: downstream feeds to numerous FIDO based networks in the tristate area
: (Montana, Idaho, and Wyoming). BTW, we're running 3.2.2 if that makes
: a difference.
I have looked through the manuals as well and can't find this
information. If someone out there knows how to send mail to multiple
addresses as one would want in a mailing list application, please let
the rest of us know.
--
==========================================================================
George Farris - VE7FRG Internet : geo...@ve7frg.ampr.org
Amprnet : geo...@ve7frg.ampr.org
Bernd Felsche
dav...@golem.waterloo.on.ca (David J. Fiander) writes:
>According to r...@sherpa.UUCP (Roger Cornelius):
>>> The TLS uucp channel supports confstr parameters which allow
>>> you to set the maximum number of address that UUCP hosts on the
>>> channel can process. See the documentation for details.
>Well, I worked on the code, not the documentation.
>>MCHN uucp, ..., ap=822, naddr=10, mod=imm....
>Close. Try confstr="naddrs=#"
Standard mmdf2 distribution I have has naddrs= #ifdef'd out.
--
+-----+ Bernd Felsche _--_|\ #include <std/disclaimer.h>
| | | | MetaPro Systems Pty Ltd / \ ber...@metapro.DIALix.oz.au
| | | | 328 Albany Highway, X_.--._/ Fax: +61 9 472 3337
|m|p|s| Victoria Park, Western Australia 6100 v Phone: +61 9 362 9355
David J. Fiander
>>Close. Try confstr="naddrs=#"
>
>Standard mmdf2 distribution I have has naddrs= #ifdef'd out.
That's right. That's why I was very careful to say SCO MMDF as
shipped in the MMDF TLS. I rewrote the UUCP channel almost
from scratch while working for SCO in order to provide this
essential functionality.
- David