On Thu, 15 Mar 2007, Seth Goodman wrote:
(or until you get a match). Maintaining local SPF records for your
forwarders is a significant burden and testing all messages against a
list of known forwarders could consume a good deal of resources. The
suggestion was an attempt to mitigate these two issues.
Sequentially comparing connections to a list of forwarder SPF records
is a naive implementation, and only workable for a short list.
The smart implementation is to compile the SPF records into IP sets,
like libspf2 does (and which pyspf will do when I get a round tuit).
Regarding the need to identify all your users' forwarders, and then
construct SPF records for forwarders that don't publish SPF,
automatically creating reputation database entries for parent domains
of confirmed HELO FQDN's may accomplish the goal most of the time. It
may not yield the actual mail domain of the forwarder, but this doesn't
matter because the return-path doesn't include that domain anyway.
You have to know when not to reject on SPF fail. Hence the non-SRS
forwarder list.
The system would create reputation database entries for parent domains
of confirmed HELO FQDN's that handed you mail. Those entries represent
Except I'd be rejecting most of them on SPF fail.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735