Stuart D. Gathman wrote on Thursday, March 15, 2007 11:55 AM -0600:
On Thu, 15 Mar 2007, Seth Goodman wrote:
This is true, however, the HELO FQDN generally contains the parent
domain name, and that just might provide a way to emulate CSV and
automatically track non-SRS forwarders who publish SPF records. If
If the forwarder publishes an SPF record for their domain (not the
HELO FQDN), then there is no problem. It doesn't matter if they
publish an SPF record for HELO names, because a proper HELO FQDN
matches the connect IP anyway. The pymilter best_guess algorithm
already matches correct HELO FQDNs against the domain:
if res != 'pass' and hres == 'pass' and
spf.domainmatch([q.h],q.o): res = 'pass' # get a guessed pass for
# valid matching HELO
What I suggested operates the same as this when the forwarder publishes
SPF for their mail domain, or you construct local SPF records for
trusted forwarders who don't publish SPF, *and* you're willing to check
*all* incoming messages against the whole list of trusted forwarders
(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.
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.
The system would create reputation database entries for parent domains
of confirmed HELO FQDN's that handed you mail. Those entries represent
the mail flow of all the forwarder's MTA's that have related HELO
FQDN's. If the mail flow from a forwarder is very spammy and your
reputation system begins to refuse their mail, the task now is to find
the relevant parent domain that is already in your database and
whitelist it. As long as the forwarder's MTA's have related HELO
FQDN's, you shouldn't have to create or maintain local SPF records for
them, and you shouldn't have to preemptively test all known
forwarding domains for every incoming message. This is somewhat more
correct (in a strict sense) than using a "pretend" MAIL FROM domain,
since the reputation applied in this case is from a HELO identity,
and it is explicitly tracked that way.
--
Seth Goodman
-------
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