Subject: [spfbis] Optimization consideration

From: Hector Santos <[email-masked]>
Date: Sat, 18 Aug 2012 23:18:03 -0400

SPF, like many DNS related protocols, get a bad rap with overhead and 
correctly so, IMV, most of it still overhead.  Since 2003, we learned 
immediately that we can get 60% reduction in SPF overhead simply by 
following the ideas in RFC 2821/5321 section 3.3

    Despite the apparent scope of this requirement, there are
    circumstances in which the acceptability of the reverse-path may
    not be determined until one or more forward-paths (in RCPT
    commands) can be examined.  In those cases, the server MAY
    reasonably accept the reverse-path (with a 250 reply) and then
    report problems after the forward-paths are received and
    examined.  Normally, failures produce 550 or 553 replies.

Is there similar text for SPF?

The 60% is unique to our server as that as been the consistent amount 
of bad/unknown RCPT attempts on our server over the many years in 
service.  We still get stupid [email-masked] attempts, and 
once upon a time, winserver.com was a free domain for our customers to 
use an alias on our server using the old school MHS email address 
formatting.  But it was abused so we stopped it in 98, but the 
spamming attempts has never stopped.

So SPF checking is delayed under RCPT TO is a valid local user 
account. For remote user addresses, it is only allowed for 
authenticated senders so SPF is skipped here. Its only used for 
anonymous local user mail transactions where authentication is not 
required (for public service port 25).

If SPFBIS does not have some insight here, I believe it valuable 
insight to have to help minimize DNS overhead/wasted lookups when mail 
is not going to be accepted anyway.

-- 
HLS