It would help if you specify the version of Exchange you think is
non-compliant.
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
5.0.1457.7 ready
helo lumberjack
250 OK
help
214-Commands:
214- HELO MAIL RCPT DATA RSET
214- NOOP QUIT HELP VRFY XAUTH
214- XEXCH50
214 End of HELP info
vrfy
501 Syntax Error
vrfy awebb @
swinc .
com
252 Cannot verify user
=======================================================
Andy Webb awebb @
swinc .
com www.swinc.com
Simpler-Webb, Inc. Austin, TX
512-322-0071
"Mauve has more RAM" - Dilbert
=======================================================
> -----Original Message-----
> From: Ned Freed [SMTP:Ned .
Freed @
innosoft .
com]
> Sent: Sunday, September 21, 1997 1:39 PM
> To: firewalls @
GreatCircle .
COM
> Cc: Ned .
Freed @
innosoft .
com
> 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
> minimum
> > > > 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
> standards
> 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
> incorrect.
>
> Second, implementations which do not want to support VRFY for security
> reasons
> (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
> determination
> of an associated mailbox that the name of that mailbox be returned in
> the
> 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
> response.
> Many implementations are deficient in this regard.
>
> Fifth, current standards do not specify exactly what response is to be
> returned
> 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
> valid
> argument is given. However, one could also argue that a "500 command
> disabled"
> 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
> should
> 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
> "502
> command not implemented" response to VRFY doesn't comply with the
> standards.
> These responses were legal in RFC821 but were made illegal by
> RFC1123.
> (Microsoft Exchange falls into this category, BTW.)
> (2) An implementation that returns 252 for all syntactically valid
> arguments
> without doing any check is acting within both the letter and
> intent of the
> standards.
> (3) An implementation that returns a "503 command disabled" error is
> arguably
> 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
> out
> 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
> point,
> 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.
>
>
> Ned
Follow-Ups:
|
|
