Message-ID: <35DBA537.A00F170E@to.sel.fujitsu.co.jp>
Date: Thu, 20 Aug 1998 13:25:27 +0900
From: Antony Bowesman <adb@to.sel.fujitsu.co.jp>
MIME-Version: 1.0
To: Norbert Bollow <nb@thinkcoach.com>
CC: drums@cs.utk.edu
Subject: Re: VRFY clarification - Revised proposed text
References: <199808200431.GAA00907@quill>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Norbert Bollow wrote:
> 
> Antony Bowesman <adb@to.sel.fujitsu.co.jp> wrote:
> 
> > In your proposed text the following:-
> >
> > > ! The information in such a directory server or
> > > ! database SHOULD be updated immediately after the set of valid addresses
> > > ! has changed in any way,
> >
> > is outside the scope of the draft.
> 
> I don't think so, since this is a paragraph which which talks about
> the possibility of a directory server or database which contains the
> information for VRFY responses, and hence it is completely within of
> the scope of the draft to say something about how it should be kept
> in sync with the set of valid addresses. Here is the complete paragraph:
> 
> ! The VRFY command MAY be implemented by making a query to some kind of
> ! directory server or database, but even then there MUST be appropriate
> ! means of ensuring that the server will never generate a 5xx response
> ! for a valid address. The information in such a directory server or
> ! database SHOULD be updated immediately after the set of valid addresses
> ! has changed in any way, and the server MAY always generate 252
> ! responses to VRFY commands until the update is finished.

My point was that it is acceptable if the SMTP implementation makes
queries to some kind of directory but I expect in almost all cases it's
not appropriate for it to pump directory entries back to it.  Perhaps I
misunderstand the context but how is the SMTP server supposed to detect
a change to an address if that change did not already come from the
directory service.

> If several DRUMS WG participants are not comfortable with this paragraph,
> the best solution will be to get rid of the entire paragraph and resolve
> the VRFY issue without it.

I would prefer the para removed.  Your changes (and others') have given
acceptable versions to move forward and I think this introduces
unnecessary complications which will not add to VRFY implementation. 
Implementors will have to make their own decisions on how best to
support a genuine VRFY response.

> 
> May blessings from the eternal God surprise and overtake you!

I missed them.

Antony Bowesman
adb@to.sel.fujitsu.co.jp