[Top] [All Lists]

Re: RFC2821bis-01 Issue 2: VRFY/EXPN

2007-03-29 08:55:17

As yet, there has been no discussion on this issue.

Any comments?

First, a comment about the security considerations relevant to the use of
251/551 responses. Section 7.6 discusses the potential for such codes to
disclose potentially sensitive information. However, the section does not
mention the issue that arises when a client actually does use 251/551 "address
update" information to affect future behavior. When this is done a MITM attack
can be used to force a bogus update the redirect all future mail to a given
address to whereever the attacker wants it to go. As such, 251/551
auto-updating by clients should only be used in circumstances where the
server's authenticity can somehow be verified. This probably should be
mentioned in section 3.4 as well as 7.6.

Now, as for 3.5.3, the VRFY/EXPN situation is another case where things vary
depending on whether you're operating insde an administrative domain versus
between administrative domains. The main use I've seen VRFY and EXPN used for
of late is to perform internal audits of how email gets routed to check and
make sure nobody is autoforwarding sensitive mail outside the organization. To
this end I've actually seen requirements that VRFY/EXPN not be disabled and
disabling them is considered to be a serious violation of the rules that could
get somebody fired. But the situation reverses when you talk about them being
enabled for use outside the domain - their use can expose sensitivie
information so the same places that require they be enabled internally may also
require disabling all external access.

I don't insist on describing this sort of usage in the document but I don't
think it would hurt. The last recommendation of the section - that VRFY should
"try harder" than RCPT TO - makes a heck of a lot more sense when you consider
it in the light of this usage.