Message-Id: <199512061522.JAA00932@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 Wed, 06 Dec 1995 15:59:14 +1100
	<4306.818225954@munnari.OZ.AU> 
Date: Wed, 06 Dec 1995 09:22:41 -0600
Sender: eric@CS.Berkeley.EDU

Re:
: From:  Robert Elz <kre@munnari.OZ.AU>
: Subject:  Re: My opinion on VRFY 
: Date:  Wed, 06 Dec 1995 15:59:14 +1100

: 
:     Also, VRFY should be fast,
: 
: For any reasonable use I can imagine, I don't see why this needs to
: be true.   It shouldn't be horribly slow, but "fast" I don't
: need (minutes is probably OK, hours not).

OK, I agree.  Can you suggest a way to word the spec (and implement)
the semantics that say "you should expand aliases as long as there
aren't too many aliases, and check the address very carefully unless
this is going to take too long"?

I have no problem with limits like the 5 minute RCPT timeout, because
I can easily determine that that lets me do a worst-case DNS lookup,
check the local hashed password file, etc.  But if you want it to do
as much as it can for 15 minutes, and if it hasn't been able to finish
by then return a "maybe this address is ok" response, well, I have a
somewhat different reaction.

:     The way sendmail handles this right now is to treat VRFY as a check
:     to see if the address is valid.
: 
: This is good.
: 
:     If it is an alias, it checks to see if the alias exists
:     (but does not attempt to expand the contents of that alias).
: 
: This may not be enough, but (for sendmail specific semantics),
: I'd be happy if the alias exists, and owner-alias exiss, and that
: passes the verify checks (recursively).   that should be faster
: tahn checking the alias expansion in most cases, and good enough
: to know that mail will get somewhere.   Large aliases will usually
: have an owner-alias - small ones can have their addresses tested
: by a VRFY at the destination (if needed).

Some aliases don't have owner-aliases.  I don't see what this buys you.
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

If so, this is still an unbounded algorithm -- that is, someone might
be stupid enough to have a 1000 member list without an owner-alias.
It is nice to have some guarantees.

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.  If
the point is to verify that the members of the list are correct,
then EXPN is the correct tool.

:     If it is a real user, it looks that user up in the
:     passwd file (but does not open or expand .forward files).
: 
: That's reasonable, it at least demonstrates the user exists.
: There's no way to know for sure mail will be deliverable later -
: the mail filesystem might be full.

Correct.  And of course, any good address can become bad with time;
that's just part of the game.

:     I'm going to make the possibly contentious suggestion that what sendmail
:     does now is correct and that specifications of VRFY that require it to
:     take potentially unbounded time would be in error.
: 
: Almost, as above.
: 
: I would also explicitly check for an address that is rewritten into
: a mailer that is not "clever" (sendmailese) and hence does not have
: any standard way of address verification you can use (eg: uucp,
: but anything !local, !clever) and return the  550 or something
: to indicate verify failed.

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.

: Mailers other than sendmail should do the equivalent.
: 
: kre

eric