Stuart D. Gathman wrote on Thursday, March 15, 2007 4:38 PM -0600:
On Thu, 15 Mar 2007, Seth Goodman wrote:
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.
Starting off with the idea that you will reject on SPF fail unless the
sender is whitelisted is one way to solve the problem. This certainly
works, but it's not terribly practical for large systems. As you have
shown, it requires the recipient to track all their users' forwarding
arrangements and create SPF records for forwarders that don't publish
themselves. This remains a substantial burden for large systems.
Compiling the locally maintained SPF records into IP whitelists reduces
the run-time penalty, but not the burden of tracking your forwarders'
MTA's. This suggestion is an attempt to get around that requirement for
SPF in the presence of alias forwarding.
One approach is to move beyond the idea that you reject on SPF fail for
MAIL FROM unless whitelisted. With a real reputation system, you can
track reputation for each confirmed identity and whether to accept mail
based on any applicable reputations, plus other metrics. You can use
the "highest" confirmed identity, or combine results from all confirmed
identities for a given sender. The reputation system you described
tracks reputation for a variety of identities from MAIL FROM all the way
down to IP. Because of the prevalence of alias forwarding, SPF fail on
MAIL FROM can be viewed as the absence of a confirmed MAIL FROM identity
to assess for reputation. Other confirmed identities for a sender may
still have sufficient positive reputation to accept mail from them. In
the case of legitimate alias forwards, you can presumably confirm the
HELO identity and track reputation for each HELO FQDN from whom you have
accepted any mail. When there is no MAIL FROM domain to query for
reputation (non-SRS alias forwarding), it sounds possible to accumulate
enough reputation on the parent domains of your forwarders' HELO FQDN's
that they would effectively whitelist themselves in groups without
operator intervention.
In some of the cases where forwarding domains don't whitelist themselves
through this mechanism, for example because they forward lots of spam
but your users expect you to accept and filter it, you can then
whitelist the domain manually. The difference is that the reputation
database would already have an entry for an appropriate HELO FQDN parent
domain, so you don't have to create or maintain SPF records for these
forwarders. New MTA's for each forwarder are immediately associated
with the reputation, or whitelisting status, of the HELO FQDN parent
domain. You may have to create an SPF record in the odd case where a
forwarder's outbound relays have no common parent domain in their HELO
FQDN's, but that should be a much smaller group of domains. This
basically tricks the reputation system into behaving like there are CSV
records and tracking group reputation for related MTA's.
--
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