On Thu, Mar 17, 2005 at 12:09:55PM -0500, Radu Hociung wrote:
Alex van den Bogaerdt wrote:
Currently you publish about 11 subnets (I didn't count carefully,
it may be 10 or 12) and we (our software) have to find out if an
ip address is a member of these subnets.
What I propose is that you replace this with a mechanism where
we would give the ip address to you, then you look it up and
respond match or non_match. This does not imply that you need
to change your policy.
What is being implemented now (after yesterday's change, which has
already propagated to some places) is far more resource efficient than
what you are proposing.
When the situation arises that compromises need to be made,
my compromise is justifiable as is the current one.
It is even more resource efficient to publish +all but then
everybody notices it is wrong. Being resource efficient is
not always the right thing to do (I deliberately used an absurd
example; don't attack me on that).
The list of IP blocks is fetched within the same query that gets the SPF
record. It's a query that is done no matter what. So to maximixe it's
value, it is correct to fill it with as much information as possible. If
an exists: mechanism was pointed to, a second query would be required,
whereas in the current implementation it is not necessary.
My simplified example doesn't elaborate on much needed planning
and design of the real record. Adding a fixed set of outgoing
mail exchangers would already cope with a large part of legitimate
email. There may be more tweaks needed. It was input to a discussion,
not a ready solution.
On top of this, the current record can be cached by a local DNS server,
whereas the exists: query cannot be cached. This is because forged
@rr.com email comes from potentially all 4 billion IP addresses in the
world, and you'd have to do a query for each one individually.
I think it isn't that bad. First of all, the amount isn't 2^32,
it is less than 2^29. 224.0.0.0/3 isn't going to be checked, nor
is 127.0.0.0/8 and similar. That still means over 500 million possible
addresses. But from those 500M, not everyone is going to spoof. And
certainly not all at the same time.
So yes, you could save a few bytes in the SPF record, but it would cost
4 billion queries, plus the storage required to cache each one of those
queries. I don't know about you, but I get forged rr.com email all the time.
From how many _different_ addresses? And how many _different_ rr.com
customers? Not that 500 million, not by far.
And how many of the zombies are already filtered out due to blacklists?
Or maybe because of other local policies such as bad helo, improper use
of rfc822 addresses in an rfc821 conversation?
Don't you think the remaining new spammers and current zombies _will_
be cached? Especially when the dns is queried over and over again for
the same address?
And what about the possibility to use the information (at rr.com) to
see which addresses spoof rr.com email? "Yes M'am, this email you
are complaining about comes from an infected host in China; our
automated alert system has already contacted that provider as we've
seen tens of thousands of spoofing attempts"
Alex