Return to appendixA.tex CVS log

Up to [CSRG BSD Unix] / 43BSD / contrib / mh / papers / trusted

Annotation of 43BSD/contrib/mh/papers/trusted/appendixA.tex, revision 1.1.1.1

1.1       root        1: % appendix A
                      2: 
                      3: \appendix{A}{An MH Session}
                      4: 
                      5: \tagdiagram{A1-1}{Sending Encrypted Mail}{sendmail}
                      6: In the following,
                      7: the user \eg{Marshall\ T.\ Rose} logged onto host \eg{udel-dewey},
                      8: wishes to send a message to a user known as
                      9: the \eg{UCI\ Portal} (a system maintenance account).
                     10: As shown in Figure~\sendmail, line~1,
                     11: the user first establishes a mapping between the name \eg{UCI\ Portal} and
                     12: the address {\tx uci@udel-dewey}.
                     13: Once this mapping is performed,
                     14: it remains in effect until the user indicates otherwise to the \TMA/.
                     15: When the \pgm{tma} program is invoked,
                     16: it consults the \TMA/ database to see if that user is known.
                     17: If not,
                     18: it contacts the \KDS/ to ask for the \KDS/ ID associated with the user.
                     19: If the response is successful (in this case, the \KDS/ ID is \eg{3}),
                     20: then the \TMA/ updates its database.
                     21: The \pgm{tma} program indicates in its output the \KDS/ ID associated with
                     22: the user,
                     23: along with all known addresses (in this case, only one).
                     24: So, once the name to address mapping has been described the user,
                     25: the user agent, \MH/, deals only with the address,
                     26: while the trusted mail agent deals with the name and \KDS/ ID aspects of the
                     27: user.
                     28: 
                     29: Next, the \pgm{comp} program is invoked to compose a new draft on line~5.
                     30: The user addresses the local user \eg{uci} in the To: field,
                     31: and indicates that a plaintext copy should be kept in the folder \eg{+outbox}.
                     32: After entering the subject and text of the draft,
                     33: the user enters \whatnow/ level on line~13.
                     34: At this point,
                     35: the user directs \MH/ to send the draft in encrypted form.
                     36: The resulting output is verbose (a default for \pgm{send} for this user)
                     37: but instructive.
                     38: Initially,
                     39: all addresses in the draft are verified on lines~14 to~17.
                     40: Two forms of verification occur:
                     41: first, the \MTS/ is asked to verify the address as much as possible.
                     42: For local addresses,
                     43: the \MTS/ decides if the name has a maildrop associated with it.
                     44: For remote addresses,
                     45: the \MTS/ decides if the host is known to it.
                     46: The second type of verification occurs with the \TMA/.
                     47: For all addresses,
                     48: the \TMA/ is asked if it can find a mapping from the address to a \KDS/ ID.
                     49: 
                     50: The reason \MH/ goes to all this trouble is a philosophical issue.
                     51: Since the copy of the encrypted draft is different for each recipient,
                     52: \pgm{post} tries to verify that all recipients can be successfully posted
                     53: prior to actually posting the different ciphertext versions of the draft.
                     54: This behavior is not optimal in terms of cycles,
                     55: but is perhaps ``correct'' from a \UA/ perspective.
                     56: 
                     57: Finally, the draft is actually posted, and the folder carbon-copy is filed.
                     58: 
                     59: \tagdiagram{A1-2}{Receiving Encrypted Mail}{recvmail}
                     60: Some time later, the UCI portal is informed that new mail has arrived.
                     61: As shown in Figure~\recvmail,
                     62: the \pgm{inc} program is run.
                     63: The \eg{E} prior to the date of the message indicates that \pgm{inc} has
                     64: detected the message to be encrypted.
                     65: Since the user did not inhibit \pgm{inc} from deciphering the message,
                     66: it proceeds to do so.
                     67: 
                     68: \tagdiagram{A1-3}{Message Prior to Decryption}{before}
                     69: \tagdiagram{A1-4}{Message After Decryption}{after}
                     70: Finally, it may be instructive to see what the encrypted message looked like
                     71: when it was delivered to the portal's maildrop,
                     72: and the final message after deciphering.
                     73: Figures~\before\ and~\after\ show these respectively.
                     74: In particular,
                     75: note that the \eg{X-KDS-ID:} field has been introduced in Figure~\after\
                     76: after successfully deciphering the message.
                     77: The presence of this field authenticates the sender of the message.

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.