It would help if you specify the version of Exchange you think is
With 5.0 and 5.0 SP1, VRFY is by default disabled and returns a 252
Cannot Verify User response. Sounds like it's correct. The 5.5 preview
release also behaves this way. I can't find a 4.0 server to test
against anymore though.
220 grail.austin.swinc.com Microsoft Exchange Internet Mail Service
214- HELO MAIL RCPT DATA RSET
214- NOOP QUIT HELP VRFY XAUTH
214 End of HELP info
501 Syntax Error
vrfy awebb @
252 Cannot verify user
Andy Webb awebb @
Simpler-Webb, Inc. Austin, TX
"Mauve has more RAM" - Dilbert
> -----Original Message-----
> From: Ned Freed [SMTP:Ned .
> Sent: Sunday, September 21, 1997 1:39 PM
> To: firewalls @
> Cc: Ned .
> Subject: SMTP VRFY (was: Microsoft vs The world)
> > > > 2. exchange does not implement VRFY correctly. any username at
> any host
> > > > receives the reply: "OK". VRFY is not included in the
> > > > implementation, but if included must work according to spec.
> > > This one happens to be firewall related...
> > > microsoft chose to implement the VRFY command and ignore the spec.
> > > this behavior is not uncommon in microsoft products.
> > > G*D... I NEVER thought I would EVER defend Microsoft on ANYTHING
> > > but you just can not lay this one at their door. There are
> several other
> > VRFY is *not* part of the "required minimum".
> > if microsoft or IBM wish to disable it, that's fine.
> > options are optional.
> > but do *not* claim to implement a function that is not implemented.
> Unfortunately almost all of this is wrong insofar as current Internet
> are concerned.
> First of all, VRFY *is* part of the required minimum command set of
> SMTP. As
> such, any firewall which fails to implement it is incompliant with the
> standards. So the claim that implementation of VRFY is optional is
> Second, implementations which do not want to support VRFY for security
> (whether real or fanciful) are allowed to disable the command.
> Third, not only is it permissible to not check the argument to VRFY to
> see if
> it respresents a valid user, a response code of 252 is specifically
> defined for
> this purpose. So the claim that if VRFY is implemented it has to
> actually check
> its argument is also incorrect.
> In particular, RFC1123 says:
> 5.2.3 VRFY and EXPN Commands: RFC-821 Section 3.3
> A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN
> (this requirement overrides RFC-821). However, there MAY be
> configuration information to disable VRFY and EXPN in a
> particular installation; this might even allow EXPN to be
> disabled for selected lists.
> A new reply code is defined for the VRFY command:
> 252 Cannot VRFY user (e.g., info is not local), but will
> take message for this user and attempt delivery.
> Fourth, the standards require that in the event of a successful
> of an associated mailbox that the name of that mailbox be returned in
> response. That is, if the argument to VRFY is a valid username with an
> associated mailbox the name of that mailbox has to be returned in the
> Many implementations are deficient in this regard.
> Fifth, current standards do not specify exactly what response is to be
> when VRFY is disabled. One can read a strong implication into the
> language that
> is there that 252 should just be returned whenever a syntatically
> argument is given. However, one could also argue that a "500 command
> response would be acceptable.
> Sixth, this mess is cleaned up the DRUMS update to RFC821/RFC1123. In
> particular, the ambiguity about what a server with VRFY disabled
> do is removed -- it has to return 252.
> So what does all this mean? It means that:
> (1) An implementation that returns a "500 command not recognized" or a
> command not implemented" response to VRFY doesn't comply with the
> These responses were legal in RFC821 but were made illegal by
> (Microsoft Exchange falls into this category, BTW.)
> (2) An implementation that returns 252 for all syntactically valid
> without doing any check is acting within both the letter and
> intent of the
> (3) An implementation that returns a "503 command disabled" error is
> operating within the limits of acceptable behavior now, but will
> not be
> in the future.
> Now, this may seem like a largely academic issue -- after all, who
> uses VRFY
> anyway? The answer, however, is that there are in fact implementations
> there that use VRFY as a component of their SMTP dialogues. (I think
> such usage
> is dumb, but that doesn't make it go away.) And perhaps more to the
> broken handling of VRFY all too often equates with broken handling of
> SMTP in
> general. And given how simple even extended SMTP is, this just doesn't
> wash in
> the present-day Internet.