Eben's mail came through fine for me, and as what he has happening to him now has happened to me in the past, perhaps I can shed some light on the subject [what better way to wind down a friday, eh?]

Without going too deep into the history and ramifications of securing e-mail from tampering, suffice it to say that in the long run it is "a good thing" to consider ALWAYS signing e-mail -- it helps build credability and community.  After all, if you "always" sign e-mails, then one purports to come from you WITHOUT a signature, people know to treat it as suspect.  This is especially re-inforced if the unsigned message urges you to engage in activities of questionable legal stature... ;)

BUT the problem [as Eben's messages point out] is that not everyone is on the same page when it comes to HOW to do it.  Straight ascii-armoring isn't too bad -- the message remains fully readable and has roughly 5 lines of overhead [a "begin signed message" header line, a trailer line indicating the signature follows, the "signature" itself (which contains printable ascii chars only), and a final trailer line]  There are some problems with this: if quoted, any re-organization of newlines, leader chars, or whatever will "break" the signed portion, so users should manually remove these when replying [but as evidenced by multiple copies of mailing-list-archive-and-how-to-unsubscribe trailers, we see this can be a bother for some...]

Another downside is that only the body of the text is "signed", anything else [namely, attachments] are not part of the deal.  Also, an accepted practice for "signature" lines is to lead off the witty-saying signature block with the sequence "--<space><newline>" -- yes, with a trailing space.  Unfortunately, a side-effect of signing a block of text is that the text has to be translated into 7-bit quotable AND trailing spaces have to be preserved (this leads to those "=20" items you see in messages -- 20 is the hexadecimal value of a space...)  Now the coup de' gras on this particular combination is that lines that BEGIN with a dash need to be escaped as well (because they normally indicate the end of the actual block), thus the .sig leadoff line becomes "=2d<space>--=20" -- if anything fails to un-convert this, the "signature" becomes "broken"

To alleviate that problem, the concept of MIME-signed messages comes into play -- a seperate, or "detached" signature is generated that covers not only the message itself, but each "attachment".  Further, the body itself remains free from tampering [because you aren't placing any begin/end blocks around it, only the "mime seperator"] so you don't have the =20 garbage to contend with.

HOWEVER, this is a mailing list, and we've had problems in the past with folks (intentionally or otherwise) sending either (a) damaging or harmful attachments, or (b) files far to large to be transmitted via e-mail (especially to a LIST) SOOO... lists tend to be configured to "drop any/all non-text attachments".  Since a signature [visible though it may be] is really "binary data", it can get dropped along with the rest.

So if all of this happens:
   1) Eben writes a message
   2) signs is with a detached signature
   3) sends it to this list
   4) the list strips the signature

then what happens for your client?  In most cases, you won't see anything because the client can't render the page without the signature -- there is NO guarantee that what is written is "pristine"  [well, "can't" is too strong a word, perhaps "won't" is more appropriate]  older [text only] clients don't have a problem because "the text is still there"   When you REPLY, often the 'missing' text comes back into view.

Tom

p.s.  If the "signature" block is longer than a couple of lines, then it is possible/probable/likely that Eben is sending his "public key" rather than merely a signature.  The "public key" information can be used by pgp/gpg to securely encrypt a message, and is indeed "needed" to decode/verify the signature, but you generally don't send it with the message itself, rather, you would send a pointer to a website and let users retrieve the public key themselves.  [there are also dedicated "keyservers", which I believe the plug-in makes use of, so you don't have to learn HTML or concinve someone to run an FTP server to host your file]

Also, the "public" key will grow over time, and this is "a good thing", because the more it grows, the more it means "you are you".  Here's how that part works:

   ** Say at some point Eben and I meet on the street.  He and I can "exchange" our public keys, sign them with our own [private] key, and return them.

   ** Further, say that you and I "have met" at some point in the past and done the same thing.  

   ** Finally, [for the sake of argument and this example] say you've never met Eben personally.

The fact that *I* have signed *his* key makes his key appear "genuine" to YOU, even though the two of you have never met!  Your client software will look at his public key, see *MY* signature on it, and (because you trust me), mark Eben's signature as "good".

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *