On Mon, 16 Jul 2007, Robert A. Rosenberg wrote:
At 15:08 -0400 on 07/15/2007, John C Klensin wrote about Re:
draft-klensin-rfc2821bis-04: VRFY and EXPN syntax:
Partially because of the circumlocutions and security consideration issues,
there is a lot of text about VRFY and EXPN in 2821bis.
If I may put in my 2 cents, I'd like to hopefully see some comments
about the security issues in using VRFY and EXPN in the security section
(if they are not already there) as well
Didn't believe John when he said "a lot of text", eh? Your worries should
have been assuaged by a glance a the table of contents of
draft-klensin-rfc2821bis-04.txt:
7. Security Considerations . . . . . . . . . . . . . . . . . . . 76
7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . . 76
7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . . 77
7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . . 78
...
as an EXPLICATE MUST that the
EHLO reply ONLY list them if they have not been turned off (IOW: If you
are going to reject them or send a "Send Me A massage" reply to an
attempt to VRFY then do not advertise support for them in the first
place).
I disagree.
Can you give some reason for treating the EXPN and VRFY service extensions
any differently than other extensions?
Can you give some justification for specifying "MUST NOT list unless
supported" instead of SHOULD NOT? What critical interoperability problems
occur when that isn't followed? Given that there are legitimate reasons
for a VRFY or EXPN to fail even when it is supported, or perhaps to fail
for some but not all arguments, I fail to see the benefit of attempting to
tighten this requirement.
Philip Guenther