home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / vmsnet / mail / pmdf / 2196 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  2.9 KB
  1. Path: sparky!uunet!olivea!decwrl!decwrl!infopiz!mccall!ipmdf-newsgate!list
  2. From: klensin@infoods.mit.edu (John C Klensin)
  3. Newsgroups: vmsnet.mail.pmdf
  4. Subject: RE:  vrfy and expn commands
  5. Message-ID: <714828497.685166.KLENSIN@INFOODS.MIT.EDU>
  6. Date: 26 Aug 92 11:28:17 GMT
  7. Organization: The Internet
  8. Lines: 37
  9. Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
  10. Resent-Date: 26 Aug 1992 07:28:17 -0400 (EDT)
  11. Resent-From: epmdf@YMIR.CLAREMONT.EDU
  12. In-Reply-To: <01GO147QXUN48Y5AVL@biel.be.tech.ascom.ch>
  13. CC: info-pmdf@YMIR.CLAREMONT.EDU
  14. Errors-To: epmdf@YMIR.CLAREMONT.EDU
  15. Resent-Message-ID: <01GO0W4DPNO295NWAQ@YMIR.CLAREMONT.EDU>
  16. X-Vms-To: IN%"WITTWER@tech.ascom.ch"
  17. X-Vms-Cc: IN%"info-pmdf@YMIR.CLAREMONT.EDU"
  18. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  19. Content-Transfer-Encoding: 7BIT
  20. Mail-System-Version: <VAX-MM(312)+TOPSLIB(155)+PMDF(4.1)@INFOODS.MIT.EDU>
  21.  
  22. Fritz,
  23.   To add a bit to Ned's (correct) answer...
  24.   -- Many versions of sendmail "implement" VRFY and EXPN identically
  25. and, in both cases, simply do a syntax check.  In other words, if you
  26. send "VRFY foo@bar" you get back "<foo@bar>" for any instance of "foo"
  27. and "bar".  This behavior is broken, even if the "sendmail is the real
  28. standard" community thinks otherwise.
  29.   -- A few versions of sendmail implement VRFY identicially to EXPN, i.e.,
  30. if you send them an address that points to a list, they pass back the
  31. list expansion.  PMDF has, if I recall, a little bit of this behavior
  32. relative to system aliases.  As far as I can tell from RFC821, VRFY should
  33. be returning only one line of information that tells you whether the
  34. mail will be accepted for, and delivered to, that address by that SMTP
  35. server.  If that reading is correct, this is a bug, although rarely a
  36. serious one.
  37.   -- RFC 1123 makes explicit provision for the cases in which it is
  38. not possible to fully verify an address because the SMTP server being
  39. addressed will have to gateway or relay the mail (section 5.2.3) and
  40. assigns a new code, 252, for that purpose.  My interpretation of the
  41. intent here is that PMDF should probably be returning 252, rather than
  42. 250, when there is a remote address that cannot be verified.  On the
  43. other hand, this is not what one would call a big deal.
  44.   -- VRFY is an RFC821 facility.  It really has no business knowing
  45. about personal names and should not be returning an address string that
  46. cannot appear in a RCPT TO command.  So, if an implementation of
  47. sendmail is returning personal names, that, too, is probably a bug or at
  48. least a serious mis-feature.
  49.   -- 250 is documented in RFC821
  50.  
  51. It is quite unfortunate, but the version of sendmail that has
  52. traditionally been shipped with SUN OS, together with the default config
  53. files shipped with it, are seriously broken and not suitable for use
  54. with Internet mail.  Anyone who wants to think of that as "the standard"
  55. should get used to communicating only with other Suns, and only over
  56. LANs and considering themselves very fortunate when anything else works.
  57.  
  58.       john
  59.