Re: [exim] SMTP VRFY (was: gotcha: chunking and predata)

Pàgina inicial
Delete this message
Reply to this message
Autor: John C Klensin
Data:  
A: Heiko Schlittermann, exim-users
Assumpte: Re: [exim] SMTP VRFY (was: gotcha: chunking and predata)

--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