On Sat, Feb 07, 2004 at 02:25:51PM +0100, Andrzej Filip wrote:
Do you suggest sending all messages in one of the following formats ?
headers: envelope-headers
body: message/rfc822
headers: envelope-headers
body: multipart/signed
message/rfc822
pplication/pgp-signature
Not exactly. I'm not sticking to rfc822 or 2822, this might
be good or obsolete, which is to be discussed.
I suggest to give all message a structure of
- Control data (to be modified and extended by MTA)
- Payload (not to be modified)
| |
| |-- message header as generated by the original
| | sender of the message
| |
| |-- message body as mime type (maybe multipart)
|
|---- optional: Security related data such als
digital signatures, encryption parameters
or other authorization information (like RMX)
covering the main payload
I'd rather avoid PGP, or at least do not want to make
it default. I prefer the X509-SSL-PKCS-S/MIME world,
but we should not go into such details yet. That's a question of
implementation. At the moment it is better to leave this opaque
and to say 'Any security related record needed to protect the
payload'.
But it is not trivial to define which information belongs in which
header. For example, the author of the message should be mentioned
in the message header, while the sender (sometimes the same, sometimes
similar) should be mentioned in the envelope.
When transmitting a message to the next relay, the sending relay
should transmit the envelope and wait for an intermediate reply
whether the peer wants to see the payload (like we transmit
envelope sender and receiver in today's SMTP before BODY).
Another problem is the MessageID. For some reasons it would be
good to have the MessageID in the message header.
For other reasons, the MessageID should be unique and unambigous
and should precisely identify the message. It should be impossible
for any two distinct messages to have the same MessageID (for
synchronisation and resent elimination). It must be guaranteed that if
you have the MessageID then you also have the Message.
There's a well known solution: Cryptographical Hash Functions or
Message Digests, such as MD5 or SHA1.
Problem: You can't have the Hash of the payload within the payload.
So the messageID should consist of two parts:
- A randomly but unique chosen ID generated when writing the
message
- a hash value of the full payload.
The message header can - obviously - contain only the first part.
You can calculate the second part at any time.
When synchronizing messages or preventing the same message to be
transmitted again, both parts of the messageID are used, to
avoid a denial of service attack by different messages with the same
messageID.
This requires a payload which is never to be modified.
That's why I would split header information into a
static and a non-static part.
regards
Hadmut