In the days before DNS, uucp names were used in E-mail addresses. Addresses were shown as "bang paths" showing the series of hosts you had to traverse to reach a particular destination: e.g.
uunet!apple!vox!stevemeans "send to computer uunet, who will send to computer apple, who will send to computer vox, who will send to the user named steve"
Modern systems use domain names instead, and the mail software, if configured properly, will take care of routing the message between systems. If a system doesn't have a domain name you can use the uucp name plus the fake domain ".uucp" - for example "vox.uucp" - but this address can't be used to receive mail from the Internet. It is much better to get a proper domain name allocated. Note that the domain name need not bear any resemblence to the uucp name you choose.
You can inspect the queues using uustat. Each message is identified with a job ID.
uustat -a <<Show all queued messages uustat -s uucpname <<Show messages queued for the given system uustat -k jobid <<Delete (kill) the given job
useradd -d /var/spool/uucppublic -s /usr/sbin/uucico Uvoxor manually add an entry to /etc/passwd:
Uvox::547:100:Vox UUCP:/var/spool/uucppublic:/usr/sbin/uucicowhere '547' is the first unused UID on your system. The account's home directory is /var/spool/uucppublic. (Slackware 3.1: use /usr/lib/uucp/uucico instead of /usr/sbin/uucico)
The login name (Uvox in this case) doesn't need to bear any resemblence to the uucp name, but it is conventional to use a capital 'U' plus the uucp name. By including a capital letter, this login account can't receive E-mail (i.e. nobody can send mail to Uvox@your.machine). You don't want this to happen because nobody would ever download the mail addressed to Uvox.
Of course, if machine A only ever calls machine B, then only machine B needs to have a login account.
/etc/uucp/ --> /var/lib/uucp/taylor_config/ /etc/uucp/oldconfig/ --> /var/lib/uucp/hdb_config/ /var/log/uucp/Log --> /var/spool/uucp/.Log/uucico/* /var/log/uucp/Debug --> /var/spool/uucp/.Admin/audit.local /var/log/uucp/Stats --> /var/spool/uucp/.Admin/xferstats uuchk --> /usr/lib/uucp/uuchk uucico --> /usr/lib/uucp/uucico
HDB configuration files are stored in the directory /etc/uucp/oldconfig/ and consist of the following files:
chown uucp.uucp /var/lib/uucp/ chmod 770 /var/lib/uucp/You can check your configuration files with the following command:
uuchk | lesswhich will report the location of any syntax errors if there are any, or give a verbose description of your system configuration if not.
You can also get a list of all your neighbours by typing 'uuname'.
sparky Any ACU 38400 7531234 ogin:--ogin: Utiger word: 01dcr0Ck vox NeverHere, we have two neighbours. "sparky" is the uucp name of a system we dial out to, and the rest of the line gives the parameters we need to call. "vox" is also a neighbour, but we never call them - so presumably, they must call us.
The fields of the System file are as follows:
sparky Any ACU 38400 7531234 ogin:--ogin: Utiger word: 01dcr0Ck sparky Any ACU 38400 7531234 ogin:--ogin: Utiger word: 01dcr0Ck sparky Any ACU 38400 2264322 ogin:--ogin: Utiger word: 01dcr0CkThis means that uucico will try the number 7531234, if it fails try 7531234 again, and then try 2264322. So you have a way of automatically trying an alternative number if the main number is unavailable.
In the Permissions file, you can also set the uucp name by which your system is known to each neighbour. If you don't specify one, your host name is used - e.g. if your machine is darkstar.frop.org then your uucp name is 'darkstar', so this is what your neighbour has to have in their Systems file. But by putting MYNAME=xxx you can override this individually for each of your neighbours.
VALIDATE=ccc LOGNAME=Uccc MYNAME=tiger REQUEST=yes \ COMMANDS=/usr/bin/rmailYou can split entries in the Permissions file by putting a '\' at the end of each line except the last. The above example says that uucp neighbour 'ccc' must log in using account Uccc, that they know our uucp name as 'tiger', that the remote site may request file transfers to and from the /var/spool/uucppublic directory, and that they may execute /usr/bin/rmail on our machine.
If you dial out to this machine, you will need an entry like this:
MACHINE=ccc MYNAME=tiger REQUEST=yes COMMANDS=/usr/bin/rmailIf you don't put an entry in your Permissions file for a machine, anybody will be able to collect that machine's mail. You will see this if you check your config files with uuchk.
ACU cua0 - 38400 usr ACU cua1 - 38400 usr ACU cua2 - 38400 telebit TCP uucp - -Entries in the Systems file which contain "ACU 38400" will match the first three lines. When dialling out, uucico will use the first one which is available. Lines cua0 and cua1 use the "usr" entry in the Dialers file, and line cua2 uses the "telebit" entry. The final "TCP" line is used if you want to run uucp over TCP/IP, which we will see later.
usr =W-, "" ATM0DT\T CONNECT telebit =W-, "" \rAT OK-AT-OK ATS11=100DT\T CONNECTThe first field is the name of the Dialer, as referred to in the Dialers file. The second field gives character translation: in this case we translate '=' in the phone number to 'W' and '-' to ','. The purpose of this is so that your phone numbers can contain '-' where you need a pause in the dialing sequence, and '=' where you want to wait for a new dial tone; these characters then get translated to the appropriate characters for your modem, which are normally ',' and 'W'. e.g.
Phone number in Systems file: 9=123-4567 Phone number sent to modem: 9W123,4567The final field is the chat script for dialing to the modem, and this is what you will have to customise for your type of modem. It takes the form of an expect send expect send... sequence. Where you put '\T' in a send string, it is substituted with the phone number from the Systems file. Send strings automatically have a [return] character appended, unless you put '\c' at the end of the string.
sendmail is a complex program, and its configuration file /etc/sendmail.cf is extremely cryptic. But fortunately there is a set of configuration modules available, which you can string together using the 'm4' macro processing language to make a customised sendmail.cf with very little effort.
You can find a full description of the m4 configuration options in file /usr/lib/sendmail-cf/README, but here I will give you some configurations you can use immediately. In each case you must create the file in /usr/lib/sendmail-cf/cf, and give it a name ending ".mc". This is then built into a config file ending ".cf" in /usr/lib/sendmail-cf/cf/obj, which you will later copy to /etc/sendmail.cf. (For Slackware 3.1: each time you see /usr/lib/sendmail-cf/ replace it with /usr/src/sendmail/cf/)
Here is a sample .mc file which will route all outgoing mail to one uucp neighbour, presumably your ISP. In this case I am assuming its uucp name is "sparky".
dnl A config file which forwards all non-local mail to our smart host VERSIONID(`linux uucp to smarthost') OSTYPE(linux) define(`ConfDEF_USER_ID',``8:12'') define(`SMART_HOST',`uucp-dom:sparky') FEATURE(redirect) FEATURE(use_cw_file) FEATURE(nocanonify) FEATURE(local_procmail) MAILER(local) MAILER(procmail) MAILER(smtp) MAILER(uucp)If you want to add comments in this file, put 'dnl' in front of them (this is the m4 command to 'delete to end of line') so that they don't get passed through to the final sendmail.cf file.
The main elements of this file are:
So you need to create this file in the correct directory, then compile it, like this.
cd /usr/lib/sendmail-cf/cf (Red Hat 4.1) or cd /usr/src/sendmail/cf/cf (Slackware 3.1) joe myconfig.mc pmake myconfig.cfIf the 'pmake myconfig.cf' line doesn't work for any reason, use this instead:
m4 ../m4/cf.m4 myconfig.mc > obj/myconfig.cfNote that you must have the 'm4' package installed for this to work. The resulting .cf file is stored in /usr/lib/sendmail-cf/cf/obj/myconfig.cf
Finally, you must create a file '/etc/sendmail.cw'. This file contains all the host names by which this computer is known, in other words, all domains which are to be considered 'local' to this machine. You don't have to list the machine's full name (as shown if you type 'hostname -f') because it knows that already. However if there are alternative names by which your machine is known to the outside world, you must list them in /etc/sendmail.cw. Even if there are no extra names, you need to create an empty file with this name.
The most common use of /etc/sendmail.cw is if your machine is called (let's say) "mailhost.frop.org" but you also wish to receive mail for the domain "frop.org". In other words, the address "email@example.com" is really the same as "firstname.lastname@example.org". In this case, the machine knows that mailhost.frop.org is its own name, but you need to add frop.org to /etc/sendmail.cw - otherwise, it would think that mail to this address is external, and try to forward it to another machine.
If you are going to use this trick, which helps keep E-mail addresses short and hides the internal setup of your domain, you need to arrange that mail to email@example.com is actually delivered to machine mailhost.frop.org. This is achieved by putting an MX record for frop.org, pointing to mailhost.frop.org, in the DNS. This can be done by whoever runs the DNS for your domain.
sendmail -v -C/usr/lib/sendmail-cf/cf/obj/myconfig.cf address Now type some text .This will deliver the message to the given address, and display its progress on the screen. If everything seems OK, you can then install your new .cf file as /etc/sendmail.cf, remembering to keep the old one as a backup!
cd /etc cp sendmail.cf sendmail.cf.orig cp /usr/lib/sendmail-cf/cf/obj/myconfig.cf sendmail.cfFinally, you will need to locate the sendmail daemon, and send it a 'hup' signal (-1) to get it to reread its configuration files.
ps -axw | grep sendmail 94 ? S 0:00 sendmail: accepting connections on port 25 kill -1 94
kill 94 # or whatever pid sendmail is /usr/sbin/sendmail -bd -q1hAlternatively you can fix the problem by editing /etc/rc.d/init.d/sendmail.init and changing the line which starts up the sendmail daemon, so that it includes the full pathname (/usr/sbin/sendmail):
echo -n "Starting sendmail: " daemon /usr/sbin/sendmail -bd -q1h
uustat -s sparky(assuming your smarthost's uucp name is "sparky"). You should also check that mail is delivered to local accounts on your system, for addresses like "firstname.lastname@example.org". If your machine is known by more than one name, try them all.
uucico -S uucpname -x 3The '-x 3' enables debugging at level 3. The uucico program will turn itself into a daemon and return you to the command prompt, but will run in the background. You can see its debugging messages like this:
tail -f /var/log/uucp/Debugsince the 'tail -f' command shows you the last 10 lines of a file, plus any new lines as they are added. Hit Ctrl-C to get out of this.
Even if you place a call without debugging enabled, you will see entries created in /var/log/uucp/Log summarising each call in or out, and /var/log/uucp/Stats which shows how fast each file transfer was.
Typically, you would like your incoming mail processed quickly. One way to achieve this is by writing a script to dial out:
#!/bin/sh uucico -D -S sparky -x 3 sleep 10 sendmail -qIf you save this file as (for example) /usr/local/sbin/poll, and make it executable by "chmod +x /usr/local/sbin/poll", then typing "poll" will execute the series of commands given. The -D flag to uucico prevents it from going into the background, so the script will wait until uucico finishes, then wait another 10 seconds, then make sendmail process any queued mail.
crontab -u uucp -e (Red Hat 4.1) crontab -e uucp (Slackware 3.1)This will put you into vi. If you want to use a sensible editor, create the crontab using joe and then install it from that file:
crontab -u uucp -l >tempfile joe tempfile crontab -u uucp tempfileLines in crontab consist of the following fields:
30 3,9,12,15 * * 1-5 /usr/sbin/uucico -s sparkyIf you have written a poll script you can run that instead.
Red Hat has a more powerful cron daemon which can also read in entries from a global file /etc/crontab. This is in the same format as above, but has an extra field on each line, giving the username to run the process as. You may find this an easier place to put your crontab entries.
30 3,9,12,15 * * 1-5 uucp /usr/sbin/uucico -s sparky
VERSIONID(`linux uucp with mailertable') OSTYPE(linux) define(`ConfDEF_USER_ID',``8:12'') define(`SMART_HOST',`uucp-dom:sparky') define(`ConfSMTP_LOGIN_MSG',`$j Sendmail $b') FEATURE(redirect) FEATURE(use_cw_file) FEATURE(nocanonify) FEATURE(local_procmail) FEATURE(mailertable) MAILER(local) MAILER(procmail) MAILER(smtp) MAILER(uucp)(The 'ConfSMTP_LOGIN_MSG' line tells sendmail NOT to give its version number when someone connects to your SMTP server. This prevents giving away some information which could be of interest to a hacker, especially if a security hole is discovered in the version of sendmail which you are running)
Next you need to create /etc/mailertable. Each line consists of:
In this case, /etc/mailertable would look like this:
admin.frop.org smtp:admin.frop.org accounts.frop.org smtp:accounts.frop.org .frop.org error:error Unknown host finance.gov.gh uucp-dom:minfThe ".frop.org" line catches all addresses ending in .frop.org apart from the specific ones listed, and the "error" delivery agent bounces the message back to the sender, with the message you give on the line. We don't list the smart host here - this is still in the .mc configuration file as before.
Before sendmail can use this file, you must compile it into a database format which is efficient to search:
makemap hash /etc/mailertable < /etc/mailertableIf this doesn't work (and unfortunately 'makemap' has some problems in Slackware 3.1) you can replace 'hash' with 'btree' or 'dbm' which are two different database formats. You will also need to change the FEATURE(mailertable) line in your .mc file too, and recompile it:
FEATURE(mailertable,`btree -o /etc/mailertable')
uucp remote\!/var/spool/uucppublic/filename localfilenameTo transfer a file from your machine to the remote:
uucp localfilename remote\!/var/spool/uucppublic/filenameNote the syntax uucpname\!filename; the backslash is needed to stop the shell treating the exclamation mark specially. Now that most E-mail packages are able to send binary attachments using MIME, this facility of uucp is rarely used.
It is possible to run a uucp transfer over a TCP/IP connection. This is useful if your site has intermittent IP connectivity (e.g. via a dial-up PPP link) and you want to transfer uucp mail at the same time as using the Internet. It is also useful if you have a dial-up IP access point nearby, but your uucp mail host is far away, since you can save the cost of a long-distance phone call.
uucp over TCP/IP conventionally uses TCP port 540. To configure your machine to making outgoing connections over TCP/IP, you need to add a line to the Devices file:
TCP uucp - -There should already be a line in /etc/services which maps "uucp" to port 540/tcp. Then you add an entry into your Systems file which uses "TCP" instead of "ACU" for the dialer, a "-" for the speed, and the host name instead of the phone number:
sparky Any TCP - relay.xyz.net ogin:--ogin: Utiger word: 01dcr0Ck sparky Any ACU 38400 7531234 ogin:--ogin: Utiger word: 01dcr0CkIn this case, if you run uucico to connect to system 'sparky', uucico will first try to establish a TCP connection to host "relay.xyz.net" (which is that machine's full hostname on the Internet). If it fails, it will then try to place a direct phonecall instead.
If you want to accept incoming connections over TCP/IP, you have to add the remote machine's username and password into a separate file, /etc/uucp/passwd
Uvox:whoopee7This is because uucico, when running as a TCP/IP daemon, generates its own username and password prompt, and doesn't check the /etc/passwd file. Since the passwords in the above file are unencrypted, it is very important to make sure it not readable by anyone apart from 'uucp'.
You also need to uncomment the following line in /etc/inetd.conf:
uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/sbin/uucico -land send a HUP signal to inetd to make it reread this file:
killall -1 inetd
Here is an example configuration:
# This is our uucp name nodename tiger
# A system we connect to using uucp over TCP/IP system ucb call-login Utiger call-password wibbly time any port type tcp address uucp.ucb.edu.bz # We dial out to this system, which knows us as 'ccc' system sparky myname ccc call-login Utiger call-password 01dcr0Ck time any port usrobotics phone 12345 # The far end supports large packet sizes so let's use them # (greatly improves performance for calls routed via satellite) protocol-parameter g retries 10 protocol-parameter g packet-size 1024 # This system dials into us system vox called-login Uvox
port usrobotics type modem device /dev/cua0 dialer hayes speed 38400
dialer hayes chat "" ATZ\r\d\c OK ATDT\T CONNECT chat-fail BUSY chat-fail NO\sCARRIER
Using fetchmail is very easy. Create a file .fetchmailrc in your home directory:
poll <server> proto <protocol> user <remote-username> is <local-username>You must make this file unreadable (chmod 600 .fetchmailrc). For example:
poll btlmail.btl.net proto pop3 user corocom is janThen when you type 'fetchmail', mail for user 'corocom' on server 'btlmail.btl.net' will be collected using pop3 and delivered to user 'jan' on the local machine.
You can include your password in this file too, to completely automate the process - but beware the security implications, since the root user is able to read everybody's .fetchmailrc file.
You can put entries for multiple POP3 accounts in the same configuration file, you can choose to keep your mail on the remote server, and you can also run fetchmail as a daemon (so it checks for new mail periodically). For more information see 'man fetchmail'.