On Thu, 22 Mar 2007, John C Klensin wrote:
Question: The second paragraph of Section 3.5.3 has been rewritten slightly
for clarity and to note the parallelism between VRFY and RCPT. This should
be checked carefully by someone with experience actually using VRFY other than
me.
The only difference I can see is the case of the S in the cross-reference
to the discussion in section 2.1 (which is wrong - there seems to be no
such discussion). Perhaps the new text you are referring to is the extra
paragraph in section 7.3? It seems mostly sensible to me, though the last
few words point to an issue:
2821 contains the requirement (which isn't in 821) "Implementations
generally SHOULD be more aggressive about address verification in the case
of VRFY than in the case of RCPT, even if it takes a little longer to do
so" and the new paragraph reiterates it: "VRFY is expected to make a
serious attempt to determine validity before generating a response code
(see discussion above)."
I'd be surprised if any MTA implements this. It's been common since the
1990s to disable any verification by default to make it harder to perform
dictionary attacks, and section 7.3 endorses this. Some MTAs didn't
implement any SMTP-time verification at all, but this was a horrible
mistake: it's much cheaper to reject than to accept-and-bounce, and really
bad to emit backscatter to bogus return paths. VRFY is still usually
disabled even though it wouldn't provide any information to attackers. As
such, there's no point for MTA developers to add code to implement
aggressive verification for VRFY since it will almost never be used. Even
if VRFY is enabled it's practically never used so aggressive verification
will be poorly tested and a likely place to find bugs and vulnerabilities.
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
SOUTHEAST ICELAND: WESTERLY 3 OR 4, OCCASIONALLY 5. SLIGHT OR MODERATE. WINTRY
SHOWERS. GOOD.