On Fri, 2004-11-26 at 09:32 -0500, Theo Schlossnagle wrote:
As for AOL, you should let AOL think about AOL -- that's their job. The
same thing it does with 10 billion message devilvery attempt everyday --
handle it. There are likely a variety of inexpensive ways to detect
faked signatures. Besides, I don't need to check the DK signature
before I look at the body, it isn't a prerequisite for anything but DK
policy at this point.
Correct me if I am wrong, but is it not RFC policy that you must fully
accept the 2822 portion of th email before any rejection can take place.
Also according to Carl Hutzler's last posted statistics, 10B seems far
to high if I recall.
This is one of the beauties of the corporate interests. If it was a
problem for AOL, you'd have heard them openly opposing the technology.
Likewise with all the other big players, they are all in the game and
plan on preserving business continuity and controlling costs to stay in
the game.
... YET.
If you have a drone army, then you'd likely just send all the data at
once. The TCP buffers will still do all the work. They pay network
costs, which is insignificant for them and no other expensive I/O costs
(like disk). But if you get so far as the data phase, it demonstrates
that you already trust the connection enough and had every intention on
reading it anyway -- DK is irrelevant in that argument.
Why on earth would I implement DK then!?
They don't have to wait for the data to finish to check the From. The
From is often at the beginning of the message, as well as Sender and
DomainKey-Signature, so as soon as the headers roll in you can start
"thinking." Of course you need to read in the whole DATA phase to
perform the canonicalization. Like I said, if you are already at the
point of reading the DATA, then you with or without DK you'd be reading the
DATA.
Like I said, why on earth would I implement DK then?
DomainKeys verifications are pretty cheap -- 4ms or so with no hardware
acceleration and much faster with acceleration. Anyone who is large
enough to have this matter either has a horizontally scalable system
that would be negligibly impacted by DK (think Yahoo and gmail) or have
a tight veritcal system that they can buy very inexpensive crypto
acceleration units for. Anyone who isn't huge, this simply doesnt
matter... why? Because my MTA can verfiy DK faster than my network pipe
can handle anyway.
So err, whats the point of DK then?
The people for whom the math really matters have certainly done it all
ready. It was a calculated decision by Yahoo! and gmail. Big business
don't implement without cost analysis. And as it was their costs, I
trust their results more than your speculation.
I don't doubt that they have, but it pains me to see these companies
moving forward without considering the alternatives, which are
substantially cheaper.
Back to one of David's point: the math clearly shows that doing DK
_before_ something like spam assassin make perfect sense as it less
expensive computationally by several orders of magnitude.
Several orders of magnitude? Thats quite a bit and doesn't reflect the
data that I've seen in working with SA. SA also affords me intelligent
classification of email. Remember even with DK, people can still SPAM!
So no one will be removing SA from their networks anytime soon and not
likely in the future either. So really, whats the value of DK again?
Cheers,
James
--
James Couzens,
Programmer
( ( (
((__)) __\|/__ __|-|__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features
SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
signature.asc
Description: This is a digitally signed message part