MMDF to Exchange- and Back!
Recently I contracted to solve an Email problem for a national
food chain who uses SCO servers in their stores. The individual
servers have always had uucp based email communication with each
other, and at one time had communication with the rest of the
corporate network through a CC-MAIL uucp gateway by way of a main
corporate Sco server. Individual machines relayed all mail through
the main corporate box, which in turn would pass corporate messages
to the CC-MAIL machine and would transfer messages to other stores
back out using uucp. However, when the corporate network began
using Microsoft Exchange, the functionality of the CC-MAIL gateway
was lost, and they needed another way to communicate.
All of the out-lying stores had recently been upgraded to OSR5,
but the corporate SCO server still ran 3.2v4.2. MMDF was the
standard for all SCO machines. Fortunately, the corporate machine
did have tcp/ip installed.
The first step was to configure MMDF to be able to use tcp/ip.
On the 3.2v4.2 release, this requires su'ing to mmdf ("su - mmdf")
and then executing "mkdev mmdf". The questions asked are very
similar to what you get in the modern, more graphical
configuration. You might wonder if there is any danger in
configuring both uucp and tcp/ip mail: there isn't. MMDF is smart
enough to know what hosts use uucp, and will only use uucp for mail
addressed to those hosts. I designated the Exchange server as a
"smart host" for unknown domains and unknown users. This means that
any address not understood by the corporate server will be passed
to the Exchange server.
On the Exchange side, I had to be sure that Exchange was
configured to allow the corporate server to transfer SMTP mail.
That's under Organization\Site\Configuration\Connections\Internet
Mail Service. Double-click or choose "Properties" from the top
menus. You'll be at the "Internet Mail" tab, and under
"Connections" you'll find a button for "Accept Connections". In
this case, the server was set to accept anything from anyone, so I
didn't have to change anything. But if it hadn't been, I would have
had to give explicit permission for the corporate server to use
SMTP with Exchange.
Back to the Unix side, it was now necessary to check the
individual stores. These need to also have a "smart host", but this
time it is the corporate server. Unfortunately, they were not
already configured that way, so some extra work would be required.
Note that it was very important in all these MMDF configurations
NOT to hide the individual machines behind the corporate addresses.
If we had done that, we'd have a terrible routing problem because
there is duplicate name space at each store: that is, there is
"firstname.lastname@example.org" and "email@example.com". I
considered changing this, but too many other systems depended on
that convention, so we had to leave it as is for now.
At this point, a store could send mail to
"firstname.lastname@example.org". The local MMDF would not recognize the
domain, so it would send the mail to its "smart host"- the
corporate server- by uucp. That server in turn wouldn't recognize
the address, and since its "smart host" is the Exchange server, it
will use tcp/ip (SMTP) to transfer the message to Exchange, which
then delivers it to the appropriate place (note that the Exchange
server itself also has a "smart host", but that doesn't concern us
Now, of course, we have to get back to the stores. That requires
another configuration of Exchange: on the same Property sheet as
before, you'll also notice an "E-Mail Domains" button (under
"Connections"). Here, I specified that the "corporate.uucp" domain
is to be routed to the SCO corporate server (as that server is not
in their DNS, I just used its IP address).
Let's look at what happens from the Exchange user's desktop.
That original message we sent has a reply address of
"email@example.com". When the user clicks "Reply",
the message goes to Exchange. Normally, that would get relayed out
to its "smart host" (or resolved with DNS), but because we've added
an E-Mail Domain, it sees that this message does indeed belong to
"corporate.uucp", so it initiates an SMTP conversation with the
corporate SCO MMDF machine. That machine accepts the mail, and
immediately recognizes that "store100.corporate.uucp" is one of the
places it knows how to reach by uucp, so it does exactly that.
It's really just that simple, however you can make mistakes, so
it is helpful to have some debugging tricks up your sleeve. First,
on the Exchange side, you'll find a "Message Tracking" choice under
the Tools menu. You can specify a particular user, and see just how
Exchange has treated the test messages you've created. It's not
necessary to enter anything more than the user's address: if you
leave the other fields blank, all current messages will be
displayed. It's interesting to see that the messages sent back
(that will be going to "firstname.lastname@example.org") show up
in tracking in X.400 format, even though SMTP will obviously be
used to transmit them.
On the MMDF side, both the "uustat" command and the
"/usr/mmdf/bin/checkque" can be helpful. The "uustat" command will
show what mail (or other uucp jobs) are queued for delivery to
another site, while "checkque" shows the work that MMDF has been
Thu Jun 3 06:55: 0 queued msgs / 1024 byte queue directory
0 Kbytes in msg dir
0 msgs 0 Kb (local ) local : Local delivery
deliver start : Thu Jun 3 05:59
deliver message : Thu Jun 3 05:59
deliver end : Thu Jun 3 05:59 / 0 hours
0 msgs 0 Kb (list ) list : Mailing list processor
No deliver start
No deliver message
No deliver end
0 msgs 0 Kb (smtp ) smtp : SMTP Delivery
deliver start : Thu Jun 3 07:42
deliver message : Thu Jun 3 07:42
deliver end : Thu Jun 3 07:42 / 0 hours
0 msgs 0 Kb (uucp ) uucp : UUCP Delivery
deliver start : Thu Jun 3 07:52
deliver message : Thu Jun 3 07:52
deliver end : Thu Jun 3 07:58 / 0 hours
You can tell if MMDF has done any work in a particular queue by
looking at the deliver time stamps: deliver does not run against a
queue with no work to be done. So, if you have sent uucp or smtp
mail, but don't see a recent time stamp, something went wrong.
To see if Exchange has initiated an SMTP conversation with you,
check "ls -lut /usr/mmdf/chans"- if "smtpsrver" has a recent
time stamp, then someone was talking to it. Also see MMDF
Troubleshooting on SCO's web site for more hints.
If you suspect that SMTP may not be working correctly, you can
impersonate the MMDF server by telneting to port 25 of the Exchange
server ("telnet exaddress 25") and pretending to be another SMTP
server. The conversation will go something like this: (responses
from the server always begin with a number and are shown in a
different font here)
telnet exchange.corporate.com 25
220 Exchange version such and such ready
250 Recipient OK
354 Enter Mail, end with "."
A real mail message would include other headers
but for testing, this is fine.
Note the last line will be just a "."
If you can talk to Exchange (or any SMTP server) manually, than
any real SMTP server should be able to also, and if it cannot,
there's a misconfiguration somewhere.
You also might find this MMDF FAQ useful.
Finally, keep in mind that this also could have been done with
Sendmail; it was just easier to use what was already in place and
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Tony Lawrence
Find me on Google+
© 2012-07-21 Tony Lawrence