--On Thursday, January 19, 2017 08:59 +0100 Heiko Schlittermann
<hs@???> wrote:
> Jeremy Harris <jgh@???> (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 foo@???
>> > <-- 250 OK foo@??? 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 foo@???
S: 550 no mailbox of that name
C: VRFY bar@???
S: 250 OK bar@??? is valid
C: VRFY baz@???
S: 550 no mailbox of that name
While use in a mail session implies:
C: MAIL FROM:<>
S: 250 OK
C: VRFY foo@???
S: 550 no mailbox of that name
C: RSET
S: 250 OK
C: MAIL FROM:<>
S: 250 OK
C: VRFY bar@???
S: 250 OK bar@??? is valid
C: VRFY baz@???
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
