--On Thursday, January 19, 2017 08:59 +0100 Heiko Schlittermann <[email protected]> wrote:
> Jeremy Harris <[email protected]> (Do 19 Jan 2017 01:03:37 CET): >> On 18/01/17 21:50, Heiko Schlittermann wrote: >> > Side note: we should have: >> > >> > --> MAIL FROM:<> >> > <-- 250 OK >> > --> VRFY [email protected] >> > <-- 250 OK [email protected] accepts mail from <> >> > --> QUIT >> > >> > This would avoid all that clumsy >> > sender-verification-de-impact hacks. >> >> We don't at present. In effect, both VRFY and EXPN are dead >> (though there is support for dealing with received ones). > > Yes, we don't and others don't do it. And unfortunenatly I'm > not in the position to to introduce it. But, OTOH if Postfix > and Exim would support it… (just dreaming) there would be a > good coverage. Just remember that, if one is planning to check three addresses, two of which turn out to be bad, use of VRFY without a mail session means C: VRFY [email protected] S: 550 no mailbox of that name C: VRFY [email protected] S: 250 OK [email protected] is valid C: VRFY [email protected] S: 550 no mailbox of that name While use in a mail session implies: C: MAIL FROM:<> S: 250 OK C: VRFY [email protected] S: 550 no mailbox of that name C: RSET S: 250 OK C: MAIL FROM:<> S: 250 OK C: VRFY [email protected] S: 250 OK [email protected] is valid C: VRFY [email protected] S: 550 no mailbox of that name C: RSET S: 250 OK Could be a fair amount of overhead for a small gain. Also, if one thinks that "VRFY <mailbox>" discloses information (the case that can be simulated with RCPT), then exposing the proposed sender name (or, more specifically, backward-pointing address) in a MAIL command and having the server explain what it will do with it also discloses that information. There are also some complex questions as to whether a server is ever permitted to refuse to accept mail with a backward-pointing address of "<>". Unless tied to either the identifying information in EHLO/HELO or the client's IP address, it would imply that the server never accepts bounce messages or MDNs of any sort. I have probably missed some cases, but think that would be a terrible practice and would certainly violate assorted assumptions of SMTP. So be careful about going there. > Does anybody remember, why VRFY isn't supported? 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. See my earlier note today. best, john -- ## 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/
