Subject: suggesting displaying processed message before sending + confirmation (cf. rfc 2368)

From: [email-masked]
Date: Wed, 10 May 2000 13:59:14 +0900

for reference, the following text is from the security considerations
section of rfc 2368:

   A mailto URL gives a template for a message that can be sent by mail
   client software. The contents of that template may be opaque or
   difficult to read by the user at the time of specifying the URL.
   Thus, a mail client should never send a message based on a mailto URL
   without first showing the user the full message that will be sent
   (including all headers that were specified by the mailto URL), fully
   decoded, and asking the user for approval to send the message as
   electronic mail. The mail client should also make it clear that the
   user is about to send an electronic mail message, since the user may
   not be aware that this is the result of a mailto URL.

   A mail client should never send anything without complete disclosure
   to the user of what is will be sent; it should disclose not only the
   message destination, but also any headers. Unrecognized headers, or
   headers with values inconsistent with those the mail client would
   normally send should be especially suspect. MIME headers (MIME-
   Version, Content-*) are most likely inappropriate, as are those
   relating to routing (From, Bcc, Apparently-To, etc.)

in a similar vein, would it not make sense to recommend that mail
clients display the encrypted or signed form of messages and ask for
confirmation before actually sending the message?  or at least
recommend providing the capability to do so.

i would guess there have been cases of people who thought they had
encrypted or signed a message before sending it, but it turned out
they hadn't.  i have a vague recollection of this being mentioned in a
recent pgp usability study (perhaps someone can confirm).

---

From: Werner Koch <[email-masked]>
Date: Wed, 10 May 2000 11:10:14 +0200

> recent pgp usability study (perhaps someone can confirm).

IMHO, an MTA which rejects unencrypted mails would be a better
alternative to protect against such kinds of failures.  It may look 
at some headers to detect ML replies and use a table of
addresses which are allowed to receive unencrypted mail.  Or reject
everything unless a special formed address is used (which the MTA
substitutes for the real address).

  Werner

-- 
Werner Koch				OpenPGP key 621CC013
OpenIT GmbH                             tel +49 211 239577-0
Birkenstr. 12                           email   [email-masked]
D-40233 Duesseldorf                     http://www.OpenIT.de

---

From: [email-masked]
Date: Wed, 10 May 2000 19:05:20 +0900

From: Werner Koch <[email-masked]>
Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368)
Date: Wed, 10 May 2000 11:10:14 +0200
Message-ID: <[email-masked]>

> substitutes for the real address).

that is indeed another (not necessarily mutually exclusive) option.

i presume you are referring to an mta on the sending client machine.
that is correct, right?

i think i would like a client that does both :-)

in any case, i think it would make sense to point out somewhere these
kinds of concerns -- hints for implementors.

---

From: Werner Koch <[email-masked]>
Date: Wed, 10 May 2000 16:28:47 +0200

> i presume you are referring to an mta on the sending client machine.

Sure.  The local /usr/lib/sendmail should do it.

  Werner

---

From: [email-masked]
Date: Thu, 11 May 2000 00:22:19 +0900

From: Werner Koch <[email-masked]>
Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368)
Date: Wed, 10 May 2000 16:28:47 +0200
Message-ID: <[email-masked]>

> Sure.  The local /usr/lib/sendmail should do it.

this sounds like you are assuming a unix system w/ sendmail.

what i'm a bit more concerned about is all of the windows and mac
clients that i have to look after for my users.  each of those clients
connects to an external smtp server to send mail (i think that is a
pretty typical setup, don't you?).  i'm not very happy about the idea
of messages being accidentally transmitted in the clear between the
client and the smtp server [*].  it seems like for those cases the
mail client should (perhaps also) be doing the checking.

as a side note, in fact the mail client which i am using already
supports a bit of "policy" w.r.t. replying to messages that were
encrypted -- sadly it isn't a mail client that my windows and mac users
will use :-(

[*] good reason to use ssh port-forwarding of the relevant smtp connection
i guess, but not everyone will be so lucky...