spf-discuss
[Top] [All Lists]

Re: Re[2]: Re: DEPLOY: SPF/Sender ID support in Courier.

2004-08-29 10:11:14

A> server.  Please support SenderKeys (or something like it) and also

Bad idea. crypto stuff stomps on loads of legitimate middlemen,
costs dearly in bandwidth and CPU, is very complicated, prone to
export regulations and patents, and introduces a range of new security
problems - all with absolutely no benefit over plain old SPF.

Summary of some of the things I have written off-list:

If the crypto header is self-contained with checksum, then the worst that 
happens is the same as when there is no SPF record, e.g. the e-mail gets 
delivered.

The bandwidth argument fails because unless "-all" is every where, then SPF has 
to read and tag the data.

Etc..

See below for main point.



Also, we need to keep a close eye on Microsoft's crypto key initiatives.
Take a careful look at their magical appearing/disappearing/re-appearing and
frequently renamed "Palladium" initiative, which involves collaborating with
Intel to integrate a BIOS level encyption key management system,

[...]

In SenderID terms, it's a potential way to provide extremely robust and
centrally managed encryption key that operates quickly because it's
occurring at an extremely low hardware level, almost directly on the CPU
itself.

Unfortunately, since Microsoft or their corporate partner would hold all the
private keys for these encryption devices, 

[...]

Again I assert that crypto signing of e-mail is going to happen.  I assert that 
a de-centralized approach like SenderKeys is our best defense.

We either fulfill the market need or Microsoft will.