begin quoting [EMAIL PROTECTED] as of Thu, Sep 04, 2008 at 03:53:06PM -0700: > On Thu, Sep 04, 2008 at 03:33:46PM -0700, SJS spake thusly: > > I object? Since when? > > Yes. Since the last time you and I talked about this. :)And I halfway > expected some wiseguy to reply with that "You have proposed a solution to > the spam problem. Here is why it won't work" with a bunch of checkboxes. > In fact, I still expect it. :)
Hmph. I don't remember that conversation. > > I mean, yes, I object to letting MS take the lead in anything, or to > > standardizing on Outlook. > > I object to that also. But until someone else gets a widely used email > program distributed we don't have a lot of choice. I'd be happier trying it out on a small scale and seeing how it actually works. > > Does that at all match my previous objections? > > Sounds about right. And? Objections can be mitigated, addressed, or redefined. Let me play my own Devil's advocate, then: >> 1. Any presumption of anonymity is lost. Is this actually important? Is it important everywhere? I think that yes, it's important, and no, it's not important everywhere; email within an organization, such as a business, could bypass this whole issue with "we don't care about anonymity within the organization because it's an illusion anyway -- we have server logs.". Inbound email from customers ought to be treated as if it were anonymous, but it can be filtered through a human being or three. Sending email to someone with a digital signature doesn't PREVENT them from reading the email (except for some versions of MSOutlook and apparently some versions of Eudora), so it's a low-cost approach that does no harm. >> 2. Unique email addresses become very painful to use. Is this actually important? Is it important everywhere? Again, yes, and no. Yes, this is important, mostly because I take advantage of it in some situations; No, it's not important everywhere. My ISP doesn't want to deal with an eternally-changing email address, nor does my employer. Intra- and Inter- business communication probably should NOT use unique email addresses anyway. We ought to be able to generate a PKI certificate that doesn't rely on an email address -- drop a wildcard into the email section, or leave it blank, for when you want to sign email from someone with an array of email addresses. >> 3. Current PKI/reputation systems are (needlessly?) complex. Is this actually important? Is it important everywhere? Yes, and yes. Needlessly complicated system will be subverted by their users, deliberately our out of a desire to merely get stuff done. We should be looking to improve the usability of such systems anyway. Building an infrastructure on it might provide interest and motivation for doing so. >> 4. Too many CAs are trusted by default on little to no >> assurance/evidence. Is this actually important? Is it important everywhere? Yes, and yes, again. Forcing users to use a system they don't trust will result in those users being sloppy and stupid -- so far as they are concerned, it's a mess anyway, why bother? So. Start providing assurance. Accumulate evidence of slack policies. Test the CAs. Impose penalties for breaches of established policies. Make it easier for users in inspect who they trust, how they trust them, and so and so forth. Addressing #3 might solve this one as a side-effect. >> 5. Doesn't solve the problem of a compromised machine. Is this actually important? Is it important everywhere? Not sure. I'm not sure ANYTHING will solve the problem with a compromised machine, but at least with a PKI infrastructure to support someone, the machine can be cleaned (wiped, if necessary), the certificate revoked and a new certificate issued, and only a minimal disruption need occur. One can certainly argue that entirely eradicating spam may not be a good idea, as at least this way there's some suspicion that a little caution may be called for when reading email. People who feel TOO safe tend to be kind of stupid, so "good enough" may indeed be the best solution in the long run. -- Objections are sometimes necessary provoke a decent discussion. Stewart Stremler -- KPLUG-List@kernel-panic.org http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
