--On Sunday, January 15, 2017 6:51 PM +0100 Luca Bertoncello <[email protected]> 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 [email protected] (i.e., obtaining an email address given a name) or C: VRFY Doe S: 250- [email protected] S: 250- [email protected] S: 250 [email protected] (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. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
