Tool for validating sender address as spam-fighting technique?

[Chad Leigh -- Shire.Net LLC]

On Mar 13, 2007, at 9:30 PM, Christopher Sean Hilton wrote:

> Chad Leigh -- Shire.Net LLC wrote:
>> On Mar 13, 2007, at 6:00 PM, Christopher Sean Hilton wrote:
>>> On Mon, 2007-03-12 at 12:00 -0400, Marcelo Maraboli wrote:
>>>
>>>>
>>>> I agree..... callbacks are not enough, you can reach a
>>>> false conclusion, that´s why I use SPF along with callbacks...
>>>>
>>>> on the same message, my MX concludes:
>>>>
>>>> "you are sending email "from chad at shire.net", but shire.net
>>>> says YOUR IP address is not allowed to send email on behalf
>>>> of that domain, therefore YOU ARE FAKE/FORGED" ..---> reject
>>>>
>>>> regards,
>>>>
>>>
>>> I'm not sure what you mean by callbacks but if that involves  
>>> talking to
>>> mx.example.com and trying to figure out if  
>>> cmdr.sinclair at example.com is
>>> a valid address go ahead. I would consider a mailserver that answers
>>> that question a security risk as it is freely giving away  
>>> information
>>> about your domain without notifying you. For a long time my mx  
>>> servers
>>> would answer any such question in the affirmative regardless of  
>>> whether
>>> or not the mail account existed.
>> Address verification callbacks take various forms, but the way  
>> exim does it by default is to attempt to start a DSN delivery to  
>> the address and if the RCPT TO is accepted it is affirmative.  It  
>> is not usually use VRFY.  Most address verification is done by  
>> attempting to start some sort of delivery to the address.
>
> I'm assuming that DSN is Delivery Service Notification

yes

> or return receipt.

mp

> If it is or if it somehow relies on the ability to deliver a  
> message via smtp to *@example.com then I don't see how it prevents  
> spam.

If the mail says it is from chris at vindaloo.com but I cannot send a  
DSN to chris at vindaloo.com then the account is most likely bogus  
sender and is refused.  It works wonders for spam.

DSN has a specific definition -- look in the RFCs as I don't remember  
which RFC it is offhand.  But you are supposed to always accept a DSN  
from <> as part of the RFCs

Chad


---
Chad Leigh -- Shire.Net LLC
Your Web App and Email hosting provider
chad at shire.net