--On Sunday, January 15, 2017 6:51 PM +0100 Luca Bertoncello
<lucabert@???> wrote:
> Then to my problem...
> OK, now I know why Exim answer the commands and that they are
> NOT enabled.
>
> Am I right to say that there are NO security issue in my Exim
> (4.88) regarding VRFY and EXPN?
Let me try to save Jeremy time and tell you more than you may
want to know.
There is never a security issue from having then not enabled.
They do provide some capabilities that are occasionally useful.
VRFY poses little security risk other than a slightly increased
risk of DoS attacks and some ability to build lists of valid
addresses (either can be done with RCPT instead). There is
another issue with VRFY which is that the standard permits
either of both of
C: VRFY Luca Bertoncello
S: 250 lucabert@???
(i.e., obtaining an email address given a name) or
C: VRFY Doe
S: 250- janedoe@???
S: 250- johndoe@???
S: 250 joe@???
(i.e., taking an ambiguous query and supplying all the addresses
that might match).
I'm not interested in debating whether the above are
unacceptable privacy and/or security issues, but they are
probably among the reasons why vRFY is rarely implemented that
way any more (including, IIR, by EXIM).
VRFY has one other use, which is alluded to in the documentation
section to which Jeremy pointed. Suppose is have a message
intended for several addresses and I don't care if some of them
don't go through. SMTP is fairly clear (I hope) that, if RCPT
is sent and a 5yz code comes back. it is essentially the end of
the mail transaction -- about all the client is allowed to do
after that is to send QUIT or RSET. So the theory is that, for
three destination addresses, one sends
VRFY address1
VRFY address2
VRFY address3
Then, if addresses 1 and 3 look ok, one sends
RCPT address1
RFCP address3
DATA
blah blan blan
.
Gets 2yz replies to each command, and then tells the sender that
everything was ok except that the the message didn't go to
address2 because it was bogus. There are lots of problems with
that approach, but that is the theory.
.
EXPN is more problematic because, if implemented as specified/
intended, it will disclose the addresses on a mailing list.
Today's general consensus is that mailing list membership and
addresses should be disclosed either only to those on the
mailing list or not at all and hence that EXPN should be
disabled or, if not, implemented in a way that cripples its
functionality.
At the time it was first specified, there was also a theory
floating around that the best way to do distribution lists for
at least some purposes was to ask a remote server, via EXPN, to
whom a message should be distributed and then send it to each of
the recipients from the original submission MTA. I'm not aware
of anything that still tried to do things that way although,
oddly, it would actually have some advantages if one were trying
to strongly authenticate a message originator or message content.
Does that answer your question?
john
Disclaimer: I rarely try to give official interpretations of
SMTP or the reasoning behind it. If I do, I will say so. The
above message does not. If you don't know why I feel obligated
to say that sometimes, don't worry about it.
