home *** CD-ROM | disk | FTP | other *** search
/ ARM Club 3 / TheARMClub_PDCD3.iso / hensa / internet / freesmtp / smtp_freenet / ReadMeNOW!
Text File  |  1996-10-16  |  36KB  |  961 lines
  1. !FreeSMTP 1.18
  2. ==============
  3.  
  4. Contents:
  5.     Copyright & Disclaimer
  6.     Important Changes in this Version
  7.     Installation Instructions
  8.     Upgrading from Earlier versions
  9.     Configuration Instructions
  10.         Why does all email get sent to "localhost"
  11.     Operating Advice
  12.         for people with permanent links
  13.         for people with transient dialup links
  14.     Running & Stopping !FreeSMTP
  15.     What to do if you get the error message:
  16.         Loopback interface is not configured/up
  17.         Loopback interface is configured - but not up
  18.     Kicking the sender
  19.     Activity log
  20.     References
  21.     Bug Reporting
  22.     Technical Details
  23.         MX records explained
  24.         Security Considerations
  25.         Ident
  26.     ChangeLog
  27.  
  28.  
  29. **** WARNING: Incorrect configuration can cause you to be in breach
  30. **** of your provider's terms & conditions.  Full details under the
  31. **** configuration section below, in the subsection "forwarder"
  32.  
  33.  
  34.  
  35.  
  36. Copyright & Disclaimer
  37. ----------------------
  38.  
  39. This program is copyright (C) Stewart Brodie, 1996.
  40.  
  41. The author accepts no liability for any damage or loss of any kind incurred,
  42. or allegedly incurred, by the use, or misuse, of this software.  The program
  43. may do its absolute best to ensure that incoming mail is either stored
  44. successfully in the incoming (or outgoing) mail spool appropriately, or that
  45. the sender is informed that the delivery attempt was unsuccessful and should
  46. be retried (or not as appropriate).
  47.  
  48. Having said all that, I do want people to use it and find any problems.  I'm
  49. afraid that some people's attitude make all those disclaimers necessary.  For
  50. normal usage, there shouldn't be any problem, and the programs try very hard
  51. indeed to prevent any loss occurring (eg. by not acknowledging successful
  52. reception of an e-mail until it has been successfully stored in the spool
  53. directory completely).  If the program fails, then in the vast majority of
  54. cases the upstream SMTP will have received a rejection from this program
  55. (unrequested connection termination counts as a rejection unless the 250
  56. response to the final '.' of a DATA body is received at the sender).  If the
  57. sender half of this software fails, then it it will construct a failure
  58. message and return that directly to the message originator.
  59.  
  60.  
  61.  
  62. Important Changes in this Version
  63. ---------------------------------
  64.  
  65. You MUST be running the SMTP server in order to get mail to be
  66. *sent* - since the sendmail transport will always direct mail
  67. to "localhost".
  68.  
  69. This version will NOT start unless you have configured the loopback
  70. interface correctly.
  71.  
  72.  
  73. Installation Instructions
  74. -------------------------
  75.  
  76. Installation should be fairly simple and trouble free provided these
  77. instructions are followed carefully.  You will NEED Newsbase 0.55 in
  78. order for this to work properly - it will not like 0.54.  I have tried
  79. to include as much details as possible, so don't worry about the apparent
  80. length of it.
  81.  
  82. * Copy the Transports directory into the !Newsbase directory to install the
  83. interface programs in Newsbase. (You may find that you have to restart
  84. Newsbase now to get it to recognise the newly present transport).
  85.  
  86. * Copy the !FreeSMTP directory into a directory containing your other
  87. Internet applications, and run it in its new home (it will fail to start
  88. because there is no configuration file, but this step is necessary in
  89. order to reset the system variables to point to the correct directory)
  90.  
  91. * Open the Newsbase Transport Control window, and in the middle portion
  92. of this window, choose "in_smtpd" off the Transport menu.  You should now see
  93. the description "SMTP for FreeNet/Acorn TCP/IP (S.N.Brodie)" or similar.  If
  94. you fail to get this far, then you may have forgotten to restart Newsbase or
  95. to rerun !FreeSMTP.
  96.  
  97. * Switch on the Check arrivals new mail option.
  98.  
  99. * Follows the instructions in the Configuration Instructions below
  100.  
  101. * Ensure you have a DNS resolver configuration file.  If you do not have a
  102. DNS resolver installed on your system, then you will need to get one.  You
  103. can find this out by looking for a file in !Internet.Files (or
  104. !FreeUser.Files or !InetSuite.Internet.Files) called "resconf".  If this is
  105. present, then you have already got the necessary file installed.  The
  106. resolver module is NOT used, but the configuration file it uses IS used by
  107. these programs (FreeNet (by Tom Hughes) comes with InetDB and its
  108. installation instructions; ArcWeb (my program) comes with just the
  109. installation instructions necessary)
  110.  
  111.  
  112. Upgrading from Earlier versions
  113. -------------------------------
  114.  
  115. Reinstall the Transports into !Newsbase.  If you changed the log file
  116. locations in !Run, re-edit the *new* !Run since this contains new
  117. system variables that are required.
  118.  
  119. Your mail is received into a different directory than before version 1.14.
  120. This makes it compatible with the KA9Q directory structure.
  121.  
  122. You should read the section on 'noiconbar' in the configuration section as
  123. this is a new command.
  124.  
  125.  
  126. Configuration Instructions
  127. --------------------------
  128.  
  129. There is a single configuration file for !FreeSMTP which is stored
  130. inside the !FreeSMTP directory.  This is deliberately entirely made
  131. up of comments so that the programs will refuse to load before you
  132. have edited the configuration.  You should find that you can skim
  133. through this section, modifying the file as you go.
  134.  
  135. (If !FreeSMTP.smtp-conf does not exist, then either copy it from defaultcnf
  136. in the same directory, or click on Setup in the Newsbase Transport Control
  137. window which will do this for you)
  138.  
  139. The configuration file is a sequence of directives which tell the
  140. software what your machines real name is, what e-mail domains it
  141. hosts, and which domains it relays mail for (if any).  I have tried
  142. to provide as much flexibility as possible whilst keeping it as
  143. simple as possible for the vast majority of cases (take a look at an
  144. /etc/sendmail.cf file on a UNIX system to see how hairy it can become :-)
  145.  
  146. To edit the configuration file, choose the "in_smptd" transport in the
  147. Newsbase "Transport Control" window.  You should then see the description
  148. message "SMTP for FreeNet/Acorn TCP/IP (S.N.Brodie)".  To set up the Newsbase
  149. bit, ensure that "Check arrivals: new mail" is set; Route outgoing mail is
  150. set, and a smarthost is placed in the gateway box for mail(**).  Also set
  151. in_smtpd as the Def mail route.  Then, you should click on the Setup button
  152. which will open the configuration file in your text editor ready for you
  153. to set your own site details.
  154.  
  155. (**) If you set the gateway to be your own machine, then you MUST have
  156.      an appropriate forwarder line as described below.  The line you
  157.      will need will be "forwarder * provider's-smarthost".
  158.  
  159. Provided you have set up the forwarder lines, you can tell any software
  160. you have to send outgoing mail to 'localhost'.  This will result in it
  161. being sent to the server which will then route it using the rules in
  162. smtp-conf without consulting Newsbase.
  163.  
  164. There are brief comments in the configuration file to remind you what each
  165. section is for, but these are elaborated here.  The order of the sections is
  166. not important, although the order of declarations of the same type IS
  167. important (see below for reasons) For each section I have given the syntax,
  168. an example for a Demon DialUp user with a nodename of 'customer',
  169. (application to other static IP single host systems too), an example for a
  170. host on a network handling mail for that network, and my own setup.
  171.  
  172.  
  173. hostname
  174. ========
  175.  
  176. Syntax:   hostname <Fully Qualified Domain Name (FQDN)>
  177. Demon DU: hostname customer.demon.co.uk
  178. Network:  hostname mail.an.org.uk
  179. My Setup: hostname delenn.ecs.soton.ac.uk
  180.  
  181. This gives the *full* hostname(s) of the machine running this software.
  182. Hosts may have more than one name in some circumstances, and this is
  183. allowed by having multiple hostname lines, although the *first* line
  184. found in the file is the one used to identify the server to remote
  185. hosts when it needs to (eg. when greeting SMTP clients)
  186.  
  187. localdomain
  188. ===========
  189.  
  190. Syntax:   localdomain <Fully Qualified Mail Domain> [<alias name>]
  191. Demon DU: localdomain customer.demon.co.uk
  192. Network:  localdomain an.org.uk
  193. My Setup: localdomain delenn.ecs.soton.ac.uk soton
  194.  
  195. [and in My Setup, <SMTPServer$Aliases>.soton contains the line:
  196. S.N.Brodie snb94r
  197. ]
  198.  
  199. This gives the local *mail* domain(s) handled by the software.  These
  200. mail domains are the things you see after the @ in mail addresses.
  201. When mail arrives, the destination is checked to see if there is any
  202. @ character in it.  If there is NOT, then the value of the *first*
  203. localdomain directive is assumed.  (This is so that the alias and user
  204. list functions can determine which set of aliases to apply)
  205.  
  206. Next, the bit after the @ is compared against each localdomain directive in
  207. turn.  If it matches any one of them, then the domain part is dropped. Next,
  208. if an alias name was specified for that localdomain, then the bit before the
  209. @ is looked up in <SMTPServer$Aliases>.aliasname to see if was a mail alias,
  210. and if so, the mail address is rewritten to match the definition of the
  211. alias.  The format of that file is described below.  You MUST be careful with
  212. that file.
  213.  
  214. Otherwise, the bit before the @ is assumed to be a mailbox in the local
  215. Newsbase. (If no domains match, then it is checked against the forwarders
  216. below)
  217.  
  218. For single dialup hosts, there is likely to be a single setting which
  219. will happen to co-incide with the hostname.  For hosts serving entire
  220. domains, this is less likely. (Note that in My Setup, I accept mail for
  221. an unofficial mail domain - you won't find an MX record in the DNS for
  222. the delenn.ecs.soton.ac.uk mail domain)
  223.  
  224. alias file format
  225. =-=-=-=-=-=-=-=-=
  226.  
  227. The format of the file is that the alias appears first on the line, and
  228. the real addresses are specified after it seperated by whitespace.  If
  229. you need to use more than one line, then these continuation lines MUST
  230. start with whitespace (otherwise they are considered to be other aliases)
  231.  
  232. Although this might seem like a good way to set up a mailing list, this
  233. is NOT the case, since the original sender will be in the FROM envelope,
  234. so any forwarding errors will go to there and not to some mailing list
  235. software.
  236.  
  237. The purpose of the alias file is for *simple* rewriting and occasional
  238. duplication if you need it.  If you want to run a mailing list, then
  239. use something like !MailList.
  240.  
  241. So in My Setup mentioned above shows that any mail incoming addressed
  242. to S.N.Brodie@delenn.ecs.soton.ac.uk will be sent to snb94r.  This is
  243. useful because you can specify names which might not be acceptable as
  244. usernames to Newsbase.
  245.  
  246.  
  247.  
  248. forwarder
  249. =========
  250.  
  251. Syntax:   forwarder <"*" | F.Q. Mail Domain> <"MX" | smarthost-FQDN>
  252. Demon DU: forwarder * post.demon.co.uk
  253. Network:  forwarder * MX
  254.           forwarder * mail.smarthost.provider.org
  255. My Setup: forwarder ecs.soton.ac.uk MX
  256.           forwarder * dsse.ecs.soton.ac.uk
  257.  
  258.  
  259. This gives mail domains which are to be responded to by the software, but
  260. which are not local to this machine (ie. they need to forwarded on somewhere
  261. else, cf. localdomain).  For the vast majority of people, you will want one
  262. forwarder line (see WARNING below - having such lines may in fact
  263. contravene your provider's terms & conditions of service unless you have
  264. specifically purchased the right to forward mail).
  265.  
  266. The major purpose of the non-* entries here is when you are running FreeSMTP
  267. on the mail gateway for a domain (ie. the MX record for a domain gives
  268. the machine running FreeSMTP as one of the mail exchangers).
  269.  
  270. If there are no forwarder lines, then any mail not destined for local
  271. delivery (ie. it matched one of the localdomain lines) will be rejected when
  272. it is offered by another host (*).
  273.  
  274. If there are forwarder lines, then they are matched in order.  If the first
  275. parameter is "*", then this matches, otherwise the string has to match the
  276. bit after the @ in the destination of an incoming mail exactly.  The second
  277. parameter describes how this forwarding is to be achieved and is either the
  278. string "MX" or the FQDN of a smarthost which will do the job for you.
  279.  
  280. There are two ways of forwarding the mail - MX records, and smarthosts. Using
  281. MX records involves looking up the name of the machines which handle mail for
  282. a given mail domain (see description later in this document) and then sending
  283. the mail directly to one of those machines.  The alternative is to use a
  284. 'smarthost' (such as post.demon.co.uk) which will perform that function on
  285. your behalf (ie. it acts as an intermediate relay for you). The advantage of
  286. using MX records, is that it bypasses your provider's smarthost (less hops to
  287. the destination) and can tolerate the smarthost being down.  When MX lookups
  288. return multiple records, they are tried in turn according to the priorities
  289. specified by the DNS server. [This does seem to work, as I found out when
  290. Demon's punts weren't accepting mail and when the connection attempt to them
  291. timed out, it sent it to relay-1 instead :-) ]
  292.  
  293. (*) 'another host' could actually be your own machine.  For example, I
  294. have ArcWeb's Email configuration set up with a smarthost mail gateway
  295. of "localhost".  This means that ArcWeb will send mail by talking to the
  296. SMTP server process running on my own machine.  Thus, having no forwarder
  297. lines in my configuration would mean that I couldn't send mail that way
  298. and would have to configure a remote smarthost in ArcWeb instead.
  299.  
  300.  
  301. forwarder strategy
  302. -=-=-=-=-=-=-=-=-=
  303.  
  304. The forwarder directives which specify MX records are to be used are
  305. overridden in some circumstances, primarily for performance reasons.
  306.  
  307. If the mail has only a single recipient (or multiple recipients with the same
  308. domain) and forwarder says to use MX records, and those MX records exist,
  309. then this will happen.
  310.  
  311. If the mail has multiple recipients, then any MX directive is overridden and
  312. a smarthost is used instead *if one is defined* (because otherwise the
  313. message would have to be sent seperately to each recipient).  [A future
  314. enhancement will be to still use MX records if all the destinations share a
  315. common mail exchanger]
  316.  
  317.  
  318. WARNING: Incorrect configuration of forwarder records could cause you
  319.          to be in breach of the terms & conditions of your account.
  320.          Unless you are authorised to forward mail to hosts other than
  321.          those at your provider's end of your connection, you should
  322.          only have one forwarder line:
  323.          
  324.         forwarder * post.demon.co.uk
  325.     
  326.          (where you have substituted your provider's smarthost for
  327.          post.demon.co.uk if you aren't with Demon Internet)
  328.          
  329.          The author accepts no responsibility or liability for any
  330.          such breaches of terms & conditions, nor for consequences
  331.          arising from action taken by providers against any user of
  332.          this software for such breaches.
  333.  
  334.  
  335. acceptfrom
  336. ==========
  337.  
  338. Syntax:   acceptfrom ((<IP address> "/" <significant bits>) | ( FQDN ))
  339. Demon DU: acceptfrom 158.152.1.0/24
  340. Network:  acceptfrom mail.deliverer.provider.org
  341. My Setup: (no acceptfrom lines)
  342.  
  343. ** WARNING: If you use hostnames with this command, then these must be
  344. **          resolvable when the program starts, otherwise the directive
  345. **          will be ignored.
  346.  
  347. This is used to selectively choose which remote hosts you are willing to
  348. accept mail from.  If a host other than one listed attempts to deliver
  349. mail to your machine, then it will be told that it does not have permission
  350. to deliver mail to your machine.  If there are no acceptfrom lines (as in
  351. My Setup) then any host may connect.
  352.  
  353. When specifying an IP address, you may specify the number of significant bits
  354. to be matched.  The Demon DU example describes that mail from 158.152.1.xxx
  355. will be accepted.
  356.  
  357. All addresses that pass the acceptfrom directives (including the case
  358. where there are NO acceptfrom directives) are then validated against
  359. the rejectfrom directives described in the next section.
  360.  
  361. IMPORTANT:  If you have any of these fields, then you MUST include
  362. all the machine's own IP addresses and you MUST include localhost (ie.
  363. 127.0.0.1), since the outgoing sender may use these addresses when
  364. constructing error notifications and performing mail rewriting.
  365.  
  366. There is little real reason to use this facility unless you are worried
  367. about faked e-mail being sent via your site (and even then, the message
  368. is tagged with the Received line containing the IP address of the sender,
  369. allowing you to trace the source)
  370.  
  371. See also: rejectfrom, killfile
  372.  
  373. rejectfrom
  374. ==========
  375.  
  376. Syntax:   rejectfrom ((<IP address> "/" <significant bits>) | ( FQDN ))
  377. Demon DU: rejectfrom 198.81.0.0/16
  378.           rejectfrom 152.163.172.0/24
  379. Network:  rejectfrom relay.deliverer.hackers.org
  380. My Setup: (no rejectfrom lines)
  381.  
  382. ** WARNING: If you use hostnames with this command, then these must be
  383. **          resolvable when the program starts, otherwise the directive
  384. **          will be ignored.
  385.  
  386. This is used to selectively choose which remote hosts you are NOT willing to
  387. accept mail from.  If a host covered by one of these directives, then it will
  388. be told that it does not have permission to deliver mail to your machine.  If
  389. there are no rejectfrom lines (as in My Setup) then any host may connect
  390. (subject to the acceptfrom conditions).  The Demon DU example describes that
  391. mail from 198.81.xxx.xxx and from 152.163.172.xxx will be rejected (these
  392. are the AOL mail exchangers :-)
  393.  
  394. IMPORTANT: You should not reject any of your machine's own IP addresses
  395. (including 127.0.0.1 (localhost)).  See also: acceptfrom, killfile
  396.  
  397. There is very little real reason to use this facility unless you have
  398. some hacker trying to send you mail, in which case you can block their
  399. IP address using this facility.
  400.  
  401.  
  402. killfile
  403. ========
  404.  
  405. Syntax:   killfile <Fully Qualified Kill File path name>
  406. Demon DU: killfile smtpserver:killfile
  407. Network:  killfile smtpserver:killfile
  408. My Setup: killfile smtpserver:killfile
  409.  
  410. This is used to kill incoming mail based on the *sender* specified
  411. in the SMTP envelope (ie. the MAIL FROM).  The file named in the
  412. directive is consulted when a new transaction is started and if
  413. the sender matches any entry, the mail is rejected.
  414.  
  415. The kill file format itself is one (wildcardable) address per line.
  416. If the kill file does not exist, nothing is killed.
  417.  
  418.  
  419. noexpand
  420. ========
  421.  
  422. Syntax:   noexpand
  423. Demon DU:
  424. Network:  noexpand
  425. My Setup:
  426.  
  427. This directive is optional and takes no parameters.  If it is present,
  428. then clients attempting an EXPN on an alias will receive a message
  429. indicating that EXPN has been explicitly disabled by the administrator.
  430.  
  431. If you don't understand the above paragraph, then you don't need this.
  432.  
  433. Normally, you'd only use this to stop people looking up the members of
  434. a mailing list of something like that.  The vast majority of people
  435. do not want this.
  436.  
  437.  
  438. noident
  439. =======
  440.  
  441. Syntax:   noident
  442. Demon DU:
  443. Network:  noident
  444. My Setup:
  445.  
  446. This directive is optional and takes no parameters.  If it is present,
  447. then the server will not attempt an ident request to the client making
  448. the connection.  See "Remote User Authentication" section below for
  449. more details of ident.
  450.  
  451. If you don't understand the above paragraph, then you don't need this.
  452.  
  453. You would only ever disable this feature for efficiency reasons.
  454.  
  455. noiconbar
  456. =========
  457.  
  458. Syntax:   noiconbar
  459. Demon DU: noiconbar
  460. Network:
  461. My Setup:
  462.  
  463. This directive is optional and takes no parameters.  If it is present,
  464. then no icon bar icon will be installed.
  465.  
  466. You would only ever disable this feature to avoid filling your iconbar.
  467.  
  468. maxhops
  469. =======
  470.  
  471. Syntax:   maxhops <maximum hop count>
  472. Demon DU:
  473. Network:
  474. My Setup:
  475.  
  476. This directive is optional and defaults to "maxhops 30".  The numeric
  477. parameter describes the maximum number of servers through which the mail is
  478. allowed to be passed before being returned to the sender as undeliverable. 
  479. Usually, mail will take at most half a dozen hops to get to the recipient. 
  480. If it is up to something more like 30 (the default here), then it is likely
  481. that a mail loop has developed (a set of servers (mis)configured to route
  482. mail for the destination domain to each other, which will just keep
  483. forwarding it back and forth forever and ever).  Once maxhops is exceeded,
  484. the server will not forward it any more, but will construct a delivery
  485. failure message and bounce it back to the sender.
  486.  
  487. Almost certainly, you do not want to override the default.
  488.  
  489.  
  490. maxsessions
  491. ===========
  492.  
  493. Syntax:   maxsessions <+ve integer>
  494. Demon DU: maxsessions 4
  495. Network:  maxsessions 4
  496. My Setup: maxsessions 4
  497.  
  498. This specifies the maximum number of sessions that may be in progress at
  499. any one time.  This is limited by the capability of the C library (and if
  500. you specify a number too large, it will be reduced to the maximum that can
  501. be supported - 4 with the current SharedCLibrary.
  502.  
  503. It is important to have this set to 4 for Demon customers, since Demon
  504. have multiple mail machines which may attempt delivery concurrently.
  505.  
  506.  
  507. Why does all email get sent to "localhost"
  508. ------------------------------------------
  509.  
  510. All e-mail sent by your machine will be sent initially to the server on your
  511. machine.  (tech: the GATE command in the work file will always be set up
  512. to be "GATE VIA:localhost").  This is deliberate, because all the mail
  513. routeing cleverness is stored in the *server* at the moment.  That software
  514. can then make the final destination decision and requeue it for sending out.
  515.  
  516. This will cause an extra Received header to be placed in the outgoing mail,
  517. and will also ensure that missing headers are inserted before the mail
  518. leaves your machine too.
  519.  
  520.  
  521.  
  522.  
  523. Operating Advice
  524. ----------------
  525.  
  526. for people with permanent connections
  527. =====================================
  528.  
  529. Run it all the time - that's what I do.
  530.  
  531.  
  532. for people with transient dialup links
  533. ======================================
  534.  
  535. You really do want to start the TCP/IP stack and !FreeSMTP *before*
  536. connecting to the net.  This is particularly important for Demon users, since
  537. the SMTP server takes around 1 second to start up and read its configurations
  538. files and may not manage to start listening for the incoming connections
  539. before the punts attempt to deliver mail (they fail to do so, and hold on to
  540. it for a while before trying again a bit later).  This causes a slight
  541. problem with dialup lines though unless you are careful.  You *must* start
  542. the TCP/IP stack, but you do NOT need to start up the SLIP/PPP interface (if
  543. you do, your dialler won't be able to access the comms port!).  The relevant
  544. bits that must be deferred until after dialling is complete are the slattach
  545. & ifconfig commands 
  546.  
  547.  
  548. Running & Stopping !FreeSMTP
  549. ----------------------------
  550.  
  551. Run !FreeSMTP by double-clicking on the icon in the directory viewer.
  552. To stop, it double-click on the icon again (or kill SMTP Monitor in
  553. the Task display window) or choose Quit from the icon bar menu if you
  554. haven't disabled the Wimp interface (see "noiconbar" directive above)
  555.  
  556.  
  557. What to do if you get the error message:
  558.     Loopback interface is not configured/up
  559.     Loopback interface is configured - but not up
  560. -----------------------------------------------------
  561.  
  562. These two messages are new in version 1.17.  If you get them, then you
  563. will find that the program will not have started.  FreeSMTP needs the
  564. loopback interface configured.  This should have been done during your
  565. boot sequence, or whenever the TCP/IP networking software was loaded.
  566.  
  567. If you get the latter of the messages (which would be unusual unless
  568. you were fiddling around), then you need to issue the command:
  569. "*ifconfig lo0 up" at the command line or insert this in the networking
  570. startup files.
  571.  
  572. If you get the former, then you need to insert the slightly longer:
  573. "*ifconfig lo0 inet 127.0.0.1 up".
  574.  
  575. Once these commands have been executed, FreeSMTP should load. 
  576.  
  577. (See also: Why does all email get sent to "localhost")
  578.  
  579.  
  580.  
  581. Kicking the sender
  582. ------------------
  583.  
  584. The sender program (out_smtpd) is automatically launched (by SMTP Monitor)
  585. after in_smtpd has queued a mail in the outgoing queue, or the sendmail
  586. Newsbase transport has queued a mail there.  You can kick it by choosing
  587. "Kick" on the icon bar menu (see "noiconbar" directive) or double-clicking on
  588. !SendSMTP (inside !FreeSMTP).
  589.  
  590. After being loaded, it will wait 30 seconds, then 1 minute, then 2, 4, 8,
  591. then 16 minutes, and thereafter every 30 minutes. This is in addition to the
  592. other times when it is kicked manually or by the server.
  593.  
  594.  
  595. Activity Log
  596. ------------
  597.  
  598. This software contains inbuilt activity logging which it will dump to
  599. the files smtp_log, clnt_log & mon_log inside the !FreeSMTP directory.
  600. The amount of debugging and which debugging is controlled by a file called
  601. area-log, also inside !FreeSMTP.  This contains one string per line
  602. containing a case-sensitive string to match against those used in the code. 
  603. (* is used as a wildcard which matches every string).  Examples of these are:
  604.  
  605.     domain_init
  606.     process_mail
  607.     verify_dest
  608.     
  609. Vital messages are always logged if possible.  The file is left open
  610. whilst the server is actively writing to it and closed after a short
  611. delay if nothing is written to it, for efficiency reasons.  The location
  612. of the log file can be altered by editing !Run and changing the settings
  613. of the three <SMTPServer$xxxxxLog> variables.
  614.  
  615. These will need to be cleared out every now & again.
  616.  
  617. If you place a line containing just a single * character in this file, then
  618. everything will be logged to this file, this will help provided more details
  619. if you are having problem.  If you send me this file when reporting faults,
  620. then it is more likely that I shall be able to help.
  621.  
  622.  
  623. References
  624. ----------
  625.  
  626. RFC821 - Simple Mail Transfer Protocol
  627.  
  628. RFC1123 - Requirements for Internet Hosts
  629.  
  630. RFC1413 - Identification Protocol
  631.  
  632.  
  633. Bug Reporting
  634. -------------
  635.  
  636. There are bug reporting features built-in to the software.  If you edit
  637. the file !FreeSMTP.area_log and add a new line at the bottom containing
  638. just an asterix (*), then all debugging information will be sent to the
  639. files, and not just the really important ones.  These document some of
  640. the decisions made by the software and will contain justification for
  641. those decisions.
  642.  
  643. Please give as much detail as possible when reporting bugs.  Include the
  644. e-mail message that caused the problem if possible.  NOTE:  If you do not
  645. wish to disclose the identities of the sender/recipient, then please feel
  646. free to overwrite it with something else - use * characters for example -
  647. but please do NOT just remove it.  If you do choose to delete parts of it,
  648. then please only delete the bits before the @ in the address.  You may
  649. also like to remove most of the message body.
  650.  
  651. Bug reports to S.N.Brodie@ecs.soton.ac.uk please
  652.  
  653.  
  654. Technical Details
  655. -----------------
  656.  
  657. I have included this section for those who are interested.  It does not
  658. matter if you do not want to read any more of this document.
  659.  
  660. MX Records Explained
  661. ====================
  662.  
  663. Briefly.  You are probably familiar with the concept of hostnames (eg.
  664. customer.demon.co.uk, www.demon.co.uk, sunsite.doc.ic.ac.uk).  The mappings
  665. between these and the 4 byte numeric IP addresses (eg. 152.78.67.42) are
  666. registered in the Domain Name System's 'A' records (A for address).  Mail
  667. domains look very much like hostnames, and in some cases happen to be the
  668. same, but this is coincidence (but arranged like that because it's easier to
  669. remember :-)   Mail domains are also registered in the Domain Name System,
  670. but they do NOT map to IP addresses, but to 'Mail eXchangers'.  These mail
  671. exchangers are simply the hostnames of machines which handle mail for that
  672. mail domain.  For example, when software is using MX records to send me mail,
  673. it looks up the MX records for 'ecs.soton.ac.uk'.  The response it will get
  674. will be something similar to:
  675.  
  676. ecs.soton.ac.uk. IN MX 5 bright.ecs.soton.ac.uk.
  677. ecs.soton.ac.uk. IN MX 10 landlord.ecs.soton.ac.uk.
  678.  
  679. This indicates that bright.ecs.soton.ac.uk (which when looked up, is found to
  680. have the address 152.78.64.201) is a machine which handles mail for
  681. 'ecs.soton.ac.uk'.  landlord.ecs.soton.ac.uk is also reported as a mail
  682. exchanger (so when bright is down, we can still receive mail), but the lower
  683. number indicates that bright is the preferred exchanger, and landlord the
  684. backup.  If you perform a similar lookup on any Demon customer domain,
  685. usually you will find 4 or 5 records, with varying priorities.  Although it
  686. would appear that lots of DNS lookups are required in order to find the
  687. addresses of these mail exchangers, that is not the case typically, as the
  688. full response from the DNS for the question "ecs.soton.ac.uk IN MX" will be
  689. (if not querying one of our authoritative nameservers in Southampton):
  690.  
  691. Questions:
  692. ecs.soton.ac.uk. IN MX
  693.  
  694. Answers:
  695. ecs.soton.ac.uk. IN MX 5 bright.ecs.soton.ac.uk.
  696. ecs.soton.ac.uk. IN MX 10 landlord.ecs.soton.ac.uk.
  697.  
  698. Additional:
  699. bright.ecs.soton.ac.uk IN A 152.78.64.201
  700. landlord.ecs.soton.ac.uk IN A 152.78.114.230
  701.  
  702. Authority records:
  703. dns0.ecs.soton.ac.uk    inet address = 152.78.64.201
  704. dns1.ecs.soton.ac.uk    inet address = 152.78.114.230
  705. dns0.brad.ac.uk inet address = 143.53.240.2
  706. dns0.brad.ac.uk inet address = 143.53.2.5
  707. dns1.brad.ac.uk inet address = 143.53.238.5
  708.  
  709. ie. since it is assumed that you will probably want the IN A record for
  710. each mail exchanger, the DNS server includes those records in its answer
  711. which you may need.  Since you may not 'trust' the nameserver, it also tells
  712. you machines that are the authoritative DNS servers for the ecs.soton.ac.uk
  713. internet domain.  The auth records show the names of our primary and
  714. secondary DNS servers, plus our offsite authority nameserver (an Internet
  715. requirement) at Bradford.
  716.  
  717.  
  718. Remote host authentication
  719. ==========================
  720.  
  721. When a connection is accepted, the peer IP address is looked up in the DNS.
  722. Since this lookup is initiated immediately, then the lookup is often 
  723. complete before the HELO arrives (and the HELO parameter can thus be
  724. authenticated immediately).  The domain name specified as the parameter to
  725. HELO is used in the Received header which is added by the smtp server to
  726. the incoming message, together with either the IP address of the remote
  727. host, or the name as obtained from the DNS.
  728.  
  729. NOTE: Mail will NOT be rejected if the HELO domain fails to authenticate.
  730. This is RFC-compliant behaviour (it is not allowed to reject on the basis
  731. of the HELO domain).
  732.  
  733.  
  734. Remote user authentication
  735. ==========================
  736.  
  737. When a connection is accepted, then an ident request is sent to the origin
  738. machine requesting the user identity of the sender.  (This is not done if
  739. the configuration file contains a "noident" directive).  This is logged
  740. with area "ident" (so place "ident" in area_log to see it in smtp_log).
  741.  
  742. NOTE: You cannot rely on this, particularly on the user id returned. See
  743. RFC1413 for more details about the (lack of) confidence that you should
  744. have in the ident response.
  745.  
  746. NOTE 2: You might decide to disable this, but usually only because the
  747. overhead of establishing a TCP connection to the client wastes resources.
  748. The bandwidth used is negligible though (on average about 10 bytes out,
  749. and 25-50 bytes back).
  750.  
  751.  
  752. Attacks & Security Considerations
  753. =================================
  754.  
  755. Simple denial of service attacks are prevented (limits on number of
  756. recipients for message plus limits on number of concurrent connections)
  757. The recipient limit is set to 100 (minimum requirement in RFC821)
  758.  
  759. Idling attacks are repelled by implementing the timeout strategy given
  760. in RFC1123.
  761.  
  762. Well faked e-mail can never be detected successfully, but the addition
  763. of the Received header to incoming message bodies will assist in the
  764. tracing of injection points into the SMTP system.
  765.  
  766. Three log files are generated inside !FreeSMTP.  These are called smtp_log
  767. and clnt_log and mon_log, and are generated by the server, client and monitor
  768. respectively.
  769.  
  770. For the general mail security considerations see RFC821 and RFC1123.  In
  771. the RISC OS environment, a further consideration is that being a single-
  772. user operating system, there is no way to prevent the Newsbase being
  773. examined directly, or the outgoing queue to be examined, unless you have
  774. taken specific measures to make this so.
  775.  
  776. RFC1123 Considerations
  777. ======================
  778.  
  779. Incoming addresses in both MAIL FROM and RCPT TO fields are automatically
  780. rewritten as per RFC1123 to strip unnecessary source routeing from them.
  781. This happens before any other processing.  (This also has the effect of
  782. stopping hackers using source routeing as a way of using you as a mail
  783. gateway, since after the rewrite, the destination domain will no longer
  784. match a localdomain, and will be rejected unless you forward for that
  785. domain)
  786.  
  787. The %-hack is supported by the address rewriter too and explicitly
  788. removed, so hackers can't use that either.
  789.  
  790. Miscellaneous
  791. =============
  792.  
  793. When spooling files if the file cannot be opened in spool.mail.text.user then
  794. spool.fail.user is used instead (and the mail is bounced if that fails too). 
  795. Files in spool.fail.user are never touched again and need to be handled
  796. manually.
  797.  
  798. I am very interested in RFC compliancy issues. E-mail
  799. me any issues you find.
  800.  
  801.  
  802. ChangeLog
  803. =========
  804.  
  805. 1.16
  806. ----
  807.  
  808. The smtp_log left open problem is definitely gone now, because the file is
  809. gone too!  Everything is dumped in mon_log instead.
  810.  
  811. Aliases with capital letters in now work
  812.  
  813. The forwarder doesn't consider you a twat for not using MX records and
  814. constantly override that decision. :-)
  815.  
  816.  
  817. 1.14
  818. ----
  819.  
  820. Local spool directory changed to be spool.mail.text.*
  821.  
  822.  
  823. 1.13
  824. ----
  825.  
  826. Bug in sender fixed - it was treated the successfully connection being made
  827. to the server as an error :-/
  828.  
  829.  
  830. 1.12
  831. ----
  832.  
  833. Full release of the not grabbing all processing time version.  Also
  834. contains a bug fix that cures a misinteraction caused by two concurrent
  835. mail deliveries.  Log file closing finally sorted.  However, because of
  836. the fix, you can't view smtp_log whilst the server is running.
  837.  
  838.  
  839. 1.10
  840. ----
  841.  
  842. Should be better behaved and not grab as much processor time, which should
  843. help people using dialup links
  844.  
  845. 1.09
  846. ----
  847.  
  848. Log file should be closed successfully now
  849.  
  850.  
  851. 1.06
  852. ----
  853.  
  854. Mail can now be sent even without a terminating linefeed.  This would have
  855. caused mail to not be delivered.
  856.  
  857. 1.05
  858. ----
  859.  
  860. DNS Resolver bug fix
  861.  
  862. 1.04
  863. ----
  864.  
  865. RFC compliancy fix: doesn't try the A record if all the MX records fail.
  866. A records only used if no MX records were found.
  867.  
  868. Extra debug information put in to try to determine the cause of some
  869. apparent premature timing out.
  870.  
  871. Activity log notes in this document updated to cover bug reports.
  872.  
  873.  
  874. 1.03
  875. ----
  876.  
  877. VRFY fixed again!  It was rejecting non-local single recipient aliases
  878. because Newsbase was saying that the user was unknown.
  879.  
  880.  
  881. 1.02
  882. ----
  883.  
  884. Fixed domain name processing to not add surplus > characters
  885.  
  886. EXPN procession now works properly again
  887.  
  888.  
  889. 1.01
  890. ----
  891.  
  892. Fixed acceptfrom and rejectfrom handling - the bitfield masks were
  893. the wrong way around 
  894.  
  895.  
  896. 1.00
  897. ----
  898.  
  899. TRACE removed from the sendmail transport!!
  900.  
  901. maxhops added
  902.  
  903. Vital missing headers are added to incoming mail
  904.  
  905.  
  906. 0.11
  907. ----
  908.  
  909. You can disable the GUI by adding 'noiconbar' to the configuration file
  910.  
  911. Some of the log messages are clearer
  912.  
  913. Bug in sendmail transport file corrected
  914.  
  915.  
  916. 0.10
  917. ----
  918.  
  919. Very simple Wimp interface added
  920.  
  921. Some log messages have been changed to make them sound less fatal (some
  922. are purely informational but had alarming sounding overtones)
  923.  
  924. in_smtpd's sendmail reads the smtp-conf file to determine how to send
  925. mail to single recipients, instead of defaulting to MX records (when
  926. no gateway can be found, and none was given in Newsbase, multiple
  927. mails are generated to all of the recipients via MX records)
  928.  
  929.  
  930.  
  931. 0.09
  932. ----
  933.  
  934. Multi-line responses were confusing the SMTP sender because I'd got a
  935. condition test round the wrong way :-(
  936.  
  937. Lock files removed - the task list is scanned instead.
  938.  
  939. Long lines were confusing things all over the place.  Although illegal,
  940. some clients still generate this, so I allow them now too.
  941.  
  942. The socket sender had every chance of crashing if a line was to be
  943. transmitted which was longer than 256 characters!  This is now 
  944. upped to 1024 characters (something which calling routines already
  945. enforce)
  946.  
  947. SMTP Monitor uses an exponential backoff retry algorithm for sending mail
  948. when it is first started - it delays 30 seconds, then 1 minute, then 2,
  949. then 4, then 8, then 16, then every 30 minutes.  It can still be launched
  950. manually by running !SendSMTP and will be launched whenever you send mail
  951. locally.
  952.  
  953.  
  954.  
  955. Please e-mail me any problems: snb94r@ecs.soton.ac.uk
  956.  
  957.  
  958. --
  959. Stewart Brodie
  960. April 1996
  961.