On Sat, 31 Jul 2004, Michel Bouissou wrote:
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.
That sounds very much like a DNS whitelist. I already have that. Don't
need a special protocol for that.
Ok. Lets take a likely scenario: There are roughly 30000 ISPs in the
world. Lets suppose that either for good business or for anti-trust
requirements, they all have to all allow their customers to outsource
parts of their email system to the other ISPs. So, each ISP has to allow
the servers for each other ISP to send "from:" its domain.
How well does that work? Every ISP that is "trusted" can forge mail for
the other ISPs. That doesn't really solve any problem at all. I'll
neglect the impracticality of maintaining the records for each server for
each of those 30,000 ISPs, and the problem of distributing and updating
that database. (Hosts.txt we missed you, or maybe we make root servers
service a special zone of the ISPs mailservers, or maybe we make the root
server operators operate a parallel set of servers for this zone)
Even if you trust no other ISPs, all users at that ISP can still be able
to forge mail from other users at that ISP. That doesn't really solve any
problem either.
Oh, wait. There's one more thing: They might want to allow the customer to
connect directly from the IP addressed assigned to them by the other ISP.
So, not only do they need to allow every ISP's mail servers, they need to
allow every IP address. So any IP address forge email from any ISP. Thats
actually how it is now at many ISPs. Now we've got nothing but useless
DNS requests. So, what good is SPF?
That just assuming that everyone uses SPF. That isn't likely to be the
case. SPF has to be used by both the sender and the recipient. The sender
has to have an "approved" mail server, and the recipient has to reject
mail that isn't "approved". If either the sender or the recipient do not
use SPF, then email is either blocked, or forgeable. Most places won't
want it blocked. Though there are certain radicals who do feel it's ok to
block legitimate email, the vast majority of sites don't feel this way.
The most likely scenario is that to some degree of market penetration,
people will put in SPF records, but few or none will reject mail based on
their absence. [cart/horse]. But whatever the case, even if there is full
deployment worldwide, the abuser can still send abuse. Its just a waste
of time and money.
I was thinking that one of the objectives is to have a "responsible
entity". Possibly a worthy objective, I am reminded of the cartoon about
having to be this high to storm the castle. We might as well have an RFC
that says you must be 18 to hack into computers. It would also be useless
in stopping abuse.
But even if we ignore that all these problems exist, and just take it as a
given that everything works as envisioned: No users can forge the email
from other users. Abusers wouldn't care. And it still wouldn't stop
abuse. So, I'm not sure why we care that they _can_ forge email
addresses. How does stopping that change anything? I've never assumed
that the from: address meant anything. Ahh. I think now we are getting
somewhere. People who make false assumptions (like the from: address means
something) want to change the "silly net" to make their false assumptions
true. Rob Austein has been trying to do this since 1986, when he didn't
want to put numeric addresses in the Recieved: header.
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.
Really? There is an increase both in database size, and in DNS load. And
it means that as you add new domains, that they are each larger,
incrementally. That's pretty significant, pretty fast. It doesn't take
too long before a large domain hoster can't handle all the DNS traffic.
They are already on the edge, many of them. So then they need to upgrade
servers, local networks, wide area networks, etc.
I am always amazed at the "gee, it worked for me on my littly one-host
network. It must work for everyone else. Testing done."
And if a big DNS provider that manages hundreds of thousands domains needs to
upgrade some servers, it will make the industry happy.
Not the ISP industry. Not the DNS industry. What industry are you talking
about?
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.
Uhh, Yes you can.
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.
You don't need a ratio of www traffic to Mail traffic. I referred to no
ratio.
The more records you have to request, the more traffic you'll have.
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.
I overlooked the cache effects. The more records you have to request, the
more records will get flushed from the cache to make room for them, and
the more often they will need to be requested again. The effect on DNS
caches is also negative. This hurts performance across the board.
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 :
I do.
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
I don't. Neither does register.com. They (and we) will have to create all
that.
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.
Some do, some don't.
Changing it isn't cheap. If we are going to change it, it better be
worthwhile. I know I and a lot of other people have just about had it with
frivolous "anti-spam" changes. I could go into spam history since 1994,
but I think everyone here knows full well that we've been told "just do
this one thing, and it'll all go away". We've done quite a few of those
things, and spent a lot of money doing it, and it hasn't gone away, and it
was obvious why those things would fail back then.
You've had your opportunity for the "Just try it, please" song and dance.
Several times over.
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.
Designing? No. Deploying? Yes. Don't expect quick deployment of something
that requires a lot of old software to be upgraded. If you want to design
SPF with the intention that it will be deployed over the next 10 years,
thats different. I'm hearing people say that they want to deploy it in the
next 8 months.
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.
They won't run SPF, or won't be able to accept mail from SPF users. Its
your 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.
I wouldn't say that's "massive". There are probably more SMTP AUTH and
SMTP SSL servers than that. There are some 400,000 open relays.
However, I neglected to mention one thing: Such numbers are often
meaningless for testing and reliability reasons. For example, a voting
machine maker has recently said their machines are trustworthy because in
tests, they've had 10,000 voting transactions entered and the machine
counted them correctly. OF COURSE it counts correctly when no one is
trying to tamper with it. I'd say that ought to be a given. Any high
school freshman should be able to write a "voting" program that counts
correctly. (though I guess the real machines did actually have some
counting problems)
Similarly, 20000 trivial users doesn't mean that the entire internet can
make use of it.
"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 ;-)
Spend your efforts getting more law enforcement attention to this problem,
and it will happen. Presently, reporting virus infections or cracking to
the Feds results only in dirty looks about the paperwork they have to fill
out before doing nothing. Unless a lot of money is involved.
Well, have fun storming the castle. Information theory will prevail once
again. Abuse can't be stopped by protocol changes. But, I can see that
you are not going to be convinced any more than your dozen predecessors
were. Probably be another dozen schemes after this one fails.
--Dean