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 here).
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 doing:
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 HELO scobox.corporate.com 250 OK MAIL From:<email@example.com> 250 OK RCPT To:<firstname.lastname@example.org> 250 Recipient OK DATA 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 "." . 250 OK QUIT 221 Goodbye
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 working.
Got something to add? Send me email.
More Articles by Tony Lawrence © 2012-07-21 Tony Lawrence