--On Thursday, January 19, 2017 09:59 +0000 Jeremy Harris
<jgh@???> wrote:
>>> I do not see anything
>>> that is more risky there than RCPT TO. (Given current ACL
>>> capabilities.) And in combination with the enforcement of a
>>> preceeding MAIL FROM it even makes some sense to me.
>
> Oddly enough, rfc 2821 says that VRFY SHOULD be usable even
> without an EHLO let alone a MAIL. (section 4.1.4)
> This because it is a non-mail command.
>
> I need to read through the later ESMTP spec rfcs.
Not a bad idea, because there are some changes from 2821, but,
IIR, none of them are in this area. I do strongly suggest that
anyone wanting to continue this thread read Section 7.3 (and
probably 3.5) of RFC 5321 -- we are sliding into questions that
are answered there.
The specific reasons for making it a non-mail command were, IIR,
(1) There is nothing about it that requires the sending address
identification of the MAIL command or even the host
identification of EHLO.
(2) If one adopts the "check all the addresses before trying to
send" model (see my previous long note), getting back a negative
(error) reply from VRFY would terminate the mail session anyway
In addition, to clear up a few other questions / comments in
this thread:
(3) If VRFY is implemented as specified by RFC 5321 (and 2821
and 821), the client can send it with a user name (however the
server defines that) rather than a mailbox and, if the user
exists, get the mailbox back. Whether supporting that option is
wise or not from a security or privacy standpoint is debatable.
That is a feature that, for obvious reasons, is not supported by
RCPT, so, in principle, the statement that any attack that can
be made with VRFY can also be made with RCPT is false. I
haven't done the research, but assume use without a mailbox
could be supported in EXIM with an appropriate acl. Personally,
I've not felt a desire to turn it on since before EXIM was first
written.
(4) The last paragraph of Section 3.5.2 of RFC 5321 explains why
it is not required to list VRFY in an EHLO response even when it
is supported. I would, however, suggest that it should be
listed ("as a convenience") when it is turned on, especially in
an implementation that allows turning it off.
best,
john
