spf_allowed |
Edit | Print this page |
|
Tested and working in production server 23rd Feb 2004! Initial work completed and scheduled to be available for testing 22nd Feb 2004. Work slated to begin on this check 11th Feb 2004, based on the work of http://www.wayforward.net/spf/ and adapted to the Outbound Index by Christopher Armstrong This check essentially creates an SPF client, at least a simple one, within the Outbound Index query server. The requirements for this seem obvious so I won't describe in detail. Each email administrator would turn on this check and configure what he wants to do with the results of it, through the Outbound Index dashboard. For example, what action or scoring to take on pass or fail of this test: reject, accept and skip any scrutiny of message content, mark as unknown/suspicious, tempfail etc. What I think is not obvious is the potential to use an SPF record check as part of the source data for a DNSWL (DNSWhiteList?): In a DNSWL query, I get only the IP address to work with Lookup PTR record and then crosscheck that by doing a forward DNS lookup on the result. If I get matching forward and reverse DNS, use the base domain part of the result to check for an SPF record. If the SPF record exists, does the SPF record authorize this IP? That becomes the answer returned to the DNSWL query client. Passing means that the sender domain isn't forged. Although a spammer could setup PTR record and matching forward DNS for his mail server, including the base domain he plans to use in the return address - AND set up an SPF record - it doesn't fit the present style of spammer emailing: 1. his own lines and equipment get the rejects and bounces 2. he cannot use thousands of zombie machines to send for him because their PTR records aren't under his control 3. spammers seem to prefer varying or randomizing the return address domain. (I also have a method of preventing the spammer from acheiving this whitelisted status anyway, which I'll describe at the end.) Failing just means this test couldn't determine if the mail is of whitelist quality or it is not. So nothing bad should happen to mail that fails this check, other than further processing. Advantages: Utilizes SPF records for good, forwarding / forwarded accounts are a non issue in this usage. Idea to make sure that non-identifiable spammers don't get the whitelisted status: Combine the above logic with one more factor: an Identifiability and Stability score stored in the Outbound Index by domain name. So a ficticious StableCoExample?.com:
potentially based on factors such as:
And by comparison, a ficticious HardWorkingSpammer?.com:
Although it is possible for high profile, identifiable and stable companies to send spam - ISPs and recipients can also easily block them with a RHSBL, so long as they are not moving around and hiding - and they can increasingly be held accountable by legal means.
of2349@wiki.outboundindex.net -- Thu, 02 Mar 2006 14:11:31 -0500 reply
steps2141@wiki.outboundindex.net -- Thu, 02 Mar 2006 14:12:04 -0500 reply This is a multi-part message in MIME format. --c168caa0dfaf38b369e5edeb11ed1db2 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit an a bad bringin up can go out annywhere along th dhrainage canal an prove to --c168caa0dfaf38b369e5edeb11ed1db2-- .
and5099@wiki.outboundindex.net -- Thu, 02 Mar 2006 14:14:27 -0500 reply |
|
| This page was last edited 2 years ago. | View page history | Edit this page |