On Fri, 2004-11-26 at 04:36 -0800, william(at)elan.net wrote:
If I remember Sendmail also said that they ran their own tests and
increased cpu load on any single server due to signing all emails was
about 25%, I think this may have been with smaller 384 or 512 keys.
We should probably assume that good size keys (768 at least) would mean
around 50% increase in cpu load (and to me that is acceptable number).
To me also. Making it _slightly_ more expensive to send mail isn't
unacceptable; it's the premise behind stuff like hashcash too.
I do not think that signing and verifying will be upset by that you dont
need to do virus and spam checking, at least not immediatly. I have to
assume that spammers are probably not going to sign their emails with bad
keys, but they may sign them with their own good keys and that means you
still need to do allthe same virus and spam testing after the signature
verification.
I'm not convinced of that. Let us assume the existence of a reputation
system which you were going to use to decide to reject the mail in
question.
You have a mail claiming to be from alwaysspams.com. Optimise the
following flowchart:
1. Check DK signature. If it's invalid, reject the mail.
2. Reject the mail because it comes from alwaysspams.com.
You also will not be able to reject email based on "I sign all my email"
policy records for DomainKeys because DK signed emails will fail after
being processed by almost any mail list and that means people who want
to protect their domains from beeing spoofed really can not do it with DK.
Mailing lists aren't really a problem -- they add a Sender: header and
if there's no signature for _that_ but should be, then you can reject.
But it's nice to be able to reject if _either_ is absent, which is why I
favour IIM over DK. It's one of the details that will presumably be
sorted out in a merger of the two.
But mail signatures are going to be good in the future for "hanging"
accreditation on to them and for reputation systems (and they are a lot
better for it then SPF or SID which cant be trusted for true identity
verification) and that means in some far future you maybe able to use
information that email was signed and verified and then go to third party
that will tell you something about the party that signed the email and
after that you will not need to do additional spam tests. But it may take
quite some time before we come to this point and then see benefits from
automated mail signatures in reducing extra filtering cpu load.
That's true.
The reason I mention it is because some here were taking about renaming SPF
into some "safe mail standards association" (I rephrased on purpose). Well:
1. don't, you might be laughed at in the same way as with actonline
2. its not about the name anyway, its about what we do and how
I'm not sure about that. We're laughing at actonline because they're
saying stupid things not really because of the way they present
themselves. And marketing does have a large effect. SPF has got fairly
good marketing, regardless of the technical issues. VHS video recorders
were marketed better than Betamax.
I think you overestimate the intelligence of the average system
administrator -- or at least their willingness to think for themselves.
--
dwmw2