Tool for validating sender address as spam-fighting technique?

[Chad Leigh -- Shire.Net LLC]

On Mar 11, 2007, at 2:55 PM, John L wrote:

>> I phrased it wrong.  You are not responsible for the content, but  
>> you are responsible for the mail domain and that includes  
>> verifying that mail is validly from your domain you are  
>> responsible for.
>
> Oh, OK.  So if someone sends pump and dump with a chad at shire.net  
> return address, and I do a callback and your MTA says "yup! that's  
> a 100% valid address!" then I turn you in to the SEC, rignt?

You do know what the SEC is, right?

> You have now confirmed that the mail is from you, after all.

No, it only confirms that the sender address is an actual address.

> Or if you haven't, what purpose did the callback serve?
>

It served to identify that it is possible a valid email.  A failure  
is almost definitely a non valid email.   It is a test which helps  
determine whether to accept it.  We have a policy of not accepting  
mail from people who cannot accept DSNs back.  That does not mean we  
give a blanket pass to those who pass address verification.

> There is some reasonable validation technology coming along, most  
> notably DKIM which which I presume you are familiar.  But callbacks  
> are not it.

Callbacks are one tool in the toolbox.  Maybe someday there will be  
better tools and we can retire address verification.  Callbacks, at  
this point in time, work very well for differentiating a large amount  
of non valid mail from a smaller pool of possibly valid mail.

DKIM is interesting and I am watching it.    I am in the process of  
adding some support for it btw, both for our authorized senders, as  
well as in our receive phase.  For example, we are  considering not  
doing address verification on incoming mail that has a valid DKIM  
signature.

>
>
>> and you are breaking the RFCs.  (valid verification includes  
>> checking that the sender can accept a proper DSN back, which is  
>> required of the sender to do).
>
> Uh huh.  Which RFC is this that says I have to permit a fake  
> partial DSN transaction?  If you have a DSN, send it.  If you  
> don't, don't.

The RFCs require you to accept back DSNs.  Testing that you do is a  
valid test to see if I am talking with a valid sender -- one who  
implements the RFCs and is not a rogue internet user who does not  
cooperate in the exchange of emails according to the agreed standards.

Show me some real verifiable numbers that show that verification  
traffic to your box is a significant portion of the otherwise bad  
traffic of mail bombs, bounces, etc.  On my system, and we support a  
lot of mail domains, some of which (now or in recent past) we "big  
name" domains that had a lot of exposure.  Address verification  
traffic has always been small compared to our overall load.

You are complaining about a non issue.  I can say that address  
verification helps us reject the lion's share of spam we receive  
without having to process it further.

Chad

>
> Don't forget that the From: line address need not be the same as  
> the bounce address; in my mail it never is.
>
> R's,
> John

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