ietf-mxcomp
[Top] [All Lists]

Re: How is SPF different from RMX?

2004-07-31 01:47:35

Le samedi 31 Juillet 2004 03:46, Dean Anderson a écrit :

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?

So if this is much of a concern for you, and if you have more servers than 
what can fit on a reasonably short SPF record, then use the "exists" 
mechanism and put up an SPF record such as:

v=spf1 a:main_server.company.com mx exists:%{ir}.mailserver._spf.%{d} -all

This one fits in 75 characters, I could have made it shorter, and it allows 
defining an unlimited number of mailservers, each one with one DNS record, 
using the SPF "exists" mechanism.

The vast majority of domains have 5 records. So, we are talking about
increase the global dns database of 20 percent.

The keyword here is "distributed". A company server that manages DNS for a 
company with a dozen DNS records can easily accomodate another dozen.

And if a big DNS provider that manages hundreds of thousands domains needs to 
upgrade some servers, it will make the industry happy.

And a corresponding increase in DNS traffic, and a corresponding increase in
DNS server load. 

False deduction. You cannot make a link between the number of records and the 
number of requests for these records. The "www." A record will be requested 
by people who want to access the domain's website, when the TXT SPF record 
will be requested by MTAs wanting to check mail pretending to come from the 
domain. You cannot deduct a ratio between those unrelated events.

Furthermore, you omit considering DNS caching. If one MTA starts receiving a 
lot of mail pretending to come from a given domain, it will have this 
domain's SPF record in its local DNS cache.

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.

If you manage a couple of domains, it's a matter of minutes. If you manage 
hundreds or thousands of domains :
1/ You are not forced to do all of them in the same day ;-)
2/ You probably have the necessary resources for scripting this according to 
your customer database
3/ If you have some kind of web interface for allowing customers to manage 
part of their DNS records (as many DNS hosting companies have), you just need 
to add one field in your web interface, and possibly an engine to generate or 
check syntax and consistency of SPF records.

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.

Policy analysis sometimes show rather stupid, it would be worth analyzing the 
working hours lost in policy analysis ;-)

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.

When designing a protocol, we don't have to take into consideration the fact 
that there may be a number of servers that already do not conform to 
long-date established standards.

If machines out there are DNS-broken and don't conform to the DNS standards 
that have been in place for years, it's *their* problem to fix it. Cost for 
them is their problem.

22,000 out of perhaps 22 million domains?  That's less than one tenth of
one percent.

In 6 months, just with "word of mouth" and when SPF isn't yet defined as a 
"standard", I find this rather impressive. 22,638 is just the number or known 
(registred to http://spftools.infinitepenguins.net/register.php as of today) 
SPF-enabled domains, but registering there isn't mandatory at all, and some 
estimate that the actual figure is more than 100,000. Especially because some 
DNS / Mail hosting companies may have SPF-enabled thousands of the domains 
they manage at once, and surely didn't bother entering them all into 
http://spftools.infinitepenguins.net/register.php.

I don't know many new systems that receive such a spontaneaous massive 
adhesion from the sysadmins community, especially if they impose some kind of 
constraint and may force to rethink the outgoing mail path for the domain.

"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.

Well, "It works for me at the moment" ;-)

So, it seems that you have to track down virus operators and put them in
jail.

Just do it ;-)

-- 
Michel Bouissou <michel(_at_)bouissou(_dot_)net> OpenPGP ID 0xDDE8AC6E


<Prev in Thread] Current Thread [Next in Thread>