----- Original Message -----
From: "Brett Watson" <famous-asrg(_at_)nutters(_dot_)org>
To: <asrg(_at_)ietf(_dot_)org>
Sent: Monday, December 01, 2003 2:54 AM
Subject: Re: [Asrg] 0. General - anti-harvesting (was Inquiry about CallerID
Verification)
So do we suggest that VRFY ought to be revived as a return-path validity
checker? Does this benefit outweigh the disadvantages for which VRFY has
been
depreciated in the first place?
Or am I misunderstanding this argument?
No, you got it. And you raise a very excellent possible solution which I
like because it doesn't technically change the SMTP protocol. It now
becomes a functional requirement.
Lets put a version number of the NEXT SMTP system. V2.0
For ESMTP V2.0 Servers:
Compliant servers must support VRFY as a way to validate return address.
With modern systems, RCPT TO: is basically doing the same thing. The
difference VRFY is not required to be issued in any specific order and it
doesn't occur any internal server logic to remember a RCPT TO: list. So
VRFY is the prefer method as a low overhead verification.
For ESMTP V2.0 Clients:
It can use a RCPT TO: only as a fallback if VRFY fails as a "command not
understood"
The beauty of this is that most systems already support VRFY but have it OFF
by default. So it is just a simple matter of the sysop turning it on.
We can certainly extend this in many ways. But by using this method, the
SMTP protocol itself does not need to change. Only the specifications need
to be make it clear in writing that the return path must be valid. If it
isn't valid, the is up to the server implementation to decide what to do
with it. But we can't just leave it in a "limbo" that suggests in any way
that it is may be unreachable, therefore no action should be taken that
prohibit this possibility.
I vote to "re-institute" the VRFY command as recommended requirement for
ESMTP V2.0 Protocols designs.
The argument about harvesting is a non-issue.
- Most systems offer dynamic validation with RCPT TO:
- Some might delay it to the DATA stage, but it still done (YAHOO)
- Systems that delay with gateway software will try to BOUNCE the message.
If no bounce is reached by the spammers, then he has learned that the
address is "ACCEPTABLE."
- Systems that delay with gateway software bouncing the message to a
unreachable site, well, this only means this type of spammer didn't care in
the FIRST place if the address was acceptable or not. He was just throwing
darts on the wall. If some stuck, GREAT. If not, still GREAT. From his
stand point, his SPAM SOFTWARE completed it job (throwing darts) of sending
mail to anyone who would accept it. Who cares if it was actually by a user
or not. He will find out when the user reads his mail using html
references.
So in ALL cases, it is a non-issue.
I vote for VRFY to be part of the next specs!
Thanks Brett!
---
Hector Santos, CTO
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg