Message-Id: <199512070203.UAA01248@jean-baptiste.internetMCI.ietf.org>
To: Robert Elz <kre@munnari.oz.au>
From: Eric Allman <eric@reference.com>
cc: Harald.T.Alvestrand@uninett.no, drums@cs.utk.edu
Subject: Re: My opinion on VRFY 
In-reply-to: Mail from Robert Elz <kre@munnari.OZ.AU> 
	dated Thu, 07 Dec 1995 07:51:29 +1100
	<4407.818283089@munnari.OZ.AU> 
Date: Wed, 06 Dec 1995 20:03:45 -0600
Sender: eric@CS.Berkeley.EDU

Re:
: From:  Robert Elz <kre@munnari.OZ.AU>
: Subject:  Re: My opinion on VRFY 
: Date:  Thu, 07 Dec 1995 07:51:29 +1100

:     Date:        Wed, 06 Dec 1995 09:22:41 -0600
:     From:        Eric Allman <eric@reference.com>
:     Message-ID:  <199512061522.JAA00932@jean-baptiste.internetMCI.ietf.org>
: 
:     Can you suggest a way to word the spec ..
: 
: I will look at this after I get home.

Perhaps I was being too tongue-in-cheek.  I don't believe that a
reasonable wording exists that will incorporate what I think people
think they want without being a big mess.

:     Or are you suggesting an algorithm along the line of:
:     
:     if owner-X exists
:     	verify owner-X
:     else
:     	for all members of X
:     	    verify the member
: 
: Yes.   Exactly that.
:     
:     If so, this is still an unbounded algorithm
: 
: Yes.    Maybe it would be sufficient to test that one address
: is valid, pick one at random, I'm not sure.  I would like to think
: that the better test is "can I send to here without having mail
: bounce to me", for which the owner-alias in sendmail is the check,
: but perhaps having one valid address, so I can send and have mail
: delivered to at least soemone is enough?

In which case you really want

	foreach i in members(list)
		if is ok
			return ok
	return failure

This is still technically unbounded, but the bad case only occurs
when there are many members of the list, all of which are bad.  I
still like guarantees, but as long as the wording doesn't insist
upon both a guarantee and this algorithm it can probably fly.

:     I claim that if the point is to verify that an address is plausible
:     (e.g., when it is being added to a mailing list or used in an HTTP
:     transaction) then the current sendmail algorithm is sufficient.
: 
: The problem is that may users have old addresses at various places
: implemented by way of alias entries.   If simply testing the alias
: is sufficient, those will all generate "ok".  However, many have
: the alias point into oblivion - when asked to fix that, the admin of
: the aliases file usually simply deletes the alias (no idea what to
: change it to), which is reasonable.  Thus verification of existance
: of an alias itself is really verification of nothing.

I'm a bit confused about this.  Let's take some cases.  All of these
are going to assume that there is no owner-alias, since it's only
simple aliases that have the problem, as I understand it.

  CASE 1:	alias:  bogususer
		alias:	user@bogushost
	This is the "worst case" for sendmail, since it could just
	expand the alias and find the problem in the VRFY.  However,
	any attempt to send will give a bounce; no mail will be lost,
	and the problem will probably be fixed quickly.

  CASE 2:	alias:	bogususer@goodhost
	Unless VRFY is going to become recursive, this won't be
	detected in any case.  VRFY could be modified to detect this
	situation though, as John suggested during the WG meeting.

  CASE 3:	alias:	good1, good2, ... good2323, bogus, good2324, ...
	Probably the most common case, but detecting it in VRFY gets
	us back into the unbounded algorithm case.

I suppose we could come up with some arbitrary limit (``if an alias
has more than N members, use this other algorithm'') but that sounds
like user astonishment time (and what is N?).

:     I don't understand this.  You seem to be saying that all UUCP addresses
:     will verify bad.  Although John Myers might agree with this, I suspect
:     many others might disagree.
: 
: No.  Perhaps I picked the wrong code, I meant that the mailer
: shoudl reply "I am not going to do that verification", which is
: one of the possible responses, "address is good", "address is bad",
: "I refuse to say one way or the other".   If the address is
: someplace out where we have no idea, and cannot tell, whether
: the address is OK or not, saying either yes or no seems wrong to
: me, we should just say "don't know" (ie: "I won't say").

You're thinking of 252.  I don't have any problem with that.

: We could use that approach for the big alias problem too, any
: implementation woudl be free to decide that verifying this address
: is too much work to do, and simply refuse.

Hmmmm.....    I'm still not wild about it, since about the best you
can do is set a timeout and if you can't figure it out in that
interval, give a 252.

: kre

eric