>From: Dave Crocker <dcrocker(_at_)mordor(_dot_)stanford(_dot_)edu>
>Subject: Re: DMS RFP Bids
>Date: Mon, 11 Jul 1994 16:50:03 -0700
>(By the way, I enjoyed seeing the different between your From address and
>the one in your Sender field.)
Lets enjoy the previous exchange; it was fun. If I think of any
responses, Ill reply privately...
The point of this last item however is serious, and technical. And I
have been practising this addressing for some time with a variety of
addressing and routing forms. The move in the PEM-WG crowd seems to be to
abandon Distinguished Names from within certified data. Ok. So local
needs here require use to move back to the make-do X.400 1984 idea of
simulating names by imposing an attribute structure on the mail
addressing and routing fields. Then we keep rough compatibility
between the various registration schemes operating over the Internet
within the certificate. If implementations are to assume that
Certificate.subject content is a mailable address from your average
internet UA, then we best all make sure that it is!
That the Sender: and Reply-To: and From: fields are potentially,
logically different?
In DMS and all other organizational messaging concepts known to me, the
e-mail-object-identified message originator and the terminal-identified
electronic-message sender are rarely the same. One way to achieve this
denotation and distinction is to map the sending terminals identifier
onto the Sender: field, whilst the human originator is referenced in
the From: field. To some recipients my system is configured to also
supply the distinguished name, split between the comment in the RFC 822
From field, and the Organization field, expressed in Steve Kille's User
Friendly Naming syntax. (This helps out PEM to secure-X.400 gateways,
and related problems faced by the US military )
Now, I know I'm not a mailbox. mailboxes are distinct from the intended
recipient. When your vacation notification program decides to inform me
you are away for a week, shouldnt its identity be distinguished from
your own, particularly when protecting said outgoing mail with a
signature?!
Conceptually, shouln't the Mordor dept of Stanford university be making
such a statement - Daves not here today; call back later, signed
"mordor"?
Doesn't that then mean that the certicate accompanying the MIME-PEM
would be that of the MTA/mailbox, not that of the user? In DMS, the
messaging service will not accept the message for submission without
verification of origin in order to preserve access control rules. What
do we do, if We are wrong to do what we are doing? And still preserve
an organizational messaging security policy?