[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Hi and attachment question

on Mon, Apr 14, 2003 at 12:35:37AM +0100, Antony Gelberg (ag@antgel.co.uk) wrote:
> Hi all,
> I'm migrating a couple of servers from RH 8 to Debian 3.0, and thought it
> would be a good idea to subscribe here.  One question though - why is it
> that some posts come through to me as text file attachments?  It's pretty
> annoying.

Others have addressed this in part.

While I'm not currently signing my mail, my usual practice is to do so.

			A (not so) Short Rant / FAQ 
		      on the Subject of Signed E-Mail 
		       and Public Key Infrastructure

		    Karsten M. Self <kmself@ix.netcom.com>

    You're probably reading this because you either stumbled across it
    at my website, or I sent it to you in response to an email you sent
    me saying you can't read my mail.  The reason is that I'm using an
    open Internet standard, RFC 2015 encoding, to sign, or authenticate,
    my mail.  This standard has existed since 1996, and can be freely
    implemented by any email software author.  It provides means to both
    authenticate, and encrypt, email.  You have a legal right to do this
    in many parts of the free world.  And the standard is written such
    that any compliant mailer _can still read_ the body of a signed
    message, though it may not be able to validate it, or understand the
    signature itself.

    By sending mail encoded per RFC 2015, I and others are creating
    compelling content under this standard.  At some point it's
    sufficient that others will want to access it.  By doing so, they
    are also (usually) availing themselves of *practical* crypto,
    including generating keys, getting these signed, and the other
    appurtenances of a viable public key infrastructure.  

    Merely having a legal right to encryption doesn't mean you have the
    technical means.  Merely having the technical capability doesn't
    mean you have (or know how to use) your keys.  Merely having a key
    doesn't mean that it is signed, in use, well known, or part of a web
    of trust.  If you find yourself with a need to produce authenticated
    or encrypted content, you're going to have to find, install, learn
    to use, and build the infrastructures necessary, for same.  There's
    a saying among the Boy Scouts here, "be prepared".
    Hence the intentional role I and others play as goads to the online

    As to the immediate problem, the short answer is that:

      - Your mailer is broken.

      - This is your problem, not mine.

      - File a bug report with your vendor.

      - I'm going to continue signing my mail, and if you don't change
        your end of things, you're going to continue having problems
        reading it.

        In some cases (you're cute, my mom, or you're offering
        sufficient reasons per hour), I'll make exceptions, but this
        is on a case-by-case basis, and I'm intentionally leaving it
        as a PITA manual process so that each of us is reminded it's
        a bad idea:  me, when I do it, you, when I forget and you're
        stuck with unreadable mail from me.  GET A REAL MAILER.

      - No, this isn't a virus, a bomb, a bug, a worm, or any other
        executable code.  And if it is, that's your problem, not mine.
	For signed mail, both the content and the signature are simply
	text with a particular semantic context significat to a
	validation program.

      - If your IT or MIS department is brain-dead enough to actually
        strip off these attachments before you get your mail,
        I'm going to laugh at you in public.  Sorry, this ain't the
        sympathy department.  There's a nice rant below about why this
        is such a pathetic action, though, you might enjoy reading it.

    The long answer is the rest of this document.

    For a well-reasoned essay on why public key infrastructures,
    including encryption and authentication, are vital to a modern
    economy, please read:


"Your Mail is Weird"

    I use a combination of tools in my email to create messages which
    are cryptographically signed in such a way that it is readily
    possible for the recipient to gain a good level of assurance that
    the message:

      - Originates from me.

      - Hasn't been modified in any way en route.

    This is sometimes called a digital signature (a technical term, not
    to be confused with the recently passed US legislation on
    "electronic signatures", regarding legal contractual powers
    associated with various, and largely very weak, methods of inserting
    corporate hands into your wallet).  The system under which it
    operates is known as public key infrastructure, and is based on
    public key encryption.  You're probably going to start hearing a
    whole lot about this over the next year or so.

    That's the long description.

    The short story is that there's a way for me to keep half a secret
    and spread the other half to the world in such a way that you can
    tell if a particular message came from my half of the secret.  It's
    pretty cool.

    The other part:

    You're responsible for determining whether or not a communication
    that purports to come from me is in fact from me.  And if I didn't
    sign it, it almost certainly didn't.  If the message *is* signed,
    it's still your obligation to verify the signature itself.

What are RFC 2015 and 3156 and  and Why Can't I Read Your Mail?

    There's an Internet standard, called a "request for comments", or
    RFC, which covers MIME encoded encryption and signatures.  This is
    RFC 2015, "MIME Security with Pretty Good Privacy", (more info below
    under "Resources"), and defines how to handle public key
    infrastructure (PKI) encryption and authentication via standard MIME
    protocols.  It's been updated with a second standard, RFC 3156 (also

    While RFC 2015 is still a draft standard, it is widely supported on
    multiple platforms.  There are some pieces of Internet mail plumbing
    which break the protocol -- multiple mail clients ("email
    applications" to you), as well as some server applications.
    LISTSERV and beromail are two I'm aware of -- but compatibility
    modes are frequently available for such software, and in many cases,
    support is planned in future upgrades.  But that's another story.

    If you're interested in the gory technical details, read on.  You
    should be able to save my email as a text file and open it in a
    simple editor (e.g.:  Notepad or Write under Legacy MS Windows).
    You'll find that the message body content type of my messages is
    expressed as:

	Content-Type: text/plain; charset=us-ascii Content-Disposition:
	inline Content-Transfer-Encoding: quoted-printable

    ...which should be handled properly as inline plain-text content.
    If your mailer doesn't present the message body in this format, you
    should report a bug to the program maintainer or vendor.

    The signature is presented as:

	Content-Type: application/pgp-signature Content-Disposition:

    Again, this is plain text, non-executable, and in no way represents
    a threat or possible exploit on your system.  For an intelligent
    mailer, this should be interpreted, rather than presented, and used
    to validate the message content itself.  Otherwise, the content can
    be presented or concealed, at the user's preference.

So, Why Do You Insist On Signing Your Mail Anyway?

    Fair question.

    Part of the reason is for your benefit, where you are the reader of
    my mail.  It is your responsibility to ensure that what you are
    reading as attributed to me is in fact my own writing.  While
    digital (or sometimes "electronic" signatures now carry some legal
    standing, I'm not vesting my GPG hash with this power.  However, you
    can be pretty confident that words appearing over my signature,
    verified against my public key, were written by me, or by someone
    who has access to my computer, my private key, and the pass-key
    necessary to utilize it.

    Why is it your responsibility?  Simple:  you know you've received
    mail from me.  I may or may not know I've sent it.  As is well
    known, email is an insecure, unauthenticated medium.  It's quite
    possible that someone is sending something claiming to be someone
    they aren't.  In fact, this happens as a matter of course with spam.
    Since you (the recipient) have the evidence in front of your eyes,
    and I've no idea it's been sent, if it's not from me, the burden of
    authentication lies with the recipient.

    If it's not signed by me, your assumption should be that it isn't
    *from* me.

    A large reason though is to encourage and advocate use and adoption
    of tools that support public key infrastructure (PKI) methods, both
    the ability to create and properly process signed and encrypted
    mail.  I've found myself at several times needing to send
    authenticated or encrypted mail to persons, only to find that the
    recipients did not have a public key, PKI support within their
    mailer, or even, at times, a mailer capable of supporting PKI.

    It's been suggested variously that I sign messages inline, or in
    some instances, that mailing lists drop all MIME-encoded
    attachments, sometimes due to security concerns of the recipient in
    receiving attachements.  I believe this is the wrong solution for
    two reasons:

      - It breaks useful behavior.  MIME attachments *can* provide
	useful information, including support of non-ASCII
	charactersets, required for basic communications in much of the
	world.  In the case of signed messages, a recent SANS alert of
	the BIND exploit of the day was copied to a mailing list I'm
	subscribed to as cleartext-signed message.  The body of the
	message was modified in two generations of distribution and the
	signature rendered invalid.  This is not immediately apparent as
	messages which are cleartext- signed must be verified as a
	separate, manual, step.  In the case of security exploits and
	announcements, such verification and authentication is of some

      - The underlying content is clear.  For a mailer with no MIME
	support (largely some old Unix command-line tools), you'd see
	the entire message with additional, text, MIME headers.  The
	message body itself is clear and human readable for a signed
	message (naturally the encrypted message would be unreadable). 

      - It's not the root problem.  The root problem is mail clients
	which handle untrusted content in an insecure fashion.  This is
	like dousing 75% of the population with gasoline, then placing
	match-confiscating personnel at the doors of all public arenas.
	The problem isn't the matches.  It's the gasoline.

	Palliative measures to reduce the apparent risk without
	addressing the actual cause mask the problem without fixing it.
	If sufficient people feel the pain, we'll eventually see changes
	either to client behavior or choice.

So Where Can I Find RFC 2015/3156 Compliant Mailers

    For lists:


    MUA implementations of RFC 2015:

	GNU/Linux / UNIX (most also ported to other platforms via
	compatibility kits such as Cygwin, UWIN, MKS, MS Unix Services
	for NT, etc.)

	    emacs (through various mail extensions), exmh, ishmail, mew
	    (an emacs mail reader), mutt, premail (Netscape plugin),
	    Gnus 5.6.45 with TM and Mailcrypt, KMail, Mixmaster 2.9
	    (internal mail reader), Sylpheed 0.4.63, TkRat, XCmail,
	    XFMail 1.3.

	Legacy MS Windows, Macintosh, and other platforms.

	    Claris Em@iler with PGP 5 (?), Datula (plugin), Edmax
	    (plugin), MS Outlook Express (plugin), MS Outlook (plugin),
	    Mulberry (plugin), PMMail (native), Qualcomm Eudora (full
	    and light version for Windows and Mac) since version 3.02
	    with PGP 5.5.3i and 6.0.2i Plugin, Turnpike (native), Voodo
	    on Amiga.

Got Any Funny Clueless Luser Stories For Us?

    Funny you should ask.

    One particularly illuminating response I've receive runs more or
    less as follows:

	My company's MIS department has recently configured the email
	system so that if an email has suspected attachment, it will not
	be delivered.  Instead, the recipient gets the following

	    This message uses a character set that is not supported by
	    the Internet Service.  To view the original message content,
	    open the attached message.  If the text doesn't display
	    correctly, save the attachment to disk, and then open it
	    using a viewer that can display the original character set.

	If you try to save it as instructed, you will see another


	I keep getting empty emails as the result of this



	<name deleted to protect the lusers>

    This prompted the following response from me:


	So let me get this right.

	You use a mail client which allows, among other things,

	You use a mail client which, among other things, includes
	executable content to be sent as attachments.

	You use a mail client which, among other things, *automatically
	executes* this content, without verifying its source or asking
	for user intervention.  As an added bonus, there is content
	which *does* require the user to launch it but:

	  - Mail and/or OS features disguise the fact that the
	    attachment is, in fact, an executable, by hiding such
	    extensions as might actually reveal such a fact.

	  - A file content coding scheme (file extensions) which is
	    bypassed by the fact that a program can be coded to open
	    content which should be safe (say, a text or RTF document)
	    but then proceeds to allow execution of unsafe content
	    within it (MS Word macro viruses).

	  - There is no ready tool for looking at the raw (text/binary)
	    form of the attachment to determine its true Buddha nature.
	    I've got raw text and binary viewers at my fingertips, and
	    use them.

	  - OS features and security  are such that unprivileged users
	    can wreak havoc on their own systems, networked storage, and
	    other users systems, without protections afforded by sane
	    filesystem security, user permissions, and file

	  - OS and application features are such that users routinely
	    send, and are expected to utilized, arbitrary content, much
	    of which may be executable.  Which might be translated as
	    "the user is an idiot", but is conditioned by the fact that
	    the user has been trained that acting like an idiot: running
	    arbitrary software, or engaging arbitrary methods, which may
	    or may not include executing code, on arbitrary content, is
	    not only a perfectly acceptable standard of operation, but
	    _is required to perform basic job functions_.

	  - In order to compensate for all these "features", your system
	    administrators have seen fit, in their divine wisdom, to
	    extricate all attachments from email.  Including such
	    attachments as might actually serve to provide some level of
	    authentication as to whether or not the source of a
	    particular email is who it claims to be, and possibly even a
	    trust level associated with this.

	And this is now a problem for third party sites to deal with on
	your behalf?

	I'm sorry.  I don't follow the logic.

	This is your problem, not mine.

	If you're going to strip all such features from your email, why
	don't you just go back to a plain text mailer and stop asking
	the rest of the world to please stop passing bombs your way with
	fuses you insist on lighting.




    Some additional informational resources for your benefit:

      - RFC 2015, "MIME Security with Pretty Good Privacy", M. Elkins,
	October, 1996, http://www.rfc-editor.org/rfc/rfc2015.txt 
	Spells out the standards for encrypted and cryptographically
	signed email.  Note that signature-as-attachment is required by

	Note also that munging the content of multipart/signed messages
	violates RFC2015.  This addresses issues with several broken
	mailing list management software packages.

      - RFC 3156, "MIME Security with OpenPGP", M. Elkins, et al,
        August 2001, http://www.rfc-editor.org/rfc/rfc3156.txt
	Updates the 2015 standard.

     -  For a list of mailers supporting RFC2015, see:

     -  For information on GnuPG, the GNU Privacy Guard, see

Copyright (c) 2001, Karsten M. Self <kmself@ix.netcom.com> 
This document may be freely distributed with attribution.

Thank you.

Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
   Support the EFF, they support you:  http://www.eff.org/

Reply to: