----- Original Message -----
From: "Bruce Lilly" <blilly(_at_)verizon(_dot_)net>
To: <mail-ng(_at_)mail(_dot_)imc(_dot_)org>
Sent: Monday, February 23, 2004 4:18 PM
Subject: Re: user-visible goals
Doug Royer wrote:
And it sounds like it would be spammers heaven to test email addresses
before sending.
That is why most of us turn off SMTP's VRFY and EXPN.
I'm not so sure about that. Spammers don't seem to care whether would-be
recipient addresses are valid or not. They forge the sender envelope
address with
the result being that joe-job victims get all of the bounces. From the
user's
point of view, it would be better if VRFY worked. I.e.
I agree. The "harvesting" concept is to me a red-herring.
1) Using RCPT serves the same purpose as VRFY.
VRFY just saves a few extra command steps the client has to issue.
HELO mail.example.com
VRFY <address>
but the same can be achieved as so:
HELO mail.example.com
MAIL FROM: <whatever>
RCPT TO: <address>
2) Commercial spammer's product is the selling EMAIL addresses.
Systems did not not dynamically validate RCPT addresses at the smtp level
add more to the problem than help and they definitely add more pressure on
the network (move the burden to other systems).
A system that accepts it at RCPT with delayed DATA validation logic such as
done at YAHOO.COM is a perfect example.
It will perform the RCPT validation at the data stage, and as far as the
spammer is concern, it could careless if the email reaches the user or not.
The RCPT was "successful" from its point of view which puts more weight in
the selling or usage of this email address for potential customers.
Spammer: "We know this address will be accepted by Yahoo.com. Watch this."
HELO example.com
250 ok
MAIL FROM: <>
250 ok
RCPT TO: user(_at_)yahoo(_dot_)com
250 ok
QUIT
Spammer: "You see!! Its a good address! and we tested 3,000,000 yahoo addre
sses just like this!"
Customer: "Yes I see! Wow! But will the user get our ads?"
Spammer: We can't tell you if the mail will be delivered or not or whether
user will actually read it, but as you can see YAHOO.COM will accept the
address. Thats all we can provide to you."
Customer: "I'm sold!"
So systems need to validate recipients dynamically. If they delay it, that
only helps the spammer and in addition, and its a POST-SMTP delayed
validation it now puts the burden on the servers and network with bounces.
Also, consider the fact that all or any protocol level sender/machine
validation/authentication checking can be completely skipped if the
recipient is dynamically validation - "unknown user?" ---> skip all other
checking. no need to be done.
Dynamic Validation: RING RING
you: "Hello?"
caller: "Hi, May I speak to Tom?"
you: "Sorry, No Tom. Wrong Number."
caller: "ok, sorry."
caller: <click>
Post/Delay Validation: RING RING
you: "Hello?"
caller: "Hi, May I speak to Tom?"
you: "What about? Who is this?"
caller: "Robert, about some stuff."
you: "what stuff?"
caller: "stuff! Its personal."
you: "Listen, I am the man of this house. Its my phone! What stuff?"
caller: "Like I said. Its personal. May I speak to tom?"
you: "There is no Tom here so quit wasting my time! What stuff!"
caller: "Idiot! Why didn't you say so to begin with you a-hole!"
caller: <click>
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com