Re: user-visible goals
"Hector Santos" <[email protected]> Mon, 23 Feb 2004 17:57:17 -0500
| Newsgroups | gmane.mail.ng |
|---|---|
| Organization | Santronics Software, Inc |
| Message-ID | <00e601c3fa60$d50d5110$6401a8c0@FAMILY> |
----- Original Message ----- From: "Bruce Lilly" <[email protected]> To: <[email protected]> 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: [email protected] 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