Recently Tom DeLombarde (email@example.com) wrote to me concerning a client with a problem. I've reproduced part of his email here:
The project: One of my clients is having the plug pulled from the uucp account that psi.net has hosted for many years. Their system is SCO OS5 and we have used mmdf and a direct-dial connection for E-mail service. Since I have a linux web server with qmail and vchkpw installed and operational, I offered to host their E-mail only account - and of course they had to wait until a week before the plug is to be pulled to give me the go-ahead. My problems: I am unfamiliar with SMTP, have always used uucp on business systems like this one and POP3 on the web server. What I think can be done is: Configure the SMTP channel in mmdf to use a dial-up ppp connection (through their ISP) with which to connect to my server and collect mail. This would effectively work like the uucp system did: Every xx minutes, dial a modem and collect the mail, which will be distributed by the existing local channel configuration (alias etc. are functioning properly now). So far, the catching point has been the dial-up ppp connection. After reading your article on this, I can now manually raise this connection, but am having problems making the transparent bring up work. I think that if I can make this happen, it is just a matter of configuring the SMTP channel to point to an address that will trigger the dial out.
The system Tom referred to is a 3.2v5.0.0, which is why the dynamic ppp link doesn't work (prior to 5.0.4 you need a static IP address for a dynamic link). I suggested that Tom take a look at my Mail article and consider using fetchmail. As he would now be the ISP for mail, using fetchmail would give him the ability to just have one multidrop mail account for this client on his server, letting fetchmail distribute that account to the various real accounts on the client's server. Tom liked that idea:
Put fetchmail on the SCO OS5 machine (the mail 'client' if you will). As I understand, this will collect all mail and feed it to mmdf's SMTP channel for local distribution. If I run fetchmail from cron, I think that I will even be able to use my hack of your manual bring-up for the ppp link. That would pretty well solve my most immediate and (so far) stickiest problem. Doing this would also have benefits on the mail server end: I could use a single POP user on the server. The combination of qmail and vchkpw that I am now using there is really tailored for POP use and this will give me the filtering capabilities that I will need in the near future - the SCO system is character based, slow modems; but this is a publishing house, so their clients often send huge binary files to this system. Not only are these files completely useless on this system, but they clog the pipe through the slow modems. I will ultimately forward (on the server) these to a POP account to be picked up by one of the Mac users in layout. With SMTP on the server, this would have been difficult.
Because he couldn't get the dynamic link, Tom modified my "up" script from the Quick PPP setup article. As originally written, that script doesn't give up- it just keeps trying and trying and trying. That's OK for desktop use, but if you are going to stick this into a cron job, it needs to be smarter. Here's Tom's modifications with his comments:
: # up.sh - establish manual ppp link through dial-up # 09 Sept 1999 Hacked from A.P. Lawrence's <firstname.lastname@example.org> # 'up' script /Unixart/quickppp.html # by Tom deLombarde <email@example.com> # # removed call to down, replaced with test for previously # established ppp link # /usr/bin/down # call ifconfig just to set error status /etc/ifconfig ppp0 # if already attached, we will use it, # notify user (log) and exit clean: if [ $? -eq 0 ] then echo 'Already up.' exit 0 fi # no existing ppp link, try to establish one: /etc/pppattach bright # set counter so we can bomb out in case the modems # are otherwise occupied: tries=0 # wait for pppattach to dial and negotiate: sleep 60 # loop until we get ppp0 up or the counter expires: while [ $tries -lt 10 ] do echo 'tries = '$tries tries=`expr $tries + 1` ip=`/etc/ifconfig ppp0 | grep inet | cut -d" " -f2` && /etc/route add default $ip /etc/ifconfig ppp0 && exit 0 sleep 5 done # if the script made it to here, it failed (exit 0 above): echo 'Connection failed, could not raise ppp0.' exit 1
With that modification, he could now use this to both deliver and get mail:
: # getmail.sh - script to be called from cron to get mail # 09 Sep 1999 - Tom deLombarde <firstname.lastname@example.org> # # This script is dependent upon: # A.P. Lawrence's <email@example.com> 'up' and 'down' scripts: # /Unixart/quickppp.html # # This script uses a hacked version of A.P. Lawrence's 'up' # script to raise a ppp connection through a dial-up account. # The ppp connection is used to allow fetchmail to retrieve # from a server over inet and deliver it to SCO's MMDF on the # local system. This should also work with sendmail, qmail or # any properly configured MTA that supports SMTP # # Also required is fetchmail # https://www.ccil.org/~esr/fetchmail/ # Running from cron, I don't want the output mailed to root, # so set up a crude logging system: logfile=/usr/mmdf/getmail.log # keep the log file from running away with the disk drive: tail -5000 $logfile > $logfile.tmp mv $logfile.tmp $logfile # place a dated header for each entry into the log: echo ' ***** Begin Transaction ***** '`date` >> $logfile # call the 'up' script to raise a ppp connection: /usr/bin/up >> $logfile 2>&1 # if we made a connection, go for it: if [ $? -eq 0 ] then # send local outgoing to server now that we have a connection: # (these are MMDF specific commands) /usr/mmdf/bin/deliver -csmtp >> $logfile 2>&1 /usr/mmdf/bin/deliver -cbadhosts >> $logfile 2>&1 /usr/mmdf/bin/deliver -cbadusers >> $logfile 2>&1 # time for fetchmail to collect incoming (will just hand over to # the SMTP channel of MMDF or sendmail, etc.) /usr/mmdf/bin/fetchmail >> $logfile 2>&1 # then tear down the ppp0 interface: /usr/bin/down >> $logfile 2>&1 else exit 1 fi
Tom did have to make some changes to MMDF:
To make it work with MMDF, I set up in /usr/mmdf/mmdftailor (for outgoing): MCHN show="Last-Chance Routing", name=badhosts, que=badhosts, tbl=smtpchn pgm=smtp, ap=822, mod=imm, confstr="hostname=machine.domain.com", host=mailhost.com MCHN show="Last-Chance Routing", name=badusers, que=badusers, tbl=smtpchn pgm=smtp, ap=822, mod=imm, confstr="hostname=machine.domain.com", host=mailhost.com Then defined the smtp channel in /usr/mmdf/table/smtp.chn: mailhost.com yyy.yyy.yyy.yyy That was really the only MMDF-specific stuff I had to do (this is assuming an otherwise properly configured MMDF system, I was just replacing the UUCP/direct dial server with the SMTP-POP3/dial-through-ISP server). The simple .fetchmailrc file I used is: poll mailhost.com localdomains domain.com: user maildrop%domain.com with pass notreal to * here Tom deLombarde FTM Development 23 West Main Street Suite 208 Shelby, Ohio 44875 (419) 342-6842 Voice (419) 342-6843 Voice (419) 342-6842 FAX firstname.lastname@example.org https://www.blackflute.com/
Got something to add? Send me email.
More Articles by Tony Lawrence and Tom DeLombarde © 2012-07-15 Tony Lawrence and Tom DeLombarde