Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"KLENSIN@INFOODS.MIT.EDU"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Mon, 31 Aug 92 03:10:51 GMT
From:         Ned Freed <NED@INNOSOFT.COM>
Subject: RE: vrfy and expn commands
X-To:         KLENSIN@INFOODS.MIT.EDU, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

John Klensin writes:

>   -- A few versions of sendmail implement VRFY identicially to EXPN, i.e.,
> if you send them an address that points to a list, they pass back the
> list expansion.  PMDF has, if I recall, a little bit of this behavior
> relative to system aliases.

I believe that PMDF used to do this. However, the code was changed (maybe in
V4.0 but more probably in V4.1) to simply return information about whether or
not the given name is actually an alias. No expansion information is returned
by VRFY.

PMDF's VRFY is quite specific in talking about the nature of a given address;
this information is often a vital item in debugging. I don't think it is an
invasion of privacy or anything like that to know if a given mailbox name is
attached to a "file" or a "user mailbox" or a "local alias"; people read both
sorts of things and so do programs -- you cannot draw any real conclusions
about the nature of the readership from this information.

> As far as I can tell from RFC821, VRFY should
> be returning only one line of information that tells you whether the
> mail will be accepted for, and delivered to, that address by that SMTP
> server.  If that reading is correct, this is a bug, although rarely a
> serious one.

I think there was a bug in the past but it has been fixed.

>   -- RFC 1123 makes explicit provision for the cases in which it is
> not possible to fully verify an address because the SMTP server being
> addressed will have to gateway or relay the mail (section 5.2.3) and
> assigns a new code, 252, for that purpose.  My interpretation of the
> intent here is that PMDF should probably be returning 252, rather than
? 250, when there is a remote address that cannot be verified.  On the
> other hand, this is not what one would call a big deal.

It is a very good idea to have PMDF do this, and I have implemented such
a change for the next release.

>  -- VRFY is an RFC821 facility.  It really has no business knowing
> about personal names and should not be returning an address string that
> cannot appear in a RCPT TO command.  So, if an implementation of
> sendmail is returning personal names, that, too, is probably a bug or at
> least a serious mis-feature.

I would consider return of personal name information associated with an address
to be something of an invasion of privacy myself. In any case, PMDF simply does
not work this way. Personal names are associated with an address by a message
originator or list expansion; there is no personal name that's intrinsically
associated with a given mailbox specification.

PMDF's EXPN command also does not return personal name information. I think
this is a Good Thing since I for one use the personal name attached to mailing
list addresses to store information about the subscriber. I don't think anyone
has any business knowing this stuff. I also usually hide my lists behind an
alias so an outsider cannot get an expansion of the list, but that's another
story for another day.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU