On Mon, 2004-06-07 at 13:42, Scott Kitterman wrote:
Looking in as a mostly innocent bystander (I hope to use (and am using) SPF,
not write code for it) I think that perhaps people would be more likely to
calm down if SPFv1 was still headed for the IETF. What I hear people saying
is that SPFv1 allows processing before data in a lightweight protocol and I
don't want to lose that.
I believe that the New SPF is focused after data (2822) with before data
(2821) deferred until later. If the old (SPFv1) SPF could be adopted as the
basis for an RFC for 2821 time in parallel with the New SPF being adopted
for 2822 time, then I think people would be happy. It would also help sell
SPF in the mean time. Right now, it just feels like an orphan.
SPF1 and CID do not need to be mutually exclusive. I see a lot of
potential for SPF1 (as or similar to how it is now). There are a huge
number of domains for which "v=spf1 +mx -all" is all that they would
ever need. Large organizations that desire the full CID implementation
could and should still publish SPF1 containing a superset of all
potential servers, with a flag in there to say that CID data is
available as well. They could publish lets say "v=spf1 +mx +ptr +CID
-all", which would drop obvious fakes like it does now or pass a
response back to the mailserver saying "its all clear so far, go ahead
and continue accepting the email, but check it against CID after that,
because this domain has additional information there". This way
*obviously* forged emails are still bounced early in the game. [Large
company] should certainly know all the possible addresses their email
might come from. Even if they get lazy and overshoot by just listing an
entire class c in SPF1, they have still announced 4 billion addresses
that can not send mail claiming to be from their domain, and they have
done so without negating their ability to setup CID. Just as nobody is
required to use SPF at all, nobody would be required to spend the extra
memory requirements and processor time to do full CID processing. If a
site operator decided the SPF1 list is "good enough" for their needs,
then they have still gained a useful tool to block a good portion of
forged emails.
While companies that sell datacenter versions of their os and the
manufacturers of multiprocessor systems to run it on would all love to
add enough bloat to require upgrades, do not lose sight of how these
extra features are going to scale under load.
--
Scott Taylor - <security(_at_)303underground(_dot_)com>
BOFH Excuse #445:
Browser's cookie is corrupted -- someone's been nibbling on it.