[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: notes on mailing binary objects
I think we should quickly note several things.
1. PEM-DEV@tis.com (subscription requests to email@example.com)
is a list related to an internet task force of some kind working
on Privacy Enhanced Mail in the RFC822 connect, to be carried in
the current RFC821 envelope without any mods to RFC821 or RFC822.
PEM is deliberately designed to be independent of its means of
PEM provides for public key encryption of keys and certificates
and DES encryption of the body of messages. I don't see any
reason for RFC821 to be modified for the intended purposes, so I
suggest that ietf-smtp should not take this task in its scope.
2. If you are seeking a "secure-mail-transfer-system" then you will
be designing yet another one to compete with the X.400(88)
standard which does provide for security measures inside the P1
(or MTA level envelope handling).
I strongly suggest that trying to start now to design, implement,
and deploy an entirely new start on such a system is a generous
waste of time and effort.
3. I note a considerable confusion in this list between extensions to
RFC821 and extensions to RFC822. I think this group should come
to grips with this issue soon, and resolve what its scope really
is. For example, why should RCF821(ext) be concerned with the
data types inside the body, as long as it has established that
there is some 8bit data inside the body which must be protected
and preserved in transfer.
Is this task force concerned with RFC822 extensions, or is it
limited to RFC821? I suggest that it be limited to RFC821.
Any structural changes to be made to the internal structure of the
body of a message should be dealt with as an extension of RFC822
(and its follow-on RFCs, of which there are several -- can someone
identify all the related RFC822 RFCs, just for the record?).
I know of RFC934 which defines an encapsulation format (with
delimiter codes and bit-stuffing techniques) which is widely ( but
not universally) used for forward messages and digests. RFC1154
provides a partially competing (with RFC934) scheme for placing
multiple body parts inside a single "main" body part. I recall
that there are some other minor extension RFCs, but I forget their