On Tue, 2006-06-06 at 00:26 -0700, william(at)elan.net wrote:
On Mon, 5 Jun 2006, Douglas Otis wrote:
Actually, with the inclusion of the bh= header, the body can be checked
separately with DKIM. The just the hash of the body is signed.
Better then nothing at all but this is still rather limiting in
actually referencing entire body data. Current email system allows
to reference external mime parts and email servers add new mime parts
as well.
I see that as a plus. The entire body would be retained at the signing
domain and accessed with a hash value (see below).
If email becomes more reputation based, a call-back mechanism should
eliminate much of the risks associated with auto-executed malware.
It is not about malware - there are actually ways to get rid of it that
are fairly effective even now (most malware is easy to identify based
on common signatures).
But the filtering for the malware depends upon the DKIM signing domain.
The reputation of the DKIM signing domain must be good before attempting
to access the data section. The other benefit of this approach is it
will not require any DSNs. There is no need to bounce a message that is
never transferred.
The reality is that im2000 is generally alot better approach for email
infrastructure where you do not expect that every email would be
delivered.... The advantages are that it can offer:
1. More effective per-ip and per-domain filters which are similar
to current URI filters but here URL is that of data store.
SPF-like verification based on URL location starts to work
with no forwarding problems for multiple identities.
This is not a secure scheme. SPF "like" verification has a rather
serious packet amplification problem as well. Unlike IM2000, the entire
headers are included to allow verification of the DKIM signature.
Worrying about the Subject line becoming the spam is a secondary concern
at best, while also tossing out an ability to authenticate the message
when the subject line is part of the signature. Any summary scheme for
the subject line could be part of the MUA. Reputation prevents spam.
2. Zombies are no longer as effective as its necessary for such
systems to be able to receive incoming connections and not
only establish outgoing connections (as these systems must
also be accessible through DNS).
Zombies have no difficulty establishing their own (highly transitory)
DNS infrastructure. That too offers little protection.
3. Integrated email tracking - sender knows if email has been
picked up or not (possibly done all the way to MUA as IM2000
wanted, but I consider it to be an option and not default) and
sender can also cancel non-picked up message.
This could work on the suggestion being made as well.
4. Better multi-party delivery that is done on per-site basis
(this is related to current thread - on per-site common emails
to multiple recipients can have shared referenced body part(s)
and those can be retrieved by the site once and can be reused).
The concept in mind was to leverage efforts being made by the T10 group
on object storage to encompass the entire message body.
http://dl.alphaworks.ibm.com/technologies/osdsim/osdsim2.pdf
http://www.emc.com/products/networked/cas/index.jsp
http://www.lustre.org/
This product allows object storage where expiry of the data can be
included within the API, for example. Information retrieval would be a
hash of the information together with the hash of the hash and the file
instance time stamp, as an analogy.
5. Email messages that have multiple alternative content (i.e.
both HTML and text) is less wasteful on bandwidth as end-user
can have setting that only certain types of content is to be
retrieved. Similar works for messages with content in multiple
languages (end-site may even communicate what language ise
prefers like its done in HTTP). Also if end-site has policies
that certain attachments are not allowed those attachments
need not be retrieved.
In most cases the bandwidth saved would be rather small for a fairly
high amount of complexity. As the store remains at the sender, any type
of added authentication remains possible as separate elements are
retrieved (such as external MIME elements via RFC2017).
6. Other advanced security choices available once communication
between end-site and sender is possible...
Security would be part of any scheme. DKIM is a good starting point.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg