home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / sendmail / sendmail-5.65c+IDA-1.4.4.1 / ida / cf / COMMENT < prev    next >
Encoding:
Text File  |  1990-06-07  |  6.7 KB  |  129 lines
  1.               Some comments on my rewrite of Sendmail.mc .
  2.  
  3.                                                         Neil Rickert,
  4.                                                         rickert@cs.niu.edu
  5.                             Thu, 7 Jun 90
  6.  
  7.   (Note: These are ex post facto comments, and do not necessarily reflect my 
  8.          thinking during the early part of the design phase.)
  9.  
  10. 1.  Data structures.
  11.  
  12.     It has long been my philosophy that the three most important ingredients 
  13.     of good programming are: Data structures, data structures, and data 
  14.     strucures.  I think I came up with a pretty good data structure for 
  15.     representing addresses. 
  16.  
  17.     You can essentially think of the internal address as being represented as 
  18.     an array, or more accurately as an array implementation of a pushdown 
  19.     stack.  The bottom element of the stack is the 'user' identifier in the 
  20.     final destination domain.  Otherwise each element is a pair consisting of 
  21.     a domain (the '@domain' portion) and an addressing format flag (the ',' or 
  22.     ':' or '!').  The majority of the .cf file deals with the top of the 
  23.     stack.  For example, you can think of the PATHTABLE lookup as popping the 
  24.     top from the stack and then pushing the domains of its pathalias lookup 
  25.     value. 
  26.  
  27.     The mailer specific rulesets, of course, must use the fact that the stack 
  28.     is implemented as an array, so that they can visit each entry and modify 
  29.     the flag.
  30.  
  31.     There is, of course, one more overall flag, which I implemented with the 
  32.     choice of either '@' or '%' as the leading character for the primary 
  33.     domain.  Think of this as an overall flag to distinguish between sender 
  34.     and recipient addresses.  This was added when I realized I was pushing the 
  35.     limit of the 30 allowable rulesets, and I didn't wish to require code 
  36.     changes if it could be avoided.  It was pretty obvious that the mailer 
  37.     specific rulesets for sender and recipient addresses were usually very 
  38.     similar, so this flag idea makes sense.  The flag idea could easily have 
  39.     been extended to also distinguish between header and envelope addresses, 
  40.     but I felt that would be overreaching for the present. 
  41.  
  42. 2.  Logic.
  43.  
  44.     In my (admittedly biased) opinion, the internal logic is, in the main, 
  45.     simpler than in the original IDA.  The original package was made overly 
  46.     complex by the continual reformatting from a bang path to a source route 
  47.     to %-path, and then possibly converting it back again.  Part of my 
  48.     motivation in doing this rewrite was my frustration with the complexity of 
  49.     the original IDA.  Almost every time I studied it closely I found another 
  50.     logic error, usually caused by making unwarranted assumptions in the 
  51.     process of conversion of an address between formats.  It is fortunate that 
  52.     most of these logic errors rarely caused serious problems. 
  53.  
  54.     It is much simpler to retain a consistent internal representation, and 
  55.     work mostly by changing the 'addressing format flag'. 
  56.  
  57.     Most of the remaining complexity is because the internal representation as 
  58.     an array of domains must be crudely simulated in a tokenized character 
  59.     string.  Except for the mailer specific rulesets, which need considerable 
  60.     flexibility, this would have been much easier to implement in code than in 
  61.     the replacement rulesets.  A code version would probably be more reliable, 
  62.     too.  Paul mentioned that Berkeley is working on a sendmail replacement.  
  63.     Perhaps they should look at this config, together with these comments, for 
  64.     one possible approach to address formatting. 
  65.  
  66. 3.  Dealing with ambiguous addresses.
  67.  
  68.     I largely followed the interpretation of Lennart Lovestrand in the 
  69.     processing of input addresses.  In particular in an address containing 
  70.     '@', '!' and '%', I gave '%' a higher precedence than '!' (unless the 
  71.     address originates at a UUCP source and STRICTLY822 is NOT defined).
  72.  
  73.     Thus the address  'c!u%b@a'  was converted to the internal form:
  74.         @a,  @b:  @c!  u   
  75.       (where the spacing is for readability, and <> are omitted).
  76.  
  77.     It is entirely possible that on some occasions this is incorrect, and the 
  78.     address should have been interpreted as:
  79.  
  80.         @a,  @c!  @b:  u
  81.  
  82.     I permitted sufficient residual ambiguity in many of the rulesets so that, 
  83.     when finally processed by ruleset 4, either of these internal forms would 
  84.     still finish up as  'c!u%b@a'  in the final output address. 
  85.  
  86. 4.  Ruleset #4.
  87.  
  88.     This ruleset is now in its fourth, and I hope final, rewrite.  In each of 
  89.     my earlier versions I made some attempt to limit the degree of ambiguity 
  90.     allowed in the resultant address.  But every approach had potential 
  91.     problems with eliminating some plausibly reasonable output address 
  92.     formats.  I finally concluded that S4 should be totally general, and the 
  93.     reduction of ambiguity should be handled in the mailer specific rulesets. 
  94.  
  95.     There is a down side to this complete generality.  It is theoretically 
  96.     possible to present an internal format address to ruleset #4, such that 
  97.     the output is completely uninterpretable.  I doubt that such addresses 
  98.     will arise naturally, and in any case the mailer specific rulesets are 
  99.     designed to eliminate most of the problems that could permit such 
  100.     addresses.
  101.  
  102.     About the only ambiguity I allowed to remain after the mailer specific 
  103.     rulesets is that between the precedence of '%' and '!' in a mixed address. 
  104.  
  105.     I allowed some residual ambiguity there because, as I commented above, the 
  106.     original assumptions when first parsing the input address may have been 
  107.     incorrect. 
  108.  
  109. 5.  Residual complexity. 
  110.  
  111.     Most of the remaining complexity is in rulesets #4, #7, #9, and #19.  
  112.     Complexity is unavoidable in rulesets #4, #7 and #9, which deal with 
  113.     conversion between internal and external forms. 
  114.  
  115.     The complexity of ruleset #19 is caused by the combination of two 
  116.     factors: my wish to retain full domain addresses as far as possible, 
  117.     replacing them by UUCP names only in ruleset #4; and my decision to fully 
  118.     follow the logic of the original IDA in using the UUCPXTABLE lookup as one 
  119.     criterion in the decision to continue conversion to ! formatting. 
  120.  
  121.     Actually ruleset #19 (and its continuation in ruleset #20, or was it #21) 
  122.     was one of the places where there was a logic error in the original IDA.  
  123.     It never really used UUCPXTABLE the way the documentation claimed.  I have 
  124.     a sneaking suspicion that all of the UUCPXTABLE dependent code in ruleset 
  125.     #19 should be eliminated, for the sake of a reduction in complexity.  Now 
  126.     that the unnecessary conversion back and forth between '!' and '%' formats 
  127.     is eliminated, the original need for this code has probably disappeared. 
  128.  
  129.