Re: [spf-discuss] SPF, DKIM, and NIH

Ian Eiloart wrote:

>
> --On 16 October 2009 10:11:50 -0400 "Stuart D. Gathman"
>>
>> The REJECT itself is the feedback.  The spammer manually
>> or automatically adjusts the camouflage for the spam until
>> it no longer gets rejected.
>
> Right, but I'll bet that's not universal. For example we saw
> a big drop in attempted virus deliveries when we started
> rejecting them at smtp time. My theory is that the spambots
> went and knocked on someone else's
> door when they realised they weren't delivering to us.


I found the moment one thinks there is a pattern, it goes away, and 
may or may not come back.  That includes thinking that you frustrated 
a system enough to stop and seen far too often during our 2003 to 2005 
automated AVS statistics collection that they come back.
      http://www.winserver.com/public/antispam

So I think its purely randomly cyclic.  They really don't care what 
you have, they are going to do blitz attacks not carrying whether you 
stop them or not.  But boy of boy, they believe they have the 
advantage if even 0.01% of a million addresses gets in. Once they need 
to demonstrate to potential customers is that mail acceptance is 
possible with their harvest of users.  They really don't care if its 
discarded. Showing Mail Acceptance perpetuates the problem.
Anyway, some clear results of this research did help mold our 
anti-spam products are:
   - The majority of the filters is found with EHLO/HELO domain ip
     literal mismatches. If the client issues a bracketed ip
     literal [x.x.x.x] then it is required to match the client
     connection IP.

   - Delay Mail From Validation is VERY efficent with a 60%
     reduction on DNS lookup.  RFC 2821 actually gives you
     a hint to follow this approach, wait for RCPT TO is
     validated before attempted to validate MAIL FROM.  This
     is shown with the 2003 December delay validation introduction
     in the above web page.

   - 80% of the time 821.MAILFROM = 822.FROM.  This told
     me that Microsoft's PAYLOAD version of SPF (SenderID)
     was wasteful compared to the SMTP level SPF check.

BTW, soon will update the statistics system to include Greylisting 
that was added, and also DKIM.  Once again we will be able to see how 
it fits and scales. It is pretty clear that it will take a while for 
ADSP stats are collected. You can see that with the SPF (LMAP) volume 
growth over the years from 0.0% in 2003 to 1.8% when we finished this 
in 2006.  I wonder what that percentage would be today in 2009.
--
Hector Santos, CTO
http://www.santronics.com



-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ 
[http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com