Below is an example log of a concern with SPF shown by our WcSap (Wildcat!
Sender Authentication Protocol) which provides a serials of test, including
internal filter white/black list, DMP, SPF, RBL and CBV.
1) The transaction was eventually rejected via DNSRBL
2) The SPF host used a default neutral result (no ALL directive, why would
they not do this?) Would such a wide IP4 range (class b?), should this be
deemed suspicious? Get ready for the spammers to support SPF like this
using neutral, softfail results!
3) The DNS lookup performance is terrible for both DMP and SPF. We can't
have this when in fact the majority of the lookups will be failures during
the transition. It is possible to use a "central and distributed P2P SPF
database" systems? Without DMP/SPF, this transaction would of been 1-2
seconds, not 17 seconds. Sure, if more connects came in from the same
site again soon after, the DNS cache would catch this. We need to improve
this lookup. Is there something I can do on our DNS server to improve the
non-authoritive request?
I'm interested in hearing from other people who might of gotten such a
transaction but did not do a DNSRBL, how would of treated this message if
it was treated on your system?
Finally, if interested in trying out a serials of test, we put our WCSAP
tester up that now includes SPF at http://www.winserver.com/testwcsap
Change the log verbosity to medium or high to get a similar output like
below.
-- log --
20040221 00:58:32 000130b1 -------------------------------------
20040221 00:58:32 000130b1 version : 1.55 / 1.54
20040221 00:58:32 000130b1 calltype : SMTP
20040221 00:58:32 000130b1 state : rcpt
20040221 00:58:32 000130b1 cip : 68.122.222.252
20040221 00:58:32 000130b1 cdn : oricom.ca
20040221 00:58:32 000130b1 from : <nroe_yo(_at_)carleton(_dot_)ca>
20040221 00:58:32 000130b1 srvdom : mail.winserver.com
20040221 00:58:32 000130b1 srvip : 208.247.131.9
20040221 00:58:32 000130b1 sapfilter : pass (time:15)
20040221 00:58:38 000130b1 sapspf : v=spf1 ip4:134.117.0.0/16
20040221 00:58:38 000130b1 sapspf : neutral (time:6469)
20040221 00:58:38 000130b1 sapdmp : testing
252.222.122.68.in-addr._smtp-client.carleton.ca
20040221 00:58:40 000130b1 sapdmp : testing
252.222.122.68.in-addr._smtp-client.oricom.ca
20040221 00:58:46 000130b1 sapdmp : none (time:7703)
20040221 00:58:46 000130b1 saprbl : testing
252.222.122.68.sbl.spamhaus.org
20040221 00:58:47 000130b1 saprbl : testing 252.222.122.68.list.dsbl.org
20040221 00:58:49 000130b1 saprbl : blocked at list.dsbl.org (127.0.0.2)
20040221 00:58:49 000130b1 result : reject (0)
20040221 00:58:49 000130b1 smtp code : 554
20040221 00:58:49 000130b1 reason : Rejected by WCSAP RBL Host
list.dsbl.org
20040221 00:58:49 000130b1 wcsap finish (17187 msecs)
(note, the 0000130b1 number is a session task/thread number)
thanks
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com