Encrypting / Signing the mail subject?

[Robert J. Hansen]

>> If you want to call something with a 70-year track record a "bad 
>> workaround," well, that's on you.
> 
> "We always did it like this" is not actually a valid point, but hey 
> …

The idea of replacing descriptive subject lines with non-descriptive but
unique conversational identifiers is an old and very well-used
technique.  That means it's been thoroughly tested in a variety of
real-world situations, is simple enough for the vast majority of users,
is robust in the face of failures, its failure modes are well-known, and
more.  On top of that, it's a solution that can be implemented *right*
*now*, with no code changes necessary.

What you're proposing has zero implementations, zero track record, and
we have zero knowledge of its failure modes -- just a vague belief that
it will somehow be superior.

This doesn't mean you shouldn't try it.  It might actually be superior,
and if we didn't try new things there would be no progress at all.  But
your fervor for the new needs to be tempered against a serious
understanding of timelines: if you were to have a complete RFC today you
might see this proposal fielded in significant numbers in three years,
and enough feedback for it to be a trusted alternative in five years.

When I weigh a perfect solution that's a minimum of five years out
against a pretty darn good solution that's available *right now* and
involves no code changes and only minor policy changes... well.

Like I said, you're doing it wrong.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/attachments/20150116/bf70a0a7/attachment.bin>