Actually you must have the TCP/IP working first, and may wish to leave the "difficult" sendmail later. A much better idea is to realise that yesterday you had no TCP/IP, no sendmail, and no regular flow of incoming mail to lose. Experimenting NOW will get it stable for when you can't afford to be without it.
Sendmail is all about receiving and transmitting email between machines. It delivers your mail into /usr/spool/mail/$LOGNAME, where you can read it.
You compose an EMAIL using pine or elm. It calls sendmail to send it. Sendmail accepts the message and either delevers it immediately or adds it to the queue to be processed.
To send a message, sendmail (usually) looks up the name of the destination host using the nameserver. The nameserver (after asking another nameserver!) replies with the MX record for that host, ie a 'top-two' list of IP addresses, of the destination host and it's backup mail exchanger. Sendmail than tries the hosts in that order, to find the most direct path, or the nearest intermediary. Sendmail may decide to send the message to the smart-path relay-host, ie your ISP's mailhost, and let it do the work.
Sendmail calls that host in TCP/IP port 25, and expects to talk SMTP.
If you ever get stuck and cannot SEND mail, you can do this manually with telnet. Using cut and paste saves some editing mistakes.
gps@trix:~/raven/soon$ telnet localhost smtp Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220-trix.dircon.co.uk Sendmail 8.6.12/8.6.12 ready at Mon, 4 Mar 1996 00:18:21 GMT 220 ESMTP spoken here --> HELO 250 trix.dircon.co.uk Hello gps@localhost [127.0.0.1], pleased to meet you --> VRFY john 250 John F Gold <john@trix.dircon.co.uk> --> MAIL FROM:<gps@trix.dicon.co.uk> 250 <gps@trix.dicon.co.uk>... Sender ok --> RCPT TO:john 250 john... Recipient ok --> DATA 354 Enter mail, end with "." on a line by itself --> To: john | From: Graham | Subject: Junk Mail | X-extra: Extra lines in the header for those who want them | don't you just love it? | G --> . 250 CAA00694 Message accepted for delivery --> QUIT 221 trix.dircon.co.uk closing connection Connection closed by foreign host. gps@trix:~/raven/soon$
When your ISP or another internet user (directly) SENDS you an email, they connect to TCP/IP port 25 on your host, and expect it to talk SMTP. Sendmail is the program that implements SMTP, and handles incomong email.
Sendmail also does various tricks like aliases, lists of users and delivering email to your scripts, for automatic processing. It also talks to machines that use different systems (uucp transports or different message formats).
Get dial_up Internet working (done). Select Sendmail (not Smail) from the N disks. Ensure that your /etc/HOSTNAME is the proper email name, and that /etc/hosts is correct, with the full hostname first on the line after the actual address. Create your user. Check that your names get resolved (/etc/resolv.conf), so that ping www.InfoMagic.com works (without the address in /etc/hosts, it must have come from the nameserver).
Get a prepared /etc/sendmail.cf file by running the slackware command:
cd /var/adm/setup ./setup.sendmailSelect option 1, ie the one that uses a nameserver. This tell sendmail to use MX (mail exchange) records.
You have just run a program that installs a new /etc/sendmail.cf for you.
Restart sendmail and send a few messages. Start Internet (dip_in) and test that you can send and receive to/from your ISP.
tail -f /var/adm/messages &; # start this once killall sendmail # ensure not using old .cf file! ps -xa # none running sendmail -bd -q 15m # process queue every 15 minutes telnet localhost smtp # what your machine looks like HELO QUIT echo help | sendmail user3 # yourself mailq # view list in queue sendmail -q # process queue now pine # read mail in other window echo help | sendmail user # yourself echo help | sendmail user@hostname.domain # yourself dip_in # connect to Internet ping isp-mailhost.domain # your ISP's mailhst # the long address is a special format that ROUTES # that email to yourself via your service provider # the 'quotes' make < and > meaningless to the shell echo help | sendmail '<isp-mailhost.domain:user@hostname.domain>' # watch /var/adm/messages # press CTRL-C to interrupt tail -f filename ping news-digests.mit.edu # we're both online echo help | sendmail majordomo@news-digests.mit.edu mailq sendmail -q # send it NOW mailq # DONE #Because you selected the dns sendmail.cf, and have not defined any SMART_PATH, , sendmail will attempt to call news-digests.mit.edu DIRECTLY.
Sendmail uses DNS to get the most direct route. If the modem is DOWN, your dns link will be down. Sendmail wont be happy. It may decide that it can't queue this for later, and bounce it back at you!
Even worse, sendmail wants to use DNS to confirm its own address. Local traffic wont get send until the modem came back online!
I fixed this for me, by selecting nodns (when generating the sendmail.mc), and by specifying a default route. Now all my email goes out via felix, but incoming mail can be sent direct.
If you remain on-line, mit.edu will reply directly to you. If you go off-line, your reply will be sent to your 'backup' mailhost. IE your ISP's mailhost, which will store it for 6 weeks or whatever. You may need to run a command to tell your isp-mailhost you want to download now. I use finger @mailhost, your ISP will have told you what to do. If you have POP instead of plain SMTP, your story may be different.
Who's afraid of the big bad wolf? Sendmail.cf is a monster, but most of it is technical detail from included libraries. Go back to the source: sendmail.cf is generated from: sendmail.mc
With a bit of simmering, it boils down to a single file /usr/src/sendmail/cf/MYFILE.mc, something like:
divert(-1) include(`../m4/cf.m4') VERSIONID(`gps.mc - get this thing working') Cwlocalhost trix.trix.org trix.dircon.co.uk define(`SMART_HOST', mailhost.dircon.co.uk ) OSTYPE(linux) FEATURE(nouucp) MAILER(local) MAILER(smtp) FEATURE(nodns)
Having said that, my configuration is NOT yet working as I want it, but the problem is in those lines somewhere. (It works, but only with /etc/HOSTNAME set to the proper name. Maybe its the HOSTNAME=`cat /etc/HOSTNAME` in /etc/profile.
Other than that, I don't see how it gets the DOMAINNAME DDsomething does not work. I'd ask someone but I've got to get news working first!
You want to generate an /etc/sendmail.cf from the above .mc file. Here is how you do it, in a way that is relocatable, and keeps a summary file for SCCS.
Sendmail is an old program, and it has several distributions, each with varying configurations. The sendmail.cf itself is a horrendous configuration file, and over the years people have developed MACROS to make it easier to setup. Different people use different MACROS, eg sendmail+IDA or V8.
Your distribution may vary from this (eg Slackware relocates some of the docs to /usr/doc/sendmail), but chances are the following will apply to you.
Remember that mc-3.1 can read groff formatted documents using the F3 key, without it you would need groff -Tascii -me op.me
DOCS /usr/src/sendmail/cf/README - text lists many macros and names /usr/src/sendmail/cf/README.linux - the two Slackware .mc files /usr/src/sendmail/README.linux - the two Slackware .mc (different) /usr/doc/sendmail/op/op.me - operators manual /usr/doc/sendmail/FAQ - --> /usr/doc/sendmail/READ_ME - main README - lists most other docs DEMOS /usr/src/sendmail/cf/cf/tcpproto.mc MAN PAGES and apps mailaddr(7) procmail sendmail deliver (Write your list here)
Create a directory, eg /home/gps/cfg/sendmail where all your files will go. You mught also put some of these scripts into /usr/local/bin or $HOME/bin, (PATH=$PATH:$HOME/bin). You don't need any of these, but they help.
X11 will paste the highlighted selection to where the mouse is when you click MIDDLE.
gpm does a similar job on text consoles. pico the editor from the PINE package is very simple. In vi go into Insert mode after making sure that auto-indent is off : set noai
If you are using xterm or a mouse-aware app, SHIFT+MOUSE ususally works.
These scripts are really pointless, if you are in the right directory (.../src/sendmail/cf/.), simply say m4 MYFILE.mc However, it's nice to have location independence, comments removed and the terse result placed under SCCS or somnething. These scripts need chmod 755 script and placing in a dir on the PATH.
#!/bin/sh # here blank lines includes TAB or SP # elsewhere they indicate non-blank lines! grep -v '^[ ]*$' # eof # no_blank_lines
#!/bin/sh # [<TAB><SP>] - can be hard to see and read # provides a very simplistic definition of 'comment' # works with terminfo source and lots else # '#' must be at the start of a line, or preceded by BLANK(s) # messes up line numbers # no protection of # 'eg # in quotes' grep -v '#' "$@" | sed 's,[ ][ ]*#.*,,' # eof # no_comments #
#!/bin/sh [ $# = 1 ] || exit 1 if expr match "$1" / >/dev/null then echo "$1" # already absolute else echo `pwd`/"$1" fi # eof # full_path_name #
#!/bin/sh [ $# = 1 ] || exit 1 # could be: mv <$1 > /etc/sendmail.cf # warning do not use on DOS fs as ${file}.no_com may kill $file # warning overwrites /etc/sendmail.cf ! file=`full_path_name $1` cd /usr/src/sendmail/cf # normal location of file no_comments $file \ | no_blank_lines \ | tee $file.no_com \ | m4 \ > /etc/sendmail.ce # some pople use: mv /tmp/sendmail.cf /etc/sendmail.cf # incase of fail half way through killall sendmail # still using old .cf file ? mailq # view queue before starting sendmail -bd -q 15m
#!/bin/sh # automates the obvious, but DOES tell you the ORIGINAL address used # ie before ELM, PINE or SENDMAIL got at it addr="${1:-user@host.domain}" # default or override sendmail -t <<-EOT-1 # eof also stops a HERE document zone To: $addr Subject: test mail addressed to $addr This is a test mail to see what happens when mail is sent to the address: $addr using sendmail -t following dot may end the email . or not! EOT-1 echo "$0: sendmail $addr returned exit code $?" # eof # send_11 #
Sendmail does NOT like trailing spaces on lines. To see where they are in vi use the :set list command (:set nolist)
The leading #!//usr/local/sbin/mc_to_cf, makes this configuration file an executable program. If you don't like it, don't do it. I suggest that you don't chmod 755 it, as you might run it by accident in a browser, however, if it is well configured sh myfile.mc will work, as /bin/sh also follows the standard:
#!/abs_path_name [single option] file_name_gets_added_here. #
#!/usr/local/sbin/mc_to_cf # the above line makes this an executable script # with chmod 755 of course # gets pre-processed by me then m4 to the .cf file # gets INSTALLED into /etc/sendmail.cf # gets /usr/src/sendmail/*/MACROS/* added to it # including some horrific LEX handlers # HINT: put yours in the hack directory, or ... # HINT: read the macro definitions, many are 1:1 dumb # divert(-1) is an m4 thing divert(-1) # include the sendmail V8 MACRO framework include(`../m4/cf.m4') # tell the reader where this came from # which host it is intended for VERSIONID(`my_file.mc - ravens config circa Feb 96 - untested ') # list of hostnames that sendmail will accept email for Cwlocalhost trix.trix.org trix.dircon.co.uk # declare gateway or ISP machine define(`SMART_HOST', mailhost.dircon.co.uk ) # Linux file layout FSSTND OSTYPE(linux) # 'uucp' is an overloaded term, often running over smtp! # 'uucp' predates TCP/IP (it is an rs232 modem dialup scheme) FEATURE(nouucp) # included anyway! MAILER(local) # use big cloud networking, smtp protocol MAILER(smtp) # dns seems like a good idea - BUT - FEATURE(nodns)
Compare this mail-conf-script with those in /usr/src/sendmail/cf. They are all much the same, with hardware names to make Linux users feel at home, or 'hp' users get the 'correct' pathnames. If you plough through them you may find interesting cases that handle BITNET to Internet to UUCP gateways, or categories of gateway types, and hosts within a gateway's 'domain' (an ambiguous word).
What are those configurations in /usr/src/sendmail/cf/? What shape networks are they handling?
Check this file rgularly, sendmail sends error rports here. Eg if someone send mail to wrong_name@host.domain, they get a fail message, postmaster gets a copy of the original.
Remember that email gateways are different from TCP/IP gateways, though one machine might do both jobs. TCP/IP gateways, are really routers that direct IP packet traffic. EMAIL gateways do much the same, but with email messages, not TCP/IP packets.
The email gateway for a domain, handles incoming traffic bound for all local machines.
If the sender reaches the destination machine (wth TCP/IP:SMTP), the gateway is not used. Email within the domain may be direct, or through the gateway. The gateway expects to receive email addressed to a LIST of hosts, or domains.
A gateway can have a simple name, and route mail to machines in other LAN's, eg user@company.com gets routed to <user@host.lan.building.town,country.company.com>. Then that might be send to a gateway towards that domain. ie CInorder to reach user@host.lan_90.bodmin.uk.company.com, the email gets sent via user@pigeon.demon.co.uk
That routing could be a chain-list of addresses, or it could simply be the nearest gateway to user that would know the proper address.
If you only have a leaf PC connected to an Internet provider, you are a leaf attached to an intelligent gateway - your ISP's mailhost.
A LAN of PC's can have peep-to-peer email. The sender has to know which host a user is on (From: user@crow.domain), or the network can be designed so that the sender replies to: user@domain, in which case the email is sent to the server/gateway, which looks up user in a databse to find that the next hop is to (or via) crow.domain.
If the destination address is outside of the LAN, it will probably have to go through a gateway (the gateway), so if the PC can't reach the host directly it simply sends it to the gateway, whhich then has the responsibility of routing it.
If you have a single PC connected to the Internet via dial_up, all your TCP/IP packets go through your ISP's LAN (possibly 100 M ethernet not 10 M ethernet).
Your ISP will have an internal LAN that connects the various TCP/IP routers, name servers, terminal servers, and service hosts (mailhost, ftp.hosts, www.hosts). It is likely that your ISP have several LAN's all threaded together.
If your packet traffic goes worldwide (as it does), there will be a spiders web of interconnections between ISP providers, LANS at the remote ISP and LANS at the far end.
Each connection requires that the packet be completely read in (eg 1.5K bytes) by the router, and then re-transmitted on the other side of the router (from wire to router to wire). Transmission on a wire shared by several hosts (eg ethernet not point-to-point), may require a wait for free air-time to become available. This is a tiny delay, but can lead to backlogs, where several packets are waiting in a queue to be transmitted next. The ISP side of your modem is a primary example of this, with ftp packets coming from several directions waiting to be transmitted at V34 speeds.
When all of the UK wants to access all of the US, the air-time providers like having a little capacity overload - before they have to swich on extra circuits that they rent from their providers. Statistically backlogs are few and far between - but how much so?
If your ISP has a quality machine, it will be much faster to transfer email between it and you (data throughput), though there will be a total delay of delivery that takes twice as long. If your host completes sooner, it releases memory sooner, reducing swap, makeing your server faster.
If the remote host is overdriven, data throughput may be slow or even break. It makes more sense to let your ISP have that worry. It may even tolerate remote ISP's going offline for a while.
If your smart host has a quality configuration, it will be able to bridge with other TYPES of networks, and know of routes through gateways (or their smart_hosts). That saves you a lot of hassle, you just have to get the compuserve address right, or the JANET address correct, your ISP does the work.
This is great at 3am in 1996, but at 11:30 in 1998 the picture may be totally different. If your mailhost.isp.com is getting old, overdriven, etc you may not be happy with the service.
Similarly, what happens tomorrow and all next week, when the ISP's mailhost goes AWOL? Presumably, they struggle to get basic connectivity back, and dns lookups are still fast and relatively few.
At that time, you would stop using the smar-thost, and start to go directly to the remote ISP's mailhost, or the end host if it is on-line.
if you are running an interactive multi-media discussion with a friend, simultaneously logged-on. One stop EMAIL is faster than 2 or even 3, even it it runs at a slower throughput.
in addition, you know your emaail went through the ISP's packet routers, not through the email gateways (and hence onto disk, along with log-files). You trust your ISP, it's unlikely that they will 'tap-into' your lines, but who works for them? (Ususally these people are too busy, too well paid, and email is boring). BUT ...
EG Your ISP may well collect traffic statistics (From_site, To_site, When, N_bytes) that are retained and archived. How would you feel to find out that a debt collection agency had its email summary log, sold on a weekly basis? You would not be told.
Using the SMART_HOST is usually a good idea.
<- page break ->