----- Original Message -----
From: "wayne" <wayne(_at_)midwestcs(_dot_)com>
To: "SPF discussions" <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Sunday, February 15, 2004 7:18 PM
Subject: Re: [spf-discuss] A couple of thoughts
In <200402151756(_dot_)I1FHUVEU094818(_at_)asarian-host(_dot_)net> Mark
<admin(_at_)asarian-host(_dot_)net> writes:
On the other hand, RCPT TO: is guaranteed to always work (which, if you
think about it, kinda defeats the purpose of disallowing VRFY, as the
same info can be obtained through using RCPT TO:).
MAIL FROM:<>/RCPT TO:<test> is not guaranteed to always work. Many
mailers say "ok" to every RCPT TO: command. Some will delay the error
code for until a data command is issued (I think Yahoo does this),
others will simply accept and create a bounce message.
With "guaranteed to always work" I meant, of course, that the command,
unlike VRFY, is always available -- not per se that you will get a useful
result. Like with the catchall example I gave, you could always get an "Ok"
for every recipient, both on RCPT TO: and VRFY; but that has more to do with
the underlying MTA's policy of what is considered a valid recipient on the
system, and does not really pertain to the SMTP protocol itself.
However, your point of being silly to disable the VRFY command when it
is so easy to simulate is on target. There really isn't any reason to
disable it. On the other hand, since it is so easy to simulate, there
really isn't any reason for people to use it.
It is definitely useful to disable EXPN. Keeping VRFY disabled, while its
function can be easily simulated, could still be considered useful, in that
no Milter callback exists for VRFY, whereas one exists for the RCPT TO:
callback.
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx