home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / mail / sendmail / 3037 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  3.2 KB
  1. Path: sparky!uunet!stanford.edu!apple!TIS.COM!avolio
  2. From: avolio@TIS.COM (Frederick M Avolio)
  3. Newsgroups: comp.mail.sendmail
  4. Subject: Re: "Standard" Behavior of $[ $] Syntax (?)
  5. Message-ID: <9212181548.AA07506@TIS.COM>
  6. Date: 18 Dec 92 15:48:42 GMT
  7. References: <1992Dec18.013900.16700@cfctech.cfc.com>
  8. Sender: daemon@Apple.COM
  9. Reply-To: avolio@TIS.COM
  10. Organization: Trusted Information Systems, Inc.
  11. Lines: 64
  12.  
  13. In article <1992Dec18.013900.16700@cfctech.cfc.com> kevin@cfctech.cfc.com (Kevin Darcy) writes:
  14. >Quick and simple question: on most sendmails which I've (reluctantly) 
  15. >configured, the $[ $] syntax will transform a partially-qualified name into 
  16. >an FQDN, e.g.
  17. >
  18. >foo.bar -> foo.bar.blech.com
  19. >
  20. >Is this behavior universal enough to be considered part of the de facto
  21. >sendmail "standard"? I have an implementation of sendmail, from a vendor who 
  22. >shall remain nameless, where the $[ $] syntax will ONLY translate CNAMEs into 
  23. >their canonical counterparts; it passes partially-qualified names through
  24. >untouched. This is highly inconvenient, but, not being a sendmail expert, I'm 
  25. >unsure whether to actually call it "broken"... 
  26.  
  27. I have also seen both behaviors (and am pretty sure I know who the
  28. unnamed vendor is).  The behavior is that it rewrites the address only
  29. for a CNAME (or if the thing between the $[ and $] is an IP address,
  30. e.g. 192.5.214.10)
  31.  
  32. What you want to do is use the DNS's support for partially qualified
  33. names, or "relative addresses", in sending mail.  This is NOT a good
  34. thing to do. There are three main reasons, keeping in mind that using
  35. a relative address is habit-forming:
  36.  
  37. 1. Relative addresses are.. well... relative.  They change with
  38. location.  If you are sitting on host foo.det.dec.com and send mail to
  39. user@gatekeeper it might go to "user" on "gatekeeper.dec.com" because
  40. the resolver tried "gatekeeper.det.dec.com" (gatekeeper.LOCALDOMAIN)
  41. and then tried one level up, and found it.  But move to Maryland and
  42. be on foo.dco.dec.com and send the same mail and it might go to "user"
  43. on "gatekeeper.dco.dec.com" -- a different user.
  44.  
  45. 2. Relative addresses may become ambiguous.  User 1 is
  46. "mary@alpha.cs.umd.edu" and user 2 is "joe@beta.ee.umd.edu".  Joe
  47. sends mail to mary as: "mary@alpha.cs" and it works.  But if someone
  48. on "beta.ee.umd.edu" wants to send mail to a user on a system in
  49. Czechoslovakia (.cs) he is out of luck.  There are numerous ways
  50. around this, but all require knowledge or how the MTA is going to act
  51. and this changes site to site.
  52.  
  53. 3. Relative addressing does not carry to the top-level.  Logically, I
  54. (avolio@tis.com) should be able to send mail to a friend Allen
  55. (allen@det.dec.com) to "allen@det.dec" seeing as how we both share the
  56. same top-level (.com).  This does not work.
  57.  
  58. One should configure sendmail to:
  59.  
  60. a. rewrite any address $*@$- to tack on the local domain (the only
  61. definition possible).
  62.  
  63. b. leave everything else alone.
  64.  
  65. This means that relative addresses will work (since the DNS will do
  66. what was dscribed above) but are discouraged.  One *could* put a
  67. trailing dot on, as in:
  68.  
  69. R$*@$-        $1@$2.MYDOMAIN
  70. R$*@$+        $:$1@$2.        note addding trailing blank
  71.  
  72. which would disallow relative addresses (treating every addresses as
  73. rooted) but I'd chose not to bother.
  74.  
  75. Fred
  76.  
  77.