Email does not normally get a delivery confirmation, except for the nearest neighbour in the hop list. However email can be rejected, either immediately (smtp-norm), later (uucp-norm) or never.

A typical reason is "No such person known at this host". SMTP knows by looking in /etc/passwd that the user exists, or by looking in its aliases database, or ... other. It is advantageous to respond immediately if possible, as the connection is open and active, especially if the comms are end-to-end direct.

One example of this is FEATURE(redirect), if enabled, will lookup the name in the aliases list. If the result is user@host.elsewhere.REDIRECT, the callers email will fail, but they get a nice diagnostic, telling them where to go.

If you wish to achnoledge all email you receive, with a standard "Thankyou for yor email, Subject: RE: Text our-ref 1234, this is an automated reply, etc" email, you want it to happen whilst the user is still online, with a direct focus, avoiding smarthosts. You need to get sendmail to pass thhe message through a script (a bit like cgi really), as well as queuing the email for delivery.

The script belongs to the specific user (eg sales@, marketing@, admin@, each getting a different reply), and could be on your server (under your control), or on the ISP's server - which should give a faster response, and you only need to dial-in once every hour.

Users that go on vacation may with

Generally: deliver(1) can run  /.deliver (of target mailbox) with a full toolbox of access environment variables. The manual quotes an example:

(cat $HEADER; tr '[A-Z]' '[a-z]' < $BODY) | deliver -n "$1"

Once the system adminstrators has set up the system, either allowing each user to write their own .deliver, or install one of a pre-agreed list of scripts (using a menu) -then- the user ia autonomous, and can adjust their own configuration day-or-night, as many times as they wish.

It is up to the user how often they want to go on holiday, and have a note saying whatever is up to date information (back soon ...). These may be administered (by general agreement), by line managers who have group access to a list of users files (group-name = managers-role).

Users with several machines, that move around can redirect their email (like telephone follow-me's), to where they are (the home machine), or the currently assigned receptionist. People who change their name by deed-poll get a new email address, and .forward from their old login name. To save time searching through /albatros/home2/name, - which may be spun-down or NFS (possibly broken), sendmail can be told not to pick  /.forward (the default) but any sequence you can encode into the 'J' option. IE a central directory. [SEE: op.me 2.5 ".forward Files" (use mc-3.1 to view).

Direct [iInternet connectivity is great when its available, but email can get through all sorts of fire-walls, and run efficiently as batch jobs. (Though the limited range of btes available out of 256 is disappointing).

A DTP bureau, (eg the bosses office upstairs with the colour laser, but no time for riff raff to use it), can make the printer available be email. A customer transmits a file (eg postscript packed with uuencode) to the printer queue, and an operator guides it thru, possibly after previewing it for sensible page options.r

The sender may have a less sophisticated PC to transmit from, and email multi-media is ideal as a basic, testable transport - ftp with cover notes. V34 modems, the -slow- part of the journey, have good compression of uuencoded text (unmeasured=???).

Since sendmail can deliver to a script, you can do pretty much anything. one example is to extract a phone number (prefixed from an approved list), a file format (postscript, groff, plain text, tif, ... ) and send the document as a FAX, possibly keeping a LOG or archive record.

A centralised service, available from <many-places>. You could even route international FAXES over the Internet (but others might find the number).

Please remember that (yet again) I'm telling you what might be possible, not HOW to debug it. Unless you see an article elsewhere And I'm covering subjects I've never touched. Get excited about the ideas, but don't bet your company car on them unless: YOU MAKE THAT CHOICE.

THIS IS CONJECTURE, GUESSWORK, DREAMING AND BALONEY

You can use majordomo, listmail, procmail, .forward or your scripts to act as document servers, which send documents on request, or add users to mailing lists (bandwidth permitting). You could add HTML as a from-end to browse the documents "online", and request documents in <selected format=groff source>.

A sort of FAX-BACK, but in high quality, grep-able formats (or even a compressed tar archive, that expands to HTML + gif's, giving the same as the on-line brochures, but not at 14.4 K modem speeds, and offline).

Majordomo is used by many kind universities (etc) to provide a BBS service, for approved services, to the general public. Excessive use of bandwidth often leads to actual improved services, as popular services are obviously fulfilling a need, and get modest facilities allocated.

Having strayed from the issue of installing sendmail for 'leaf' access to Internet email, i hope you see how the sendmail.cf file (amoungs others) has built up a complex combination of configuration options. This should encourage you when browsing the DOC files listed above, and searching for others, eg man(1) pages such as mailaddr(7).

If the host is a gateway (propername "trix"), it may be sitting on two networks. The gateway to and from the Internet is called trix.dircon, the gateway to/from the LAN is trix.trix.org.

This host has to receive email from either side, and accept it as intended for 'here'. Cw defines a list of names that the gateway recognises as itself.

If the Cw list grows too long, it can be transfered to /etc/sendmail.cw, one name per line. [op.me 1.2 near line 343 [src/sendmail/cf/README L-285

Obviously you could relocate that file (not a good idea, unless it is to an optimised virtual file system, that accesses the data faster, using less space (and disk head seeks). [SEE: cf/README L-1053 "confCW FILE"

See following text ...

Every machine on the LAN (Private not Internet), has a name like raven.trix.org. Neither its EMAIL hostaddr, nor its LAN IP_ADDR is available for use on the Internet (other than <trix.dircon.co.uk:user@raven> ).

You can put a routed address <gw1,gw2:user@host.domain> in the REPLY_TO, or you could hide the internal topology (which changes), so that email is simply <user@trix.dircon.co.uk>. The gateway has to do some intelligent routing. The workstation has to accept mail addressed to raven.trix.org -or- trix.dircon.co.uk (-or- localhost), and for the purpose of sending mail, it should consider itself to BE the originating "trix.dircon.co.uk", and put that in all From: headers (see also pine(1) elm(1) sendmail(1) smail(?)).

/etc/HOSTNAME would contain raven.trix.org. (the trix in domainname(trix,org) does not have to be the name of the gateway, but it makes sense. If you find it confusing, it is because you haven't accepted it yet. Try looking at it the other way around. Name the gateway after the company (or site) that it contains. eg users@sparrow.NW10.org manages to reserve the name NW10.demon.co.uk from the ISP. NW10 is a UK PostCode zone (zip code).

Other users in the NW10 district have lost the opportunity to do that themselves, but if you do that for every size where you have an account, your network maps will make sense to you. If PostCodes are not your ideal name, think of an abstract collection of <use your imagination>. Each site can have local names that follow a local scheme. It will make your life easier if all hosts have unique basenames.

You then purchase a company email name (such as heinz.com) which only really has one site - the central office that accepts and re-routes email from people who don't know the site names. That site would probably be a permanent connection with a #5000 pa leased line.

The /etc/HOSTNAME is effectively the name of the Ethernet card on the LAN: sparrow.NW10.org, or even sparrow.lan_67.heinz.com (Please excuse me borrowing a well known trade name for my example, substitute pigeon.lan_67.<your-name-here>.com (presumably the local EMAIL server).

Every host needs a UNIQUE TCP/IP NAME, to validate and convey its IP_ADDR (albeit private names.org on private addresses 192.168.67.xxx ).

This file allows you to allocate EMAIL names for users, that differ from their login names. eg my login is "gps", but you can send email to any of my aliases, provided I have edited /etc/aliases.

Occasionally names will conflict, however in a large company (>10,000), there are supprisingly few conflicts of the basic scheme of G.P.Swallow.

Regrettable /etc/aliases is NOT for redirection from the gateway, however when you arrive at your leaf host, you can allow a list of aliases. For small companies (with only one MAIL server), you can create multimple schemes:

user_1016: gps		# thats the central db's tag
gps_1016: gps		# make nicer for me
Graham_Swallow: gps	# unique so far
G_P_Swallow: gps	# unique so far, slightly boring
G.P.Swallow: gps	# I don't like dots in the user_name
Graham: gps		# local mail is subjectively unique
c_o_l_a: gps		# majordome sends digestified feed to ... me

Now edit the installed /etc/sendmail.cf file, adding the following declarations (find them and add the otherwise blank paramater). Note they are NOT indented at all.

The smarthost (smartpath) is your ISP's mail server. It should have a full configuration, and be able to send to UUCP domains that you have never heard of.

DSmailhost.dircon.co.uk

However, all this takes time, and may result in a connection to an overloaded server, and long delays sending your mail. Sending to your smarthost first will probably be MUCH faster (if your ISP is OK).

If you compose your EMAIL when SLIP (PPP) is down, sendmail will write a fault to /var/adm/messages, and fall back to the smarthost, putting the email into a queue. To send the queue, fire up SLIP and run sendmail -q in the dip_in script (or wait for 15 minutes for the next batch run).

sendmail -q	# attempt to send the queue NOW

If you are always connected, your ISP will probably forward your mail immediately. Otherwise it batches up the mail, and waits for you to dial in.

My ISP has a simple mechanism, where I finger @mailhost, and it then prints a simple message (4 mail items waiting for you), and starts sending them. In addition, the finger remains connected until they are sent. I put the relevent command in my dip_in script so that it always runs.

Actually I do it twice, to confirm that nothing is left. (My ISP has a bug where there is often 1 left in the queue).

Ensure that your machine has its PROPER email name in /etc/HOSTNAME.

Otherwise your sendmail may refuse mail not addressed to itself, or your ISP my refuse to send to a host with the wrong name in its SMTP banner. To see how your host announces itself (and what it believes its primary name to be) try:

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.9 ready at Sat, 27 Jan 1996
04:06:10 GMT
220 ESMTP spoken here
quit
221 trix.dircon.co.uk closing connection
Connection closed by foreign host.

I can't get this to work! I want to rename my box to "raven", and the DOCS say I can, but ... I tried the following two parameters in sendmail.cf, but got nowhere. Your milage may vary. grep sendmail.cw /usr/src/sendmail.cf.obj/*.cf

In theory, this is how you configure a LAN of hosts OFF the internet with a gateway on BOTH. Every machine Masquerades as the 'proper' Internet gateway when sending mail (so replies work). They all use the gateway as the smart host. The smarthost uses aliases to send the messages back to the correct host (you must configure a comprehensive list of aliases). Each host accepts mail as trix.dircon.co.uk AND as itsname.raven.org.

Cwlocalhost trix.dircon.co.uk raven.lan67.priv
DMtrix.dircon.co.uk

Login names should be terse and unique, email names may be aliased to the login name. Edit /etc/aliases (no indent) then run newaliases. Test immediately.

Graham_Swallow: gps
Graham.Swallow: gps
G.P.Swallow: gps
Graham: gps

Test mail route to and from smarthost.

This is the syntax that tells SMTP mail to route email firstly via your smarthost, then from there to yourhost. Its how you test that you can send mail to your smarthost, and it can send to you.

If you test to and from a friends machine, you may go through your smart_hosts anyway.

It is also how you route email to an 'private' email address (that is not known on the Internet, via a gateway that does recognise the address. If you put it into your Reply-to, it should work. However, users (and users on remote sites, who can't reach you to find out what's wrong) will get it muddled.

An alternative, is to send email to a majordomo, asking it for help. If the response comes back inseconds, you know that the other host is not overloaded, so your email is not being a pest.

I used to use smail and was very happy with it, but it may have been a tad slower, and now I get mail returned when the network is unreachable (ie AFTER a successful connection, then dip_out, then compose). This MAY be solved by using the dummy network, or by editing the configuration to timout after 3 days.

sendmail (in the same circumstance) reports the timeout to /var/adm/messages, but requeues the job to the smarthost.