On Sat, 31 Jul 2004, Michel Bouissou wrote:
But, great care or not, SPF does make it pretty much impossible to
outsource. You need a record for each mailserver. It is reported that it
is only possible to have 18 root Nameservers because that is the maximum
that can fit in a DNS packet. The TXT record is not as efficient, but I
don't have any exact number for the maximum number of servers will be
possilbe. But it will probably approximately 18. This limits the number
of servers that can be outsourced, or even internally used.
I understand from this that you don't understand at all the way that an SPF
record works. Please Read The Fu^Hine Documentation...
I read
http://www.ietf.org/internet-drafts/draft-ietf-marid-protocol-00.txt
The example records seem a lot shorter than 512 bytes. But that limit
comes pretty quick. I seem to recall that HESIOD records could quickly eat
that up. Wait, wasn't that one of the reasons why we thought that TCP was
necessary in the first place?
In this respect, RMX was probably better. But it was still rejected
because
It didn't solve the problem and was therefore gratuitous.
Then there are deployment issues. Besides the cost of adding the SPF
records to tens of millions of domains and the complications of just
getting that done,
Tens of millions of domains are currently supposed to manage and maintain
their DNS records, and each domain, even really "basic" needs at least 4
records in DNS, typically
- 1 SOA
- 2 DNS
- 1 MX or more
- 1 A for the MX (if in the same domain)
- Generally one "www.thing.org" that points to the web server
The vast majority of domains have 5 records. So, we are talking about
increase the global dns database of 20 percent. And a corresponding
increase in DNS traffic, and a corresponding increase in DNS server load.
And of course the bigger the domain, the greater the number of machines and
"A" records in DNS.
Agree. It has less impact on the large domains.
Setting this up is a matter of minutes for one domain
Setting anything is "a matter of minutes for one domain". Try doing it
for hundreds or thousands of domains.
, so every domain that has an admin maintaining it should be able to
afford it -- and those who do that externally actually pay for a
service, don't they ?
Service that doesn't include 20% increase in frivolous domain record
maintanence: And it is ongoing maintenance. Change the IP of your
mailservers, and lots most stuff has to change. It gets correspondingly
more difficult to renumber.
Expressing this in "billion dollars" is like trying to evaluate the time that
I spent scratching my head today, multiply this by the number of inhabitants
in my country, and calculate from there how many billion dollars are lost
each month from work time lost scratching one's head...
Yes, to some extent. But that means its not a good idea to make everyone
on the planet scratch their heads a lot. Policy analysis includes these
sort of costs in the cost analysis.
there are other complications:
DNS protocols present provide for TCP connections to handle packets larger
than 512 bytes. However, many server implementations still don't support
TCP, or don't support it properly.
If they don't, they should. If broken, fix.
Much more easilly said than done. There are complications and costs to
doing this.
Well, you're depicting a whole nightmare in which it seems that you much
exagerate the problems that implementing SPF causes. Remember that more than
22,000 domains using SPF are known as of today, and some suppose the actual
total figure is about 100,000 or more.
22,000 out of perhaps 22 million domains? That's less than one tenth of
one percent. I'm sure more than that use "hair growth cream". It doesn't
matter how many use it if it doesn't work.
"It works for me at the moment" is not a sufficiently convincing technical
analysis to spend a great deal of money and inconvenience a lot of people.
Simply rejecting all mail with a 450 response for 5 minutes "works for
some at the moment", too. But it won't work for long, because abusers
simplely need to try again in 5 minutes, and remember for which addresses
they got a temporary error response. Not a big problem for the abuser to
solve. Unfortunately, making them solve it means that temporary respite
from spam that one obtains from a crashed server will go away, too. Gee
thanks. Now there is nothing to make those events less bad. Keep shooting
us in the foot, folks. Maybe you'll hit something vital. Or maybe, you'll
just kill something like outsourcing email, and no one will notice.
Before something will be accepted, it needs to work for a long time. That
means that it has to do more than just break the current and past abuse
engines for a few days. It has to break them permanently. Wait,
information theory says something about that. It says you can't ever
achieve that.
So, it seems that you have to track down virus operators and put them in
jail.
--Dean