on Wed, Jul 25, 2001 at 04:04:35PM -0400, Adam Bell (abell@intersys.com) wrote: > Okay, so can anyone tell me what popular (to Debian Users) MUA > sends every single message as an attachment to an empty message? Assuming, as others have, that you're referring to GPG/PGP, and quite possibly my mail (in which case you'll have to have someone forward you a copy of this message), the short answer is: you're using a broken mailer. I've written a number of FAQs on topics which recur with annoying frequency, the GPG/PGP mail FAQ isn't complete, so I'm attaching a series of related draft documents that are going into it (a bit of insight into the mind of...um, somebody). Cheers. -- Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/ What part of "Gestalt" don't you understand? There is no K5 cabal http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org Are these opinions my employer's? Hah! I don't believe them myself!
A Short Rant / FAQ on the Subject of
Signed E-Mail and Public Key Infrastructure
Karsten M. Self <kmself@ix.netcom.com>
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.
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. In the latter case, 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.
- No, this isn't a virus, a bomb, a bug, a worm, or any other
executable code.
- 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.
There's an Internet standard, called a "request for comments", or RFC,
which covers MIME encoded encryption and signatures. This is RFC 2015
(more info below under "Resources").
While it 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 doens'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: inline
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.
You might ask why I insist on signing my mail. 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 passkey necessary to utilize it. Consider it the
equivalent of an electronic signet ring.
I've been active on the Internet for over fifteen years. I've had
dozens of email accounts, and have had my identity spoofed, publicly, in
front of those who know me well. By adopting the practice of signing
every piece of email I send, I'm establishing a practice of plausible
deniability in the event unauthorized communications are made in my
name. If it's not signed by me, your assumption should be that it isn't
*from* me. No, the system's not perfect, but it's a hell of a sight
better than nothing.
It's been suggested variously that I sign messages inline, or in some
instances, that mailing lists drop all MIME-encoded attachments. 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 importance.
- 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.
Pallative measures to reduce tha 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.
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 message:
>
> 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 message:
>
>
> <<< MIME ATTACHMENT STRIPPED >>>
>
>
> I keep getting empty emails as the result of this reconfiguration.
>
> Thanks
>
> Regards,
>
> <name deleted to protect the imbecillic>
This prompted a response:
<rant>
So let me get this right.
You use a mail client which allows, among other things, attachments.
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 extentions) 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 procedes
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 detrmine 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 havok on their own systems, networked storage, and other
users systems, without protections afforded by sane filesystem
security, user permissions, and file organization.
- 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.
</rant>
Resources:
----------
Some additional informational resources for your benefit:
- RFC 2015, "MIME Security with Pretty Good Privacy", M. Elkins,
October, 1996,
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2015.html , spells out
the standards for encrypted and cryptographically signed email.
Note that signature-as-attachment is required by RFC2015.
Note also that munging the content of multipart/signed messages
violates RFC2015. This addresses issues with several broken mailing
list management software packages.
- For a list of mailers supporting RFC2015, see:
http://www.spinnaker.de/mutt/rfc2015.html
- For information on GnuPG, the GNU Privacy Guard, see
http://www.gnupg.org/
------------------------------------------------------------------------
Copyright (c) 2001, Karsten M. Self <kmself@ix.netcom.com>
on Wed, Jan 24, 2001 at 01:23:47PM -0700, Michael (M_J_Thomas@Qwest.net) wrote:
> > From: <kmself@IX.NETCOM.COM>, Wednesday, January 24, 2001 12:58 PM
>
> > As some of you may have noticed, I digitally sign my email to SAS-L and
> > elsewhere. I've noticed that mail I've sent to SAS-L since
> > approximately Jan 21, 2001, has turned up with invalid GPG signatures.
> Karsten,
>
> Is this why your (and only your) emails sent to SAS-L are sent as
> attachments??
I'm special, aren't I <g>.
> I know that I am not the only one receiving only yours as attachments. With
> all of the subscribers to SAS-L, I find it odd that you are the only one
> that comes across like that......
>
> suggestions??
I'm using a combination of tools (mutt as a mailer, GPG as a signing
tool) which creates MIME attachments for both the body of the message
and the signature. Rendering of these attachments is a mail client
("email program") issue, and is handled differently by different
mailers.
FWIW, the message body content type is:
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 doens'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: inline
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.
Signature-as-attachment is required per RFC2015, dated October, 1996.
RFC's ("requests for comment") are the documents which the IETF uses to
specify Internet standards such as email (RFC822):
http://www.landfield.com/rfcs/rfc2015.html
Note also that munging the content of multipart/signed messages violates
RFC2015 -- speaking again to the current issues with SAS-L.
For a list of mailers supporting RFC2015, see:
http://www.spinnaker.de/mutt/rfc2015.html
For a fully RFC2015 complaint mailer, validation of signatures
(including fetching of public keys from a keyserver, if necessary) is
transparently supported. Hence, opening my own SAS-L posts presents me
with a note that the content, the identity of the signer, whether or not
the signature is valid (does the hash match the content and signature),
and whether or not the key generating the signature is trusted (have I
trusted it myself, or have a sufficient number of people I trust signed
the key). This latter is the "web of trust" in public key
infrastructure (PKI).
--
Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/
What part of "Gestalt" don't you understand? There is no K5 cabal
http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org
on Thu, Mar 08, 2001 at 01:25:39PM -0500, DRoe2 (droe2@earthlink.net) wrote:
> > I send signed email conformant with RFC 2015. You state that this is
> > "not supposed to be allowed on the list sans permission". Where do you
> > come by this information?
>
> I got that from the questions I asked the list mgr. in charge prior to
> signing on a few years ago. I was told that this was an ASCII list,
> (my eyes cannot take most HTML formatted messages) and that
> we were to not to include attachments, (v-cards were OK). That
> it was best to send the attachments to those who requested via e-mail.
Understand that there's a continuum between "plain text email" and
"proprietary attachments from hell".
MIME (Multipurpose Internet Email Extensions) is a standard mode for
encoding email messages. MIME attachments can be of various types, the
standard is defined in RFCs 1341 and 1521. The primary purpose of MIME
is to extend email capabilities beyond strict ASCII characters. This
includes not only binary data files, but also such simple things as
extended charactersets required to represent characters common in many
European languages, non-Roman alphabets Western, and extended Asian
alphabets. MIME encoding itself does not entail "attachement", it is
merely an encoding of email beyond the very basic stnadards established
in RFC 822.
If you'll examine closely my messages, you'll find that they consist of
nothing by standard ASCII, and while they are MIME encoded, the
presentation is inline quoted-printable. From the MIME headers of the
message you responded to, the main body of my message:
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
And the GPG signature:
Content-Type: application/pgp-signature
Content-Disposition: inline
The signature content itself is nothing but text:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6paVCOEeIn1XyubARAp3hAJ47cf2c09KPppKIqHjsV7kyNpKwOgCeNLiu
Vrj53rSDxMVNqpM3MUHLte8=
=7zhV
-----END PGP SIGNATURE-----
Regards quoted-printable encoding, RFC 1341 section 5.1:
The Quoted-Printable encoding is intended to represent data that
largely consists of octets that correspond to printable characters
in the ASCII character set. It encodes the data in such a way that
the resulting octets are unlikely to be modified by mail transport.
If the data being encoded are mostly ASCII text, the encoded form of
the data remains largely recognizable by humans. A body which is
entirely ASCII may also be encoded in Quoted-Printable to ensure the
integrity of the data should the message pass through a
character-translating, and/or line-wrapping gateway
Regards content-disposition (RFC 2183):
A bodypart should be marked `inline' if it is intended to be
displayed automatically upon display of the message. Inline
bodyparts should be presented in the order in which they occur,
subject to the normal semantics of multipart messages.
Finally, PGP (and GPG) signatures are governed by RFC 2015. I draw your
attention to sections 2, 3, 4, and 6.1, of this document:
http://www.rfc-editor.org/rfc/rfc2015.txt
Your mailer, sir, is broken. The problem is at your end, not mine.
Discuss the issue with your vendor.
--
Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/
What part of "Gestalt" don't you understand? There is no K5 cabal
http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
on Fri, Mar 23, 2001 at 02:05:32PM -0800, Huang, Ya (ya.huang@AGOURON.COM) wrote:
> I agree with Jack's comments, in my work, IT department
> has (just recently) reconfigured the email system, so that
> if an email has suspected attachment (signature as one), it
> will not be delivered. Instead, recipient get the following
> message:
>
> 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
> message:
>
>
> <<< MIME ATTACHMENT STRIPPED >>>
>
>
> I keep getting a few empty email as the result of this
> reconfiguration. I am still able to see those message,
> only if I go to http://www.listserv.uga.edu/archives/sas-l.html
>
> Thanks
>
> Regards,
>
> Ya Huang
<rant>
So let me get this right.
You use a mail client which allows, among other things, attachments.
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 extentions) 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 procedes 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 detrmine 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
havok on their own systems, networked storage, and other users
systems, without protection.
- 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 a perfectly acceptable standard of operation.
- 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.
This message clearsigned for your benefit. Just this once.
</rant>
- --
Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/
What part of "Gestalt" don't you understand? There is no K5 cabal
http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6u9HHOEeIn1XyubARAoUVAKCCIE7Ty2Zb9lLBtzNOBQlCeXrYRACbBWPE
+/CuPHoeIXWMLgL1I6YgdwA=
=U1Bh
-----END PGP SIGNATURE-----
on Fri, Mar 23, 2001 at 11:51:48AM -0700, Jack Hamilton (JackHamilton@FIRSTHEALTH.COM) wrote:
> Joe, I'd prefer that you silently drop all attachments and extraneous
> headers. There's little need for them, you won't have to worry about
> spreading viruses or clogging up mailboxes with huge binaries, and it
> will make more mail systems happy. Using DEMIME to move plain text
> attachements into the message body might be a good idea.
>
> If Karsten wants to sign his mail, he can use clear-text signing in
> the body of the message. A bit ugly, but it should work everywhere.
There's an RFC (2015) for management of signed messages. It's still a
draft standard, but is widely supported. LISTSERV currently has an
option to not munge (modify, and hence mangle the very sensitive content
hash) MIME-encoded data. The next release will support PGP-signed MIME
attachments natively.
As for dropping attachments and headers on account of misbehaving mail
clients, while I can sympathize and respect the numbers of the
ill-informed majority, 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 SANS alert of the BIND exploit of
the day was posted to the SVLUG mailing list 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 importance.
- 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.
Pallative measures to reduce tha 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.
I'd be open to restrictions on attachments of specific types, or over a
certain size. Proscribing use of inline-text is not advisable.
--
Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/
What part of "Gestalt" don't you understand? There is no K5 cabal
http://gestalt-system.sourceforge.net/ http://www.kuro5hin.org
Attachment:
pgpz772m49ZO8.pgp
Description: PGP signature