Re: [spfbis] Local macros strike again, was Suggestion...

[Hector Santos <[e-mail]>]

Douglas Otis wrote:

> Dear Hector,
> 
> This was simply explaining the impact caused by a change Wayne Schlitt 
> made to host name limits in his SPF library.  He restricted the number 
> of host names resolved to 5.  This caused a problem for t-online.de who 
> never published SPF records but were subjected to "default" SPF records 
> such as "a mx/24" and that had 8 hosts in their MX RRset, for example. :^(

Doug,

Since I'm not familiar with the idea of a "default" SPF record, I 
don't quite understand why a receiver would applied a "SPF default" to 
a domain that did make any SPF explicit declaration. Why would you not 
expect to see problems with this?  If this part of the specification?

That said, what we have (in our package) is a macro-based filtering 
language that includes a macro called DIP for DOMAIN::IP association. 
Its a lightweight LMAP rule that sysops can add to their filters.   We 
recommend to add them for KNOWN transactions that do not have SPF 
records and only do so if its clear to them that a DIP would 
accurately apply.  These are the DIP rules I have added over the years 
for our SMTP server:

;------------------------------------------------------------
Reason DIP whitelisted
;------------------------------------------------------------

accept if %DIP% = above.proper.com[208.184.76.39]
accept if %DIP% = bbsnets.com[66.8.157.90]
accept if %DIP% = dlois.com[216.220.225.104]
accept if %DIP% = fbg.collection.com[71.40.6.42]
accept if %DIP% = fbg.collection.com[71.40.6.43]
accept if %DIP% = hello.sd.dreamhost.com[66.33.201.150]
accept if %DIP% = ietf.org[132.151.6.22]
accept if %DIP% = imc.org[208.184.76.39]
accept if %DIP% = isdg.net[208.247.131.9]
accept if %DIP% = jck.com[209.187.148.211]
accept if %DIP% = lists.dsafe.org[66.33.206.23]
accept if %DIP% = lists.php.net[216.92.131.4]
accept if %DIP% = lists.xml.org[209.202.168.102]
accept if %DIP% = lists.xml.org[209.202.168.106]
accept if %DIP% = mail.imc.org[207.182.41.81]
accept if %DIP% = mail.imc.org[208.184.76.39]
accept if %DIP% = mail.songbird.com[72.52.113.17]
accept if %DIP% = maximus.com[12.150.181.2]
accept if %DIP% = mmx.engelschall.com[195.27.130.252]
accept if %DIP% = nic.fr[192.134.7.248]
accept if %DIP% = orgill.com[204.118.96.135]
accept if %DIP% = republico.estv.ipv.pt[193.137.7.30]
accept if %DIP% = tbsp.com[173.196.180.194]
accept if %DIP% = tclbbs.com[68.252.52.41]
accept if %DIP% = tclbbs.com[68.252.52.42]
accept if %DIP% = tclbbs.com[68.252.52.43]
accept if %DIP% = tclbbs.com[68.252.52.44]
accept if %DIP% = tclbbs.com[68.252.52.45]
accept if %DIP% = tclbbs.com[68.252.52.46]
accept if %DIP% = v2.listbox.com[207.8.214.5]
accept if %DIP% = v2.listbox.com[207.8.214.6]
accept if %DIP% = v2.listbox.com[208.58.1.195]
accept if %DIP% = wingate.com[202.180.113.230]
accept if %DIP% = ww-bbs.com[63.168.37.2]
accept if %DIP% = www1.ietf.org[132.151.6.22]

Note, these are ACCEPTS, so there is no harm per se compared to DIP 
Reject rules.

Similarly, for EHLO/HELP LMAP checks, we provide active examples in 
the default filter script file for rules that apply to us:

;------------------------------------------------------------
Reason HELO/EHLO mismatch
;------------------------------------------------------------

; The following rules basically says that only the machine
; at 208.247.131.* are allowed to use the domains listed
; as part of the HELO/EHLO command.   These are specifically
; for SSI. You should add your own domains with the IP address
; of where WCSMTP is running using similar rejection rules.

Reject if .santronics.com  in .%CDN% and %CIP% !in 208.247.131.*
Reject if .winserver.com   in .%CDN% and %CIP% !in 208.247.131.*
Reject if .isdg.net        in .%CDN% and %CIP% !in 208.247.131.*
Reject if .catinthebox.net in .%CDN% and %CIP% !in 208.247.131.*

Again these "default", SPF-like rules SHOULD only applied where there 
is precise knowledge.  I can't envision a general "SPF Default" rule 
applicable to all non-SPF domains.  Is there such a thing?

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com