APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Handling mail messages in a virtual domain environment under
© October 2000 Roberto Zini
SCO OS 5.0.5

© October 2000 Roberto Zini, Strhold Sistemi Edp - Italy


This document aims at describing the steps an OpenServer 5.0.5 administrator should take in order to configure a virtual domain email management server. The need for a single server to handle several virtual domains is pretty common nowadays, where a 24hrs a day permanent connection to the Internet is not something that anyone could afford (at least here in Italy :-); so, a situation where a company acts as an Internet Service Provider (ISP) for some customers is becoming more and more requested.


The idea behind this article stems from a customer of mine (let's call him Ivo); Ivo's company has an OpenServer 5 server which acts as an Internet gateway. Thanks to its permanent Internet connection, the server can handle local WEB and FTP services, along with incoming and outgoing email messages (not to mention that this machine also acts as a proxy server for a group of local Windows based PCs). One of Ivo's customers, who can't afford a 24hrs a day Internet connection, asked him to "host" his company Internet services; technically speaking this is quite possible under SCO OpenServer, thanks to its IP aliasing capability, a feature which allows a single network interface to have more than one IP address associated with it. To complicate matters, the customer has a LAN which is built around a SCO OpenServer 5 server that's used by his colleagues to access the account package and all the rest; last but not least, that machine collects and delivers local email messages.


Talking about the messaging subsystem, the customer's server should continue to operate as usual; while operating "off-line" (i.e, not connected to the 'Net), it should spool outgoing messages whose recipients are not local. While "on-line" (i.e. connected to the 'Net), outgoing messages should be directed towards Ivo's server which in turn routes them to their final destination. At the same time, the customer's server should be able to gather incoming messages received by Ivo's one, thus allowing remote users to actually use the mail subsystem at its full potential.


Numbers, numbers, numbers


OK, let's start by giving some names and numbers; Ivo's server (the one connectet to the 'Net 24hrs a day) will be called server.domain1.it (serverA) while the remote one will be called server.domain2.it (serverB): I'm assuming here that both domain1.it and domain2.it are fully qualified and registered Internet domains.


The following table will clear up things (please bear in mind that the following numbers - in the 192.168.0.x class - are given only to ease the reading ot the document) :


Server A (Internet side):


IP Address : (Assigned by the Internet Authority)

Netmask :

Broadcast :

Name : server

Domain : domain1.it (Registered with the Internet Authority)


Server A (LAN side):


IP Address :

Netmask :

Broadcast :


Please notice that ServerA has 2 network interfaces; one ( which routes packets to the 'Net and one ( which handles internal LAN packets.


Hosted domain : domain2.it (Registered with the Internet Authority)

IP Address : (Assigned by the Internet Authority)


This is the name and IP number that Ivo's customer previously registered with the Internet Authority.


Under this configuration, a single host (server.domain1.it) can handle different WEB and FTP servers, each with a separate filesystem storage space; the same server is also able to accept and handle messages whose recipients are both under the domain1.it domain (eg, fred@domain1.it) and domain2.it (eg, fred@domain2.it) by keeping a separate stogare are for them and without mixing messages.


The same server has an Incoming PPP connection configured in order to accept a remote PPP connection call from ServerB, whose details follow:


ServerA PPP endpoint address :

ServerB PPP endpoint address :


Please notice that a PPP connection between the two machines is not strictly required; ServerB could connect to a local ISP to get in touch with ServerA.


The ServerA network includes some other machines as well; they're in the 192.168.3.x range (with 1 being assigned to the server itself), with identical netmask and broadcast addresses as previously shown.


Server B:


IP Address :

NetMask :

Broadcast :

Name : server

Domain : domain2.it


As you can see, what's really important in the above picture is the domain name: the IP address assigned to the server should be different from the registered one, while the domain name can't if you want to be able to handle locally composed messages;also, this machine has a manual outgoing PPP connection to get to the 'Net (in the above scenario, the PPP connection is used to directly get in touch with ServerA but, as stated above, this is not strictly required).


I won't go any further concerning PP details; Tony's site has a lot of useful information about this issue and you should be able to build yours by reading his excellent articles and by following the OpenServer online docs (keep up the good work Tony ! :-).



ServerA configuration


Assuming ServerA is already connected to the 'Net, we focus our attention here on the virtual domain configuration; for this to be accomplished, you must use the SCO Internet Manager, an easy to use graphical tool located on the OpenServer 5 desktop.


There are some tricks you have to know if you want to succesfully handle this configuration, the first one being the local DNS configuration. The simplest DNS client configuration assumes there's a /etc/resolv.conf file on your machine configured as follows:


hostresorder local bind

search <first_domain> <second_domain>

nameserver <ip_address>


The first line tells the resolver (a library networking programs use to get the IP address from a given host name) to search the /etc/hosts file first (local) and then to ask the server (whose address is given in the nameserver line) if the name can't be locally resolved (bind). The second one tells the resolver to append the given domains to the hostname when a program tries to refer it without giving its fully qualified name (es, ping fred should be expanded to fred.first_domain fist; if a match is not found, it should be expanded to fred.second_domain).


ServerA could also be the primary DNS server for the local domain; in this case, you need to modify several files (namely /etc/named.conf and some under /etc/named.d) to allow your machine to serve requests for the new domain (these issues are outside of the scope of this document and they won't be discussed any further).


In any case, please do a backup copy of the /etc/resolv.conf file since the Internet Manager is well known to screw it up a little bit (don't tell me I didn't tell you :-) !


Once at the OpenServer graphical desktop, you can either click on the Internet Manager icon or use the local browser to access the https://localhost:615/mana/mana/init.mana URL; both will get you to a prompt which allows you to enter the manager (you should type admin as username an give your root password to actually get to it).


Hint: the Internet Manager does an "username verification" before letting you in; as stated above, you'll have to login as user admin and give the root password to get to the main page. Please notice that the password that has to be given here is the one you assigned to user root at the OS installation time; if you later changed the root password, you'll be forced to use the previous one anyway. In case you forget it, you can manually hack the /usr/internet/admin/acces/.htpasswd file; this file is made up by a single line which holds the username of the user allowed to login (admin by default) and an encrypted password (the 2 items are colon separated, eg: admin:HHDGD.,.JJJ - please notice that punctuation marks - if any - are part of the encrypted password themselves). The simplest way to hack it is to remove the password field, thus leaving the admin: entry "alone". In this case, you'll only have to type admin at the verification prompt to get to the IM (Internet Manager) main page (i.e, leave the password field empty); if you do want to use your current root password, you can grab the encrypted password from the /etc/shadow file and insert it into the above one. As an example, the shell command "grep root /etc/shadow | awk -F: '{ print "admin:"$2 }' > /usr/internet/admin/acces/.htpasswd" will do the trick (bear in mind that you have to operate as root for the trick to work).


The first IM page allows you to specify the device the system uses to connect to the Internet; if your machine has 2 NICs, please be sure to speficy the one which connects it to the 'Net. You can also uncheck the Test Internet Connection checkbox if you don't want to actually check the connection. The second one allows you to insert the IP address of the Default Gateway; you can leave it blank if you already have a default route to the 'Net.


From this page you can click on the [Enable Virtual Domains] button to "ungroup" the network interfaces; this will create several folders under the /usr/internet/ip path that are having the same names of the IP addresses currently being used by the interface itself (es, for localhost, for ServerA and so on). Under these folders, the IM will store files related to the services being configured (WEB, FTP, Email), in order to avoid confusion among the different interfaces.


At this point, check if the IM managed to "corrupt" your DNS configuration; to do this, switch screen (by pressing CTRL-ALT-Fx) and check if the /etc/resolv.conf file contents have been changed. If they have (check for a "nameserver" line in that file), replace it with the previously backed up one.


Once back to the Internet Services menu, you can configure the "hosted" domain (domain2.it); click over the [+Add] icon (there's a picture of a PC in it) and fill the form with the following information:


Name : domain2.it

IP Address :

Admin user : root (pick the one you want - usually is root)

Password: type a password of your choice


Once finished, you can see how changes have been reflected into the /usr/internet/ folder; among the other things, this directory name will be referred by a particular script under the /etc/rc2.d folder (namely S90atlas) which, while entering multi-user mode, will add this IP address to the list of the "aliased" ones so that you won't have to add it manually every time the system boots. To check it, please try by pinging the address; if the command works as expected (and it should), it's time to have a coffee and take a deep breath :-)


You can now define the hosted WEB and FTP services; once returned to the IM main page, select the just created virtual domain (it appears twice; just click one) and click over the [FTP] icon. You can now decide if anonymous users are allowed to access your server and if you want to make the /pub directory writeable by everyone who connects.


To test the newly created service, please switch to the /usr/internet/ folder and create the pub/test file by using the touch(C) command. Next, connect to the server by using your character oriented ftp client (e.g, ftp or by using a PC browser (e.g,; log in as user anonymous and check to see if the pub/test file does really exist.


To define the WEB services associated with the new domain, switch back to the IM and click on the [WEB] icon; a new link will appear on the screen allowing you to use the Netscape FastTrack Server to configure your WEB server according to your needs. Again, to check if things are working as expected, switch screen and check the /usr/internet/ folder; it should be a symbolic link to /usr/internet/ns_httpd/httpd- A main page should already have been created for you; to access it, fire up a browser and open the URL. If the default FastTrack main page gets depicted on the screen, take another deep breath and go on reading :-)


Now, you must configure the messaging subsystem in order to send and receive emails to/from the new domain; to do this, select the [Mail] icon from the IM page: a form will appear on the screen, through which you can define the users allowed to receive messages for that domain.


This is the key factor for a successfull configuration; messages to users who have not been configured under this form will be rejected so make sure every remote user has an entry here (do not add them via the Scoadmin Account Manager interface !). By selecting [Add User] you can add a new user to the domain; you can later change his/her password by making use of the [Change Password] button and delete users by making use of the [Delete User] button as well.


Information about the newly created users will be inserted into the /usr/internet/; this file will resemble the /etc/password one, expect for the encrypted password which the latter doesn't have.


Before proceeding, please make sure that the config file does contain the following lines:





A little problem has been spotted if the /usr/internet/lib/sco_mail directory does not have permissions set to 755 (rwxr-xr-x); I've noticed that IM likes to screw them up so double check if you have to manually change them. Also, check if the domains.db file does exist under the above dir; if it doesn't, first check if the domain file contains the following:


domain2.it /usr/internet/ip/


If it does, create the domains.db file by using the following command:


makemap hash domains < domains


This little trick should only apply after adding the first virtual domain user; once done, it shouldn't be required any longer (give it a check every now and then just to be sure).


The virtual domain messaging subsystem configuration is now completed; now it's time to configure Sendmail to handle incoming messages for the domain2.it domain. Since ServerA is currently operating on the 'Net, we'll assume that someone managed to correctly configure sendmail to send and receive emails; thus means that someone made an entry into the DNS configuration files in order to let the Internet know that ServerA is able to receive messages for the @domain1.it domain. In a nutshell, someone added a MX record to the DNS database.


A little background: when you send a message to an Internet user (eg, fred@strhold.it), your messaging subsystem must know what machine among many is able to receive it. To gather this information, the Mail Transfer Agent asks the DNS server for the MX record related to the strhold.it domain; this record tells the MTA the IP number of the machine which the message should be delivered to. You can check this theory by making use of the nslookup Unix command; once at the '>' prompt, type the following:


set querytype=mx



When the prompt gets back, type the domain whose MX record you need to know:




Your DNS server should respond with the following lines of info:


strhold.it preference = 10, mail exchanger = ns2.albacom.net

strhold.it preference = 0, mail exchanger = drake.strhold.it

strhold.it nameserver = ns1.albacom.net

strhold.it nameserver = drake.strhold.it

ns2.albacom.net internet address =

drake.strhold.it internet address =

ns1.albacom.net internet address =


As you can see, there are two lines related to the strhold.it domain; the first (with precedence=0, which means high priority) shows that machine drake.strhold.it should be contacted first while delivering messages to that domain. Shouldn't it be available, the second box (ns2.albacom.net - with a low preference value, 10) should be contacted then.


Back to business now; in our scenario, we have a couple of choices when dealing with DNS:


1) ServerA is a DNS client so you have to ask your ISP manager to modify his/her DNS server files in order to add a new MX record; this should tell the 'Net that machine is able to receive messages for the domain2.it domain


2) ServerA is a DNS server so you have to manually modify the local DNS configuration file to add a new MX record


Since the configuration of a DNS server is outside the scope of this document, I'll assume you know how to do it (and you do know, don't you ? :-)


Once the DNS configuration is completed (please notice it could take some days for the new MX record to be sent across the 'Net), you can change the rather (in)famous /usr/lib/sendmail.cf configuration file; if you take a look at this file, you'll be frightened by the fact that some parts of it are literally incomprehensible but don't worry: we'll only have to change some human readable parts of it so it won't hopefully take long :-)


Nearly at the top of the file there should be a couple of macros, labeled DD and CW; please change them as follows:


DD domain1.it

Cw domain1.it domain2.it


Make also sure that the following lines are uncommented (i.e, without the leading # character) :


Kpop hash -om -a.POP /usr/internet/lib/sco_mail/domains

KpopDir hash -o /usr/internet/lib/sco_mail/domains


This tells sendmail that it can handle messages for both the @domain.it and the @domain2.it domains.


Hint: the sendmail.cf configuration file can be manually hacked if you want to activate some antiSPAM checks (eg, the check_rcpt rule). Usually these checks are disabled by default and they are not strictly required in this scenario; however nothing prevents you from activating them, given that you know how to wade through them, if you know what I mean :-)


At this point, you can also stop and restart sendmail:


cd /etc/rc2.d

./P86sendmail stop

./P86sendmail start


Just to make sure, check the /usr/adm/syslog for unusual error messages; to test your new configuration, try by manually send a message by making use of telnet to "emulate" a simple SMTP session to sendmail (as an example, see the session depicted below - user's input are in bold) :


telnet 25


Connected to server.domain2.it

Escape character is '^]'.

220 server.domain2.it ESMTP Sendmail 8.8.8/SCO5 ready at Wed, 2 Aug 2000 16:10:49 +0200 (CETDST)

helo test

250 server.domain2.it

mail from:<nobody@test.it>

250 <nobody@test.it>... Sender ok

rcpt to:<fred@domain2.it>

250 <fred@domain2.it>... Recipient ok


354 Enter mail, end with "." on a line by itself

This is a test message


250 QAA03322 Message accepted for delivery


221 server.domain2.it closing connection


By directly connecting to sendmail, we have just sent a mail message to fred@domain2.it (assuming that user fred has already been inserted through the Internet Manager); to see if the message has been received by the server, switch to the /usr/internet/ folder and manually inspect the fred file (it should contain the above typed message).


Just to double check the system configuration, you can repeat the above steps by sending a message to fred@domain1.it (change the above "rcpt to" line to reflect this change); assuming that "regular" (e.g, non virtual domain related) user fred has already been created via the Scoadmin Account Manager, the new message shouldn't get mixed with the previous (you can find it under /usr/spool/mail/fred).


So, am I good or what ? :-)


ServerB configuration


It's time now to configure the messaging subsystem on ServerB; our goal is to allow local PCs to send and receive emails to and from the 'Net. From this point of view, we have at least 2 choices:


1) local PCs are only able to send & receive messages while the PPP link is brought up by directly getting in touch with ServerA


2) local PCs are able to queue messages on the local server (ServerB); messages for users under the @domain2.it domain get handled by ServerB itself and stored under /usr/spool/mail (instead of being forwarded to ServerA), so that local users can read 'em. Messages for the outside world (Internet) get queued on ServerB to be eventually delivered to ServerA when the PPP connection is established.


Ths first solution takes into the account the fact that ServerA acts as a SMTP and POP3 server and that messages whose recipients are local have to be phisically transferred to it to be read; this is a waste of time and money, but it's the simplest solution. In fact, you only have to tell the mail composer (Outlook, Netscape ...) that the SMPT and POP3 server is accessible through the virtual domain IP address (, phisically hosted by ServerA. Messages will be held under the composer "outgoing" queue while operating "off-line", ready to be delivered when the link is up.


For a more effective solution, you have to consider choice #2; while the spooling phase isn't that difficult (you'll see it yourself in minutes), the tricky part is to configure ServerB to "fetch" @domain2.it messages gathered on ServerA and to store them under the ServerB spool area.


How can you do that ?


First, you have to tell ServerB sendmail not to deliver "outside" messages (ie, messages whose domain is different from @domain2.it); to do this, modify the sendmail command line switches in /etc/rc2.d/P86sendmail as follows, from


/bin/su root -c "/usr/lib/sendmail -bd -q1h" 2> /dev/null




/bin/su root -c "/usr/lib/sendmail -bd" 2> /dev/null


Notice how the -q1h flag has been removed from the original line.


Next, you have to tell sendmail that it'll be able to receive and deliver messages whose recipients are local (eg, from fred@domain2.it to wilma@domain2.it), without sending 'em to ServerA; to accomplish this, first check that ServerB is correctly referred and qualified in the /etc/hosts file and that its domain is actually present in the /etc/default/tcp file. As we previously did for ServerA, let's add some macros to the /usr/lib/sendmail.cf file as follows (modified macros are in bold) :











# level 5 config file format




# local info #



# Our local (e.g. LAN) domain name



# all the names this host is known by

Cw domain2.it serverb.domain2.it


Under the Options section, insert the following lines (again, in bold) :



# Options #



# strip message body to 7 bits on input?



# wait (in minutes) for alias file rebuild



# location of alias file



#log level



# Configurazione DNS




These options raise the sendmail default log level (OL10) and tell the server not to use any DNS capabilities while delivering messages; to actually send them, the server should check the /etc/service.switch file, discussed a bit later.


Last, under the Smart relay host section, insert the following line:




To complete this configuration, you have to create the /etc/service.switch file (with ownerships set to bin:bin and permissions set to 644) with the following content (exactly as typed below):


hosts file


Just to have a better "situation awareness", you can "split" warning and error messages from the system in order to avoid to check a huge /usr/adm/syslog file while searching for sendmail related messages; to do this, you have to manually change the /etc/syslog.conf file. An example of a current working configuration follows (change it according to your needs) :



*.info;*.debug;mail.none;news.none;daemon.none /usr/adm/syslog

daemon.* /usr/adm/daemon

mail.* /usr/adm/mail

local0.notice /var/adm/syslog


As you can see, we managed to have sendmail messages routed to the /usr/adm/mail file (if it doesn't exist, create it by using the touch(C) command); in order to activate the syslogd daemon with the new configuration, send it a HUP signal (eg, kill -HUP <syslogd_pid>).


Now you can restart your local sendmail daemon:


cd /etc/rc2.d

./P86sendmail stop

./P86sendmail start


Hint: you can devote one of the SCO Openserver 5 multiscreens to the monitoring of the /usr/adm/mail file (eg, tail -f /usr/adm/mail) so that by simply switching screens you'll be able to better check its behavior, thus making your life simpler :-)


It's now the time to configure the remote Windows PCs; depending on the mail composer being used, you have to tell it how to reach the server in order to send and receive messages. Namely, you'll have to change the following parameters:


POP3 Server : IP Address)

SMTP Server : IP Address)

Account name : <a virtual domain user>

Passoword : <his/her password>


To test the configuration, let's compose a message (on a Windows PC) for a local user (eg, root@domain2.it); as soon as the message reaches the server, something similar to the following should appear in the /usr/adm/mail file :


Aug 3 12:35:43 serverb sendmail[1292]: MAA01292: from=<fred@domain2.it>, size=1120, class=0, pri=31120, nrcpts=1, msgid=<004e01bffd35$b2356140$28e66ac0@domain2.it>, proto=SMTP, relay=[]


Aug 3 12:35:43 serverb sendmail[1293]: MAA01292: to=<root@domain2.it>, ctladdr=<fred@domain2.it> (203/50), delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Sent


The message has been correctly delivered (stat=Sent) and it's now available for user root to read under the /usr/spool/mail/root file (check it out just to be sure).


You can try now by sending a message to an outside user (eg, root@domain1.it); as usual, check the /usr/adm/mail file for something similar to this:


Aug 3 15:05:32 serverbsendmail[1502]: PAA01502: from=<fred@domain2.it>, size=1123, class=0, pri=31123, nrcpts=1, msgid=<001301bffd4a$a03ca740$28e66ac0@domain2.it>, proto=SMTP, relay=[]


Aug 3 15:05:32 serverb sendmail[1504]: PAA01502: to=<root@domain1.it>, ctladdr=<fred@domain2.it> (203/50), delay=00:00:00, xdelay=00:00:00, mailer=relay, relay= [], stat=Deferred: No route to host


The key here is the stat=Deferred: No route to host message; the messaging subsystem is telling you that this message couldn't get delivered since a route to get in touch with the relay server (mailer=relay, relay= [] ) couldn't be found (and this is correct since ServerB isn't currently connected to the 'Net).


But where's this message queued ?


It's under the /usr/spool/mqueue folder; the mailq command should depict something similar to the following, confirming that the message is actually queued:


Mail Queue (2 requests)

--Q-ID-- --Size-- -----Q-Time----- ------------Sender/Recipient------------

PAA01502 704 Thu Aug 3 15:05 <fred@domain2.it>

(Deferred: No route to host)



To deliver this message, ServerB has to connect to ServerA by making use of the above PPP link; before proceeding, double check that ServerB /etc/resolv.conf file points to the correct DNS server and that ServerA is pingable (eg, ping should work). To force sendmail to deliver queued messages, type the following while the PPP link is up:


/usr/lib/sendmail -qv


You should see something similar to the following:


Running PAA01489 (sequence 1 of 1)

<root@domain1.it>... Connecting to via relay...

220 servera.domain1.it ESMTP Sendmail 8.8.8/SCO5 ready at Thu, 3 Aug 2000 15:12:03 +0200 (CETDST)

>>> EHLO serverb.domain2.it

250-servera.domain1.it Hello serverb.domain2.it [], pleased to meet you







250 HELP

>>> MAIL From:<fred@domain2.it> SIZE=805

250 <fred@domain2.it>... Sender ok

>>> RCPT To:<root@domain1.it>

250 <root@domain1.it>... Recipient ok

>>> DATA

354 Enter mail, end with "." on a line by itself

>>> .

250 PAA00357 Message accepted for delivery

<root@domain1.it>... Sent (PAA00357 Message accepted for delivery)

Closing connection to

>>> QUIT

221 servera.domain1.it closing connection


The above output traces the SMTP session that ServerB performs to deliver queued messages; a quick check under /usr/spool/mail/root on ServerA should confirm that the message has been correctly delivered.


The final part of this document aims at describing a possible method to retrieve remotely queued messages (stored under the ServerA filesystem) from ServerB; to do this, we'll use the public domain fetchmail package, available on the Skunkware98/2000 CD-ROM. This piece of software acts as a POP3 client (and more) and allows a Unix user to grab messages from a remote POP3 server; plese remember that the package installs itself under the /usr/local/bin folder so it's likely that you'll have to change your PATH environment variable accordingly.


To perform a first test, we'll suppose ServerA received a message for user fred@domain2.it; given the above configuration, it should have been stored under the /usr/internet/ folder. Once the PPP connection from ServerB is up, the following command (execute on ServerB) will be able to retrieve that message:


/usr/local/bin/fetchmail -v -p pop3 -u fred


After prompting for fred's password, fetchmail will initiate a SMTP connection to ServerA (you can see the various phases depicted on the screen, thanks to the '-v' option); at the end of the connection, fetchmail will deliver the message to the local messaging subsystem so user fred can retrieve it from its local mailbox (/usr/local/spool/fred).


If everything works as expected, we have to automate this procedure; a possibile solution could use a cron(C) script which, when the connection is brought up, will force fetchmail to retrieve remote messages. To do this, you can create a $HOME/.fetchmailrc file with the following contents:


poll protocol pop3 username fred password <password_for_fred>


Be careful here: you have to use the same password you entered when you added fred through ServerA Internet Manager; also, check that the .fetchmailrc file belongs to fred (chown fred:group .fetchmailrc).


Now, create an executable shell script file (eg, /usr/local/bin/getmail.sh) with the following contents and insert it into fred's cron file:









# Another instance running ?



test -f $LOCKFILE && exit



# No; are we connected ?



ping -c 2 $SERVERA 1>/dev/null 2>&1

test $? -ne 0 && exit



# Good; create the lock file and run fetchmail




$FETCHMAIL -s 1>/dev/null 2>&1

rm $LOCKFILE 1>/dev/null 2>&1


exit 0


Please notice that the above file is just a simple yet effective script; you can change it to suit your needs. Also, the $LOCKFILE shouldn't really be needed since fetchmail itself is able to detect if there's another fetchmail instance running.


fred's crontab file could be arranged as follows:


0,5,10,15,20,25,30,35,40,45,50,55 * * * * /usr/local/bin/getmail.sh 1>/dev/null 2>&1


On a 5 minutes basis, if the connection is detected as "up", the script will try to retrieve remote messages from ServerA whose recipient is fred@domain2.it; please notice that if there aren't any messages to retrieve, fetchmail will not return any error (it'll simply complete its executing without complaining - and this is expected).


Notice also that if ServerB connects to the 'Net by using a Dynamic Outgoing PPP Connection, the script will cause the link to be brought up (due to the use of the ping command); you can workaround that by simply replacing ping -c 2 $SERVERA 1>/dev/null 2>&1 with ifconfig -a ppp0 1>/dev/null 2>&1.


If the above script works (and it should), modify the cron file of every user allowed to receive message from the 'Net and you'll be fine.


Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Handling mail messages in a virtual domain environment underSCO OS 5

Inexpensive and informative Apple related e-books:

Are Your Bits Flipped?

Take Control of OS X Server

Take Control of Numbers

Take Control of Preview

Photos: A Take Control Crash Course

More Articles by © Roberto Zini

Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

It all sounds good from the pulpit,but come Monday morning all the sinners are back to business as usual writing crappy code. (Tony Lawrence)

Linux posts

Troubleshooting posts

This post tagged:



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode