----- Original Message -----
From: "william(at)elan.net" <william(_at_)elan(_dot_)net>
Newsgroups: spf.-.sender.policy.framework.discussion
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Friday, April 01, 2005 2:09 AM
Subject: Re: [spf-discuss] Why are so many DNS requests necessary at all?
Lucky for us you're not Microsoft who would already be patenting it ... :)
(and then imposing on us no matter if its good for every case or not).
It is already prior art SMTP systems with POP B4 SMTP works under the same
premise - IP Cached with a timeout window for the purpose of authorizing a
transaction. :-)
Why do you think I immediately saw possibilities here? It will fit right
into our POP B4 SMTP logic.
So go ahead with R&D if you have time and resources for it, but I don't
think this feature is needed for SPF (as dns can already do it) and even
if it was there, I don't think it would be much used.
You are probably right. I don't see a need for a SPF refresh directive. The
server can handle it.
Please follow me here as to why I think it is good idea. You heard me speak
much of this before.
No doubt, the #1 overhead (and redundancy) is the open-ended lookups for
LMAP domains. By far, the majority either are SPF-NONE or NXDOMAIN. If
anyone has not seen this yet, then they really don't have SPF running in a
production environment, single or widely spread.
Our transaction times were over 1 minute. Keep in mind we have a multiple
test suite system (SPF is just one, so its not the total reason for the
lengthy time). So it was immediately apparent this needed to get reduced
before putting the product into the customers hands..
Since RCPT was rejected 65% of the time, it was logical to delay the
validation until it was known whether we have an anonymous final destination
transaction. For remotes, we already have standard SMTP methods to handle
relay authorizations (SMTP AUTH, Allow IP relay tables, and POP B4 SMTP).
This delay validation reduced the DNS overhead requirement by 65% and
brought down the average transaction time to ~20 seconds. A drastic
improvement. I can't see how anyone can suggest this is an option in a
production environment. It is a requirement as far as I am concern.
So the issue is mainly applying new logic to anonymous local mail
transactions. This is the basis for the SMTP exploitation by spammers and
spoofers, thus were all efforts are mostly concentrated.
So what do we have? or turned around, what don't we have?
We didn't have a way to anchor either an IP or DOMAIN in order to provide
some level of authorization for the anonymous local main sender.
SPF was invented to allowed us to provide this anchor based on the DOMAIN in
order to authorize a machine or network of machines
In POP B4 SMTP, the anchor is POP3 which inherently requires an user login
authentication. This authorized session is now used to authorize any
pending relay SMTP process predicted to occur after the POP3 pickup mail
process (most MUAs do a POP before a SMTP). This is done by having the POP3
server signaling the SMTP server with the POP3 IP connection address. The
SMTP server caches this IP address with a X second or minute timeout window
of opportunity allowing the sender to relay mail, if any does occur. POP
B4 SMTP is used by many ISP because it helped minimize ISP customer support
headaches with users not having a MUA that supports SMTP AUTH or not
prepared to use it.
So borrowing from the same idea already existing in practice, SPF can serve
as the anchor to provide a SPF authorized IP in a cached window.
The question I have to explore is whether the total savings in time is worth
the effort. For a site that has high transactions from common sources, it
make sense. If you have 1000 users sending an average of 10 messages and SPF
lookups take an average of 0.5 seconds, you would save ~5000 seconds or ~1.4
hour or transaction time. For a even larger system, the benefits area
greater.
But then again, it might also sense to white list these people. So the
secondary benefit of the automated SPF IP cache idea is that it will save
administrative maintenance time in white listing people.
Anyway, it has potential :-)
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office
http://www.winserver.com/wcsap (Wildcat! Sender Authentication Protocol)
http://www.winserver.com/spamstats (WcSAP Anti-Spam Stats)