28 October 1997<br><br>
  The Linux Mail HOWTO is not being maintained by the author any<br>
  more.  If you are interested in maintaining the Mail HOWTO, please<br>
  get in touch with me at <i>gregh@sunsite.unc.edu</i>. <br>
<br>
  The Linux Mail HOWTO<br>
  Vince Skahan, <vince@halcyon.com><br>
  v1.12, 29 November 1995<br>
<br>
  This document describes the setup and care+feeding of Electronic Mail<br>
  (e-mail) under Linux.  You need to read this if you plan to communi­<br>
  cate locally or to remote sites via electronic mail.  You probably do<br>
  *not* need to read this document if don't exchange electronic mail<br>
  with other users on your system or with other sites.<br>
<br>
<b>  1.  Introduction</b><br>
<br>
  The intent of this document is to answer some of the questions and<br>
  comments that appear to meet the definition of 'frequently asked<br>
  questions' about e-mail software under Linux.<br>
<br>
  This document and the corresponding UUCP and News 'HOWTO' documents<br>
  collectively supersede the UUCP-NEWS-MAIL-FAQ that has previously been<br>
  posted to comp.os.linux.announce.<br>
<br>
<b>  1.1.  New versions of this document</b><br>
<br>
  New versions of this document will be periodically posted to<br>
  comp.os.linux.announce, comp.answers, and news.answers.  They will<br>
  also be added to the various anonymous ftp sites who archive such<br>
  information including sunsite.unc.edu:/pub/Linux/docs/HOWTO.<br>
<br>
  In addition, you should be generally able to find this document on the<br>
  Linux WorldWideWeb home page at http://sunsite.unc.edu/mdw/linux.html.<br>
<br>
<b>  1.2.  Feedback</b><br>
<br>
  I am interested in any feedback, positive or negative, regarding the<br>
  content of this document via e-mail.  Definitely contact me if you<br>
  find errors or obvious omissions.<br>
<br>
  I read, but do not necessarily respond to, all e-mail I receive.<br>
  Requests for enhancements will be considered and acted upon based on<br>
  that day's combination of available time, merit of the request, and<br>
  daily blood pressure :-)<br>
<br>
  Flames will quietly go to /dev/null so don't bother.<br>
<br>
  In particular, the Linux filesystem standard for pathnames is an<br>
  evolving thing.  What's in this document is there for illustration<br>
  only based on the current standard at the time that part of the<br>
  document was written and in the paths used in the distributions or<br>
  'kits' I've personally seen.  Please consult your particular Linux<br>
  distribution(s) for the paths they use.<br>
<br>
  Feedback concerning the actual format of the document should go to the<br>
  HOWTO coordinator - Greg Hankins (gregh@sunsite.unc.edu).<br>
<br>
<b>  1.3.  Copyright Information</b><br>
<br>
  The Mail-HOWTO is copyrighted (c)1994 Vince Skahan.<br>
<br>
  A verbatim copy may be reproduced or distributed in any medium<br>
  physical or electronic without permission of the author.  Translations<br>
  are similarly permitted without express permission if it includes a<br>
  notice on who translated it.<br>
<br>
  Short quotes may be used without prior consent by the author.<br>
  Derivative work and partial distributions of the Mail-HOWTO must be<br>
  accompanied with either a verbatim copy of this file or a pointer to<br>
  the verbatim copy.<br>
<br>
  Commercial redistribution is allowed and encouraged; however, the<br>
  author would appreciate being notified of any such distributions (as a<br>
  courtesy).<br>
<br>
  In short, we wish to promote dissemination of this information through<br>
  as many channels as possible. However, we do wish to retain copyright<br>
  on the HOWTO documents.<br>
<br>
  We further want that ALL information provided in the HOWTOS is<br>
  disseminated.  If you have questions, please contact Greg Hankins, the<br>
  Linux HOWTO coordinator, at gregh@sunsite.unc.edu.<br>
<br>
<b>  1.4.  Standard Disclaimer</b><br>
<br>
  Of course, I disavow any potential liability for the contents of this<br>
  document.  Use of the concepts, examples, and/or other content of this<br>
  document is entirely at your own risk.<br>
<br>
<b>  1.5.  Other sources of information</b><br>
<br>
<b>  1.5.1.  LINUX HOWTO Documents: </b><br>
<br>
  There is plenty of exceptional material provided in the other Linux<br>
  HOWTO documents and from the Linux DOC project.  In particular, you<br>
  might want to take a look at the following:<br>
<br>
  ·  the Serial Communications HOWTO<br>
<br>
  ·  the Ethernet HOWTO<br>
<br>
  ·  the Linux Networking Administrators' Guide<br>
<br>
<b>  1.5.2.  USENET: </b><br>
<br>
             comp.mail.elm           the ELM mail system.<br>
             comp.mail.mh            The Rand Message Handling system.<br>
             comp.mail.mime          Multipurpose Internet Mail Extensions.<br>
             comp.mail.misc          General discussions about computer mail.<br>
             comp.mail.multi-media   Multimedia Mail.<br>
             comp.mail.mush          The Mail User's Shell (MUSH).<br>
             comp.mail.sendmail      the BSD sendmail agent.<br>
             comp.mail.smail         the smail mail agent.<br>
             comp.mail.uucp          Mail in the uucp environment.<br>
<br>
<b>  1.5.3.  Books</b><br>
<br>
  The following is a non-inclusive set of books that will help...<br>
<br>
  ·  "Managing UUCP and USENET" from O'Reilly and Associates is in my<br>
     opinion the best book out there for figuring out the programs and<br>
     protocols involved in being a USENET site.<br>
<br>
  ·  "Unix Communications" from The Waite Group contains a nice<br>
     description of all the pieces (and more) and how they fit together.<br>
<br>
  ·  "Sendmail" from O'Reilly and Associates looks to be the definitive<br>
     reference on sendmail-v8 and sendmail+IDA.  It's a "must have" for<br>
     anybody hoping to make sense out of sendmail without bleeding in<br>
     the process.<br>
<br>
  ·  "The Internet Complete Reference" from Osborne is a fine reference<br>
     book that explains the various services available on Internet and<br>
     is a great source for information on news, mail, and various other<br>
     Internet resources.<br>
<br>
  ·  "The Linux Networking Administrators' Guide" from Olaf Kirch of the<br>
     Linux DOC Project is available on the net and is also published by<br>
     (at least) O'Reilly and SSC.  It makes a fine one-stop shopping to<br>
     learn about everything you ever imagined you'd need to know about<br>
     Unix networking.<br>
<br>
     Shameless plug mode ON - the sendmail+IDA descriptions below have<br>
     been very much expanded and more fully explained in Chapter 15 of<br>
     the  Linux Networking Administrators' Guide.  I strongly recommend<br>
     you grab a copy and read it.<br>
<br>
<b>  1.5.4.  Periodic USENET Postings</b><br>
<br>
  Also worth mentioning, is Chris Lewis' periodic posting on unix e-mail<br>
  software, which is available on rtfm.mit.edu in<br>
  /pub/usenet/comp.mail.misc/UNIX_Email_Software_Survey_*<br>
<br>
<b>  1.6.  Where *NOT* to look for help</b><br>
<br>
  There is nothing "special" about configuring and running mail under<br>
  Linux (any more).  Accordingly, you almost certainly do *NOT* want to<br>
  be posting generic mail-related questions to the comp.os.linux.*<br>
  newsgroups.<br>
<br>
  Unless your posting is truly Linux-specific (ie, "please tell me what<br>
  routers are already compiled into the SLS1.03 version of smail3.1.28")<br>
  you should be asking your questions in one of the newsgroups or<br>
  mailing lists referenced above.<br>
<br>
  Let me repeat that.<br>
<br>
  There is virtually no reason to post anything mail-related in the<br>
  comp.os.linux hierarchy any more.  There are existing newsgroups in<br>
  the comp.mail.* hierarchy to handle *ALL* your questions.<br>
<br>
  IF YOU POST TO COMP.OS.LINUX.* FOR NON-LINUX-SPECIFIC QUESTIONS, YOU<br>
  ARE LOOKING IN THE WRONG PLACE FOR HELP.  THE ELECTRONIC MAIL EXPERTS<br>
  HANG OUT IN THE PLACES INDICATED ABOVE AND GENERALLY DO NOT RUN LINUX.<br>
  POSTING TO THE LINUX HIERARCHY FOR NON-LINUX-SPECIFIC QUESTIONS WASTES<br>
  YOUR TIME AND EVERYBODY ELSE'S...AND IT FREQUENTLY DELAYS YOU FROM<br>
  GETTING THE ANSWER TO YOUR QUESTION.<br>
<br>
<b>  2.  Hardware Requirements</b><br>
<br>
  There are no specific hardware requirements for mail under Linux.<br>
<br>
  You'll need some sort of 'transport' software to connect to remote<br>
  systems, which means either tcp-ip or uucp.   This could mean that you<br>
  need a modem or ethernet card (depending on your setup).<br>
<br>
<b>  3.  Getting the software</b><br>
<br>
  In general, I grab my sources from ftp.uu.net and the other fine<br>
  archive sites on Internet.  In addition, Linux-specific binary ports<br>
  are found in the usual Linux distrbutions and on the usual Linux<br>
  anonymous ftp sites (sunsite.unc.edu and tsx-11.mit.edu in<br>
  particular).<br>
<br>
  The newspak-2.5.tar.z distribution contains config files and readme<br>
  files related to building uucp, news, and mail software under Linux<br>
  from the various freely-available sources.  It can usually be found in<br>
  sunsite.unc.edu:/pub/Linux/system/Mail/news.  If you can't find it on<br>
  sunsite, please send me mail and I'll make sure you get a copy of it.<br>
<br>
<b>  4.  Mail 'Transport Agents'</b><br>
<br>
  This section contains information related to 'transport agents', which<br>
  means the underlying software that connects your local system to<br>
  remote systems.<br>
<br>
<b>  4.1.  Smail v3.1</b><br>
<br>
  Smail3.1 seems to be a de-facto standard transport agent for uucp-only<br>
  sites and for some smtp sites.  It compiles without patching from the<br>
  sources.  In addition, smail is provided in binary form in the SLS<br>
  distribution of Linux.<br>
<br>
  The newspak distribution contains config files for smail3.1.28 under<br>
  Linux that you can use to start with.<br>
<br>
  If you're building smail from sources, you need to have the following<br>
  in your os/linux file so that 'sed' gives you shell scripts that work<br>
  properly.<br>
<br>
          CASE_NO_NEWLINES=true<br>
<br>
  For a uucp-only system that has a MX-record and that wants a<br>
  domainized header (who goes through a smart-host for everything),<br>
  these are the entire config files you'll need:<br>
<br>
  ·  replace 'subdomain.domain' with your domain name<br>
<br>
  ·  replace 'myhostname' with you un-domainized hostname<br>
<br>
  ·  replace 'my_uucp_neighbor' with the uucp name of your upstream site<br>
<br>
             #-------- /usr/local/lib/smail/config -----------------<br>
             #<br>
             # domains we belong to<br>
             visible_domain=subdomain.domain:uucp<br>
             #<br>
             # who we're known as (fully-qualified-site-name)<br>
             visible_name=myhostname.subdomain.domain<br>
             #<br>
             # who we go through<br>
             smart_path=my_uucp_neighbor<br>
             #<br>
             #---------- /usr/local/lib/smail/paths --------------<br>
             #<br>
             # we're a domainized site, make sure we accept mail to both names<br>
             myhostname        %s<br>
             myhostname.subdomain.domain      %s<br>
             #<br>
             #-------------------------------------------------------------------<br>
<br>
  To run smail as a smtp daemon, add the following to /etc/inetd.conf:<br>
<br>
                  smtp stream tcp nowait  root  /usr/bin/smtpd smtpd<br>
<br>
  Outgoing mail gets sent automatically, when using elm. If your inter­<br>
  net link is down when you send mail, then the mail sits in<br>
  "/usr/spool/smail/input".  When the link next comes up, "runq" is run<br>
  which causes the mail to be sent.<br>
<br>
<b>  4.2.  Sendmail+IDA</b><br>
<br>
  I run a ppp and uucp site and generally use sendmail5.67b+IDA1.5<br>
  instead of smail3.1.28 due to the incredible ease of use.  There is a<br>
  binary distribution in sunsite.unc.edu:pub/Linux/system/Mail/delivery.<br>
  To install it:<br>
<br>
  ·  you'll probably want to remove (or rename) all the files from smail<br>
     (see the /install/installed directory if you are SLS) to be safe.<br>
<br>
  ·  cd to / then "gunzip -c sendmail5.67b+IDA1.5.tpz | tar xvf -" If<br>
     you have a "modern" tar from a recent Slackware (for example) you<br>
     can probably just do a "tar -zxvf filename.tgz" and get the same<br>
     results.<br>
<br>
  ·  cd to /usr/local/lib/mail/CF and copy the sample.m4 local.m4 file<br>
     to "yourhostname.m4".  Edit out the distributed hostname, aliases,<br>
     and smarthost and put in the correct one for your site.  The<br>
     default file is for a uucp-only site who has domainized headers and<br>
     who talks to a smart host.  Then "make yourhostname.cf" and move<br>
     the resulting file to /etc/sendmail.cf<br>
<br>
  ·  if you are uucp-only, you do *NOT* need to create any of the tables<br>
     mentioned in the README.linux file.  You'll just have to touch the<br>
     files so that the Makefile works.  Just edit the .m4 file, make<br>
     sendmail.cf, and start testing it.<br>
<br>
  ·  if you're uucp-only and you talk to sites in addition to your<br>
     "smart-host", you'll need to add uucpxtable entries for each (or<br>
     mail to them will also go through the smart host) and run dbm<br>
     against the revised uucpxtable.<br>
<br>
  ·  if you use my sendmail5.67b+IDA1.5 distribution you should not use<br>
     a "freeze file".<br>
  ·  If you run Rich Braun's original binary distribution of 5.67a,<br>
     you'll need to freeze the configuration if you change your .cf file<br>
     with "/usr/lib/sendmail -bz" to make the changes take effect.  You<br>
     should also update your version to at least 5.67b since there is a<br>
     nasty security hole in 5.67a and earlier.<br>
<br>
  Another nice thing is that if you have mail.debug set and you run<br>
  syslogd, your incoming and outgoing mail messages will get logged.<br>
  See the /etc/syslog.conf file for details.<br>
<br>
  The sources for sendmail+IDA may be found at vixen.cso.uiuc.edu.  They<br>
  require no patching to run under Linux if you're running something<br>
  like a kernel of 1.00.<br>
<br>
  If you're running a current kernel of around 1.1.50 or later, you get<br>
  the fun of reversing most of the Linux-specific patches that are now<br>
  in the vanilla sources.  It's extremely obvious where this needs to be<br>
  done.  Just type make and when it blows up, go to that line in the<br>
  sources and comment out the Linux-specific code that's in there.<br>
<br>
  Sometime after things settle down, I'll send the 'unpatches' to the<br>
  sendmail+IDA authors and ask'em to remove the now unnecessary patches.<br>
<br>
  If you're going to run sendmail+IDA, I strongly recommend you go to<br>
  the sendmail5.67b+IDA1.5 version since all required Linux-specific<br>
  patches are now in the vanilla sources and several security holes have<br>
  been plugged that WERE (!!!) in the older version you may have grabbed<br>
  or built before about December 1st, 1993.<br>
<br>
  The May/June 1994 edition of Linux Journal has an extensive article on<br>
  the care and feeding of sendmail+IDA.  The new edition of the Linux<br>
  DOC Project Networking Administrator's Guide has an even more detailed<br>
  and complete version.<br>
<br>
<b>  4.2.1.  The sendmail.m4 file</b><br>
<br>
  Sendmail+IDA requires you to set up a sendmail.m4 file rather than<br>
  editing the sendmail.cffile directly.  The nice thing about this is<br>
  that it is simple to set up mail configurations that are extremely<br>
  difficult (if not totally impossible for most people to set up<br>
  correctly) in smail or traditional sendmail.<br>
<br>
  The sendmail.m4 file that corresponds to the above smail example looks<br>
  like the following:<br>
<br>
    dnl #------------------ SAMPLE SENDMAIL.M4 FILE ------------------<br>
    dnl #<br>
    dnl # (the string 'dnl' is the m4 equivalent of commenting out a line)<br>
    dnl #<br>
    dnl # you generally don't want to override LIBDIR from the compiled in paths<br>
    dnl #define(LIBDIR,/usr/local/lib/mail)dnl    # where all support files go<br>
    define(LOCAL_MAILER_DEF, mailers.linux)dnl    # mailer for local delivery<br>
    define(POSTMASTERBOUNCE)dnl                   # postmaster gets bounces<br>
    define(PSEUDODOMAINS, BITNET UUCP)dnl         # don't try DNS on these<br>
    dnl #<br>
    dnl #-------------------------------------------------------------<br>
    dnl #<br>
    dnl # names we're known by<br>
    define(PSEUDONYMS, myhostname.subdomain.domain myhostname.UUCP)<br>
    dnl #<br>
    dnl # our primary name<br>
    define(HOSTNAME, myhostname.subdomain.domain)<br>
    dnl #<br>
    dnl # our uucp name<br>
    define(UUCPNAME, myhostname)dnl<br>
    dnl #<br>
    dnl #-------------------------------------------------------------<br>
    dnl #<br>
    define(UUCPNODES, |uuname|sort|uniq)dnl       # our uucp neighbors<br>
    define(BANGIMPLIESUUCP)dnl                    # make certain that uucp<br>
    define(BANGONLYUUCP)dnl                       #  mail is treated correctly<br>
    define(RELAY_HOST, my_uucp_neighbor)dnl       # our smart relay host<br>
    define(RELAY_MAILER, UUCP-A)dnl               # we reach moria via uucp<br>
    dnl #<br>
    dnl #--------------------------------------------------------------------<br>
    dnl #<br>
    dnl # the various dbm lookup tables<br>
    dnl #<br>
    define(ALIASES, LIBDIR/aliases)dnl            # system aliases<br>
    define(DOMAINTABLE, LIBDIR/domaintable)dnl    # domainize hosts<br>
    define(PATHTABLE, LIBDIR/pathtable)dnl        # paths database<br>
    define(GENERICFROM, LIBDIR/generics)dnl       # generic from addresses<br>
    define(MAILERTABLE, LIBDIR/mailertable)dnl    # mailers per host or domain<br>
    define(UUCPXTABLE, LIBDIR/uucpxtable)dnl      # paths to hosts we feed<br>
    define(UUCPRELAYS, LIBDIR/uucprelays)dnl      # short-circuit paths<br>
    dnl #<br>
    dnl #--------------------------------------------------------------------<br>
    dnl #<br>
    dnl # include the 'real' code that makes it all work<br>
    dnl # (provided with the source code)<br>
    dnl #<br>
    include(Sendmail.mc)dnl                         # REQUIRED ENTRY !!!<br>
    dnl #<br>
    dnl #------------ END OF SAMPLE SENDMAIL.M4 FILE -------<br>
<br>
<b>  4.2.2.  Defining a local mailer</b><br>
<br>
  Unlike most Unix distributions, Linux does not come with a local mail<br>
  delivery agent by default.  I recommend using the commonly available<br>
  deliver program, which is an optional package in a number of the usual<br>
  Linux distributions.  In order to do so, you need to define a<br>
  LOCAL_MAILER_DEF in the sendmail.m4 file that points to a file that<br>
  looks like:<br>
<br>
    # -- /usr/local/lib/mail/mailers.linux --<br>
    #     (local mailers for use on Linux )<br>
    Mlocal, P=/usr/bin/deliver, F=SlsmFDMP, S=10, R=25/10, A=deliver $u<br>
    Mprog,  P=/bin/sh,       F=lsDFMeuP,   S=10, R=10, A=sh -c $u<br>
<br>
  There is a also built-in default for deliver in the Sendmail.mc file<br>
  that gets included into the sendmail.cf file.  To specify it, you<br>
  would not use the mailers.linux file but would instead define the<br>
  following in your sendmail.m4 file:<br>
<br>
     dnl --- (in sendmail.m4) ---<br>
     define(LOCAL_MAILER_DEF, DELIVER)dnl       # mailer for local delivery<br>
<br>
  Unfortunately, Sendmail.mc assumes deliver is installed in /bin, which<br>
  is not the case with Slackware1.1.1 (which installs it in /usr/bin).<br>
  In that case you'd need to either fake it with a link or rebuild<br>
  deliver from sources so that it resides in /bin.<br>
<br>
<b>  4.2.3.  The Sendmail+IDA dbm Tables</b><br>
<br>
  Setting up special behavior for sites or domains is done through a<br>
  number of optional dbm tables rather than editing the sendmail.cf file<br>
  directly.  Refer to the July-1994 issue of Linux Journal, to the docs<br>
  in the sources, or to the sendmail chapter in the newest version of<br>
  the Linux DOC Project Networking Administration Guide which will be<br>
  available real-soon-now for more details.<br>
<br>
  ·  mailertable   - defines special behavior for remote hosts or<br>
     domains.<br>
<br>
  ·  uucpxtable    - forces UUCP delivery of mail to hosts that are in<br>
     DNS format.<br>
<br>
  ·  pathtable     - defines UUCP bang-paths to remote hosts or domains.<br>
<br>
  ·  uucprelays    - short-circuits the pathalias path to well-known<br>
     remote hosts.<br>
<br>
  ·  genericfrom   - converts internal addresses into generic ones<br>
     visible to the outside world.<br>
<br>
  ·  xaliases      - converts generic addresses to/from valid internal<br>
     ones.<br>
<br>
  ·  decnetxtable  - converts RFC-822 addresses to DECnet-style<br>
     addresses.<br>
<br>
</b>  4.2.4.  So Which Entries are Really Required? </b><br>
<br>
  When not using any of the optional dbm tables, sendmail+IDA delivers<br>
  mail via the RELAY_HOST and RELAY_MAILER) defined in the sendmail.m4<br>
  file used to generate sendmail.cf.  It is easily possible to override<br>
  this behavior through entries in the domaintable or uucpxtable.<br>
<br>
  A generic site that is on Internet and speaks Domain Name Service, or<br>
  one that is UUCP-only and forwards all mail via UUCP through a smart<br>
  RELAY_HOST, probably does not need any specific table entries at all.<br>
<br>
  Virtually all systems should set the DEFAULT_HOST and PSEUDONYMS<br>
  macros, which define the canonical site name and aliases it is known<br>
  by.  If all you have is a relay host and relay mailer, you don't need<br>
  to set these defaults since it works automagically.<br>
<br>
  UUCP hosts will probably also need to set UUCPNAME to their official<br>
  UUCP name.  They will also probably set RELAY_MAILER, and RELAY_HOST<br>
  which enable smart-host routing through a mail relay.  The mail<br>
  transport to be used is defined in RELAY_MAILER and should usually be<br>
  UUCP-A for UUCP sites.<br>
<br>
  If your site is SMTP-only and talks `Domain Name Service', you would<br>
  change the RELAY_MAILER.<br>
<br>
  If you're a SLIP site, you might want to take the easy way out and<br>
  just forward all outgoing mail to your service provider to do the<br>
  right thing with.  To do so, you'd want to define ISOLATED_DOMAINS and<br>
  VALIDATION_DOMAINS to be your domain, you'd also want to define<br>
  RELAY_HOST to be your service provider and RELAY_MAILER to be TCP. Of<br>
  course, you want to ask permission before you set any system up as<br>
  your general purpose relay.<br>
<br>
<b>  4.3.  Sendmail 8.7</b><br>
<br>
  Sendmail 8.7.x from Berkeley is the latest major revision after<br>
  sendmail5.  It has wonderful built-in support for building under<br>
  Linux.  Just "make linux" and you'll be all set.  You'll probably be<br>
  best served by grabbing one of the various binary distributions off of<br>
  the usual Linux archive sites rather than fighting things like<br>
  Berkeley dbm yourself.<br>
<br>
  There's a nice distribution of sendmail 8.6.12 from Jason Haar -<br>
  j.haar@lazerjem.demon.co.uk on sunsite.unc.edu in<br>
  /pub/Linux/system/Mail/delivery/sendmail-8.6.12-bin.tgz that has the<br>
  source documentation and a very nice quickie description of how to run<br>
  sendmail v8 for common configurations.<br>
<br>
  Bottom line with sendmail v8 is that you want to configure the bare<br>
  minimum necessary to get the job done.  The following is an example<br>
  that should get you close at least.<br>
<br>
<b>  4.3.1.  A Sample 8.7.x mc file</b><br>
<br>
  Much like sendmail+IDA, sendmail v8 uses m4 to process a config file<br>
  into a full sendmail.cf that sendmail uses.  The following is my<br>
  current mc file for my site (ppp to Internet for outgoing mail, uucp<br>
  for incoming mail).<br>
<br>
          dnl divert(-1)<br>
          #---------------------------------------------------------------------<br>
          #<br>
          # this is the .mc file for a linux host that's set up as follows:<br>
          #<br>
          #       - connected to Internet for outbound mail (ppp here)<br>
          #       - connected via UUCP for incoming mail<br>
          #       - domainized headers<br>
          #       - no local mailer (use 'deliver' instead)<br>
          #       - no DNS running so don't canonicalize outgoing via DNS<br>
          #       - all non-local outbound mail goes to the RELAY_HOST over smtp<br>
          #           (we run ppp and let our service provider do the work)<br>
          #<br>
          #                                       vds 3/31/95<br>
          #<br>
          #---------------------------------------------------------------------<br>
          include(`../m4/cf.m4')<br>
          VERSIONID(`linux nodns relays to slip service provider smarthost')dnl<br>
          Cwmyhostname.myprimary.domain myhostname.UUCP localhost<br>
          OSTYPE(linux)<br>
          FEATURE(nodns)dnl<br>
          FEATURE(always_add_domain)dnl<br>
          FEATURE(redirect)<br>
          FEATURE(nocanonify)<br>
          dnl MAILER(local)dnl<br>
          MAILER(smtp)dnl<br>
          MAILER(uucp)dnl<br>
          define(`RELAY_HOST', smtp:my.relay.host.domain)<br>
          define(`SMART_HOST', smtp:my.relay.host.domain)<br>
          define(`UUCP_RELAY', smtp:my.relay.host.domain)<br>
          define(`LOCAL_MAILER_PATH', `/bin/deliver')<br>
          define(`LOCAL_MAILER_ARGS', `deliver $u')<br>
<br>
<b>  4.3.2.  Sendmail v8 tidbits</b><br>
<br>
  There are a few differences I suppose to the 'IDA bigots' among us.<br>
  So far, I've found the following.<br>
<br>
  ·  Instead of 'runq', you type 'sendmail -q' to run the queue<br>
<br>
<b>  4.4.  Other "transport agents"</b><br>
<br>
  The following also are known to run under Linux.  Consult "archie" for<br>
  details regarding how to find them...<br>
<br>
  ·  smail2.5 - very simple UUCP-based smail<br>
<br>
<b>  4.5.  Local Delivery Agents</b><br>
<br>
  Unlike most operating systems, Linux does not have mail "built-in".<br>
  You'll need a program to deliver the local mail.  One good program is<br>
  Rich Braun's "lmail" program, but I've switched to using the more<br>
  commonly available "deliver" program.<br>
<br>
  Documentation for how to use either for local delivery is in the<br>
  sendmail5.67b+IDA1.5 binary release (on sunsite) mentioned above.<br>
<br>
<b>  5.  Mail "User Agents"</b><br>
<br>
  This section contains information related to "user agents", which<br>
  means the software the user sees and uses.  This software relies on<br>
  the "transport agents" mentioned above.<br>
<br>
<b>  5.1.  Elm</b><br>
<br>
  Elm compiles, installs, and runs flawlessly under Linux up to and<br>
  through Slackware 1.1.1 (gcc2.4.5, gcclib 4.4.4).  For more<br>
  information, see the elm sources and installation instructions.<br>
<br>
  The only thing to know is that Elm's Configure script incorrectly sets<br>
  the "ranlib" and "stdarg" variables in config.sh.  The Elm Development<br>
  Team has been informed of this little problem, so please don't bother<br>
  them with it (again).<br>
<br>
  ·  (from  Chip Rosenthal - chip@chinacat.unicom.com ) The easiest way<br>
     to deal with this is to create a file called config.over at the top<br>
     of you Elm source tree and include the line:<br>
<br>
             ranlib='ranlib'<br>
             stdarg='define'<br>
<br>
  ·  Elm and filter need to be mode 2755 (group mail) with<br>
     /usr/spool/mail mode 775 and group mail.<br>
<br>
     If you use a binary distribution, you'll need to create a<br>
     /usr/local/lib/elm/elm.rc file to override the compiled-in hostname<br>
     and domain information:<br>
<br>
  ·  replace "subdomain.domain" with your domain name replace<br>
<br>
  ·  "myhostname" with you un-domainized hostname replace<br>
<br>
             #---------- /usr/local/lib/elm/elm.rc ------------------<br>
             #<br>
             # this is the unqualified hostname<br>
             hostname = myhostname<br>
             #<br>
             # this is the local domain<br>
             hostdomain = subdomain.domain<br>
             #<br>
             # this is the fully qualified hostname<br>
             hostfullname = myhostname.subdomain.domain<br>
             #<br>
             #--------------------------------------------------------<br>
<br>
  One thing you want to be aware of is that if you have Elm compiled to<br>
  be MIME-able, you need metamail installed and in your path or Elm will<br>
  not be able to read MIME mail you've received.  Metamail is available<br>
  on thumper.bellcore.com and of course via "archie".<br>
<br>
  We have heard reports that gcc and gcclib newer than v2.4.5 and v4.4.4<br>
  respectively are rather strict and fail to compile Elm.  Here's the<br>
  scoop as reported by  ccnp@unitrix.utr.ac.za (Neil Parker)  who<br>
  forwarded a posting by  longyear@netcom.com (Al Longyear).<br>
<br>
  ·  ELM is using internal fields in the FILE structure in an effort to<br>
     bypass the standards. (The _flag, _IOERR, and _IOEOF are old fields<br>
     for the pre-POSIX runtime package. While POSIX doesn't say that you<br>
     can't define these fields, it does not say that you _must_. Linux<br>
     does not. It does say that programs should not be written to use<br>
     them, even if they are in the implementation.)<br>
<br>
              where it does         if (fp->_flag & _IOERR) ...<br>
              change it to          if (ferror(fp)) ....<br>
<br>
              where it does         if (fp->_flag & _IOEOF) ...<br>
              change it to          if (feof(fp)) ...<br>
<br>
              These are the ANSI/POSIX definitions for the same function.<br>
<br>
  ·  Also, there is a nice set of diffs for Elm 2.4.23 that works just<br>
     fine (for me at least) located on nic.funet.fi in the file<br>
     /pub/OS/Linux/kernel/src/net-source/mail/elm-2.4.24.dif that works<br>
     around some Linux-isms.  While just grabbing the vanilla sources<br>
     and patching with these diffs works fine, I've personally had<br>
     success with just setting up the config.over file mentioned above<br>
     and only patching opt_utils.c and lock.c in the Elm sources. (I run<br>
     kernel 1.3.33 over Slackware 2.1.0)<br>
<br>
  ·  In the "too cool to be true" category, there is a distribution of<br>
     Elm-2.4.24 that is "PGP-aware".  To try it, grab the file<br>
     ftp://ftp.viewlogic.com/pub/elm-2.4pl24pgp3.tar.gz, which is<br>
     elm2.4.24 with PGP hooks added.  You configure and build it the<br>
     same way you do normal Elm, which means you probably need to add<br>
     the patches mentioned above.  For what it's worth, I run it here<br>
     and like it a lot.<br>
<br>
  ·  While this item is not Linux-specific, it's perceived (wrongly) to<br>
     be a nagging Elm bug nevertheless.  We've heard that Elm sometimes<br>
     fails with a message that it's unable to malloc() some massive<br>
     number of bytes.  The identified workaround is to remove the post-<br>
     processed global mail aliases (aliases.dir and aliases.pag).<br>
<br>
     THIS IS NOT A BUG IN ELM.  It's an error in configuration of Elm by<br>
     whomever you got your binary distribution of Elm from.  Elm has an<br>
     enhanced, and non-compatible, format for aliases.  You need to<br>
     ensure that the path Elm uses for aliases is different from the<br>
     path sendmail/smail uses.  From the volume of reports of this<br>
     problem, it's apparent that at least one major distribution 'on the<br>
     street' has in the past been misconfigured.  The current Slackware<br>
     does it correctly.<br>
<br>
  ·  (from  scot@catzen.gun.de (Scot W. Stevenson) )<br>
<br>
     The current metamail package requires csh for some of its scripts.<br>
     Failure to have csh (or tcsh) will cause most interesting errors...<br>
<br>
<b>  5.2.  Mailx</b><br>
<br>
  Safe yourself the pain.  Just go and grab the mailx kit from Slackware<br>
  2.1.0 or later, which has a nice implementation of mailx5.5.  If<br>
  you're into building from sources, mailx v5.5 compiles without<br>
  patching under Linux if you have "pmake" installed.<br>
<br>
  If anybody is still using it, I strongly recommend removing the old<br>
  "edmail" stuff from SLS1.00 and replacing it with mailx.<br>
<br>
<b>  5.3.  Other user agents</b><br>
<br>
  The following also are known to run under Linux.  Consult "archie" for<br>
  details regarding how to find them...<br>
<br>
  ·  Pine      - from the Univ. of Washington<br>
<br>
  ·  Metamail  - allows MIME support<br>
<br>
  ·  mh      - yet another way to handle mail<br>
<br>
  ·  deliver   - file/process mail based on rules<br>
<br>
  ·  procmail  - file/process mail based on rules<br>
<br>
  ·  Majordomo - manages e-mail lists<br>
<br>
  ·  Mserv     - provide files-by-mail<br>
<br>
<b>  6.  Acknowledgements</b><br>
<br>
  The following people have helped in the assembly of the information<br>
  (and experience) that helped make this document possible:<br>
<br>
  Steve Robbins, Ian Kluft, Rich Braun, Ian Jackson, Syd Weinstein, Ralf<br>
  Sauther, Martin White, Matt Welsh, Ralph Sims, Phil Hughes, Chip<br>
  Rosenthal, Scot Stevenson, Neil Parker<br>
<br>
  If I forgot anybody, my apologies...<br>
<br>
<br>