On Tue, 10 Aug 2004, Rand Wacker wrote:
On Tue, 10 Aug 2004, Dean Anderson wrote:
It has been reported that AOL is already using SPF to give reduced
filtering to SPF-using domains. Is this a good idea?
Incorrect, see http://postmaster.aol.com/spf/:
---
AOL will begin using SPF records to maintain our whitelist in the near
future. If you want to remain on AOL's whitelist, you will need to
establish an SPF record for your domain as AOL will begin to query
whitelisted IP addresses from a domain's SPF record shortly. Without an
SPF record, your whitelist entries may expire.
---
What do you mean by "establish an SPF record"? This just means putting an
SPF record in for your domain right? Is there something AOL-specific that
must go in this record?
And you are right, giving *preferred* treatment for successful
authentication (without other tools like a whitelist) is a bad thing to
do.
Ok, but if you already have a whitelist, what's the point of having SPF?
One can easily use DJB's rbldns for a DNS whitelist, with practically the
same Sendmail/etc rule as a DNS blacklist. There's only a trivial config
difference between DNS whitelisting and DNS blacklisting.
If you use SPF to maintain your whitelist, then anyone who creates an SPF
record will get whitelisted. Do you mean that only certain domains will be
whitelisted? If so, then it seems to me that SPF is just a proprietary
protocol for AOL to maintain its whitelist, and a way for AOL to
discourage outsourcing. Neither of these things seem to be in the
interests of the IETF or the internet community.
That said, you need more than just a whitelist. If you subject any email
to less filtering, and it is known from which domains you do that with,
you will encourage abusers to conduct abuse from those domains, and your
users will get more junk. Whitelisting has to be done carefully, and its
more of a response to abusive blacklists by selectively rejecting the
blacklist than a rational response to spam.
We also whitelists, but only around particular filter flaws: One of things
we do is count each occurance of an IP address in headers. Too bulky, and
messages with that IP address get queued instead of delivered. This test
has to be disabled for common addresses (192.168/16, 172.16/14, and 10/8)
as well as our own mailservers and those of large ISPs. This only modifies
_this_ particular test, and only because _this_ test is invalid if there
is genuinely a lot of email from a particular IP address. But I would not
want to whitelist just any domain that has an SPF record. That would be
bad.
But I have some doubts about the overall validity of that bulkiness test.
If the test were valid, it might in fact be helpful if Large ISPs did
identify their outbound servers. However, finding out this information is
not hard, if only you monitor your mail queues. It hardly seems worth the
trouble of an IETF protocol.
Subjecting /un-authenticated/ messages to increased scrutiny might be
justified to do though (as Microsoft has announced they will start
doing).
I'd like to draw your attention to relativity:
Subjecting /un-authenticated/ messages to _more_scrutiny_ is the same as
subjecting authenticated messages to _less_scrutiny_
--