On Tue, 6 Jun 2006, Douglas Otis wrote:
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.
Its not about DKIM or other signature scheme, you can identify malware
right now quite effectively with existing tools and signatures I meant
are not crypto but virus pattern recognition signatures (which only need
to be tested against .exe and similar attachments). I'm also fairly
certain 99.999...% of email users have learned enough directly or
through friends to not open email attachments that need to be executed.
We'd have to wait for some research measurements, but I'd not be surprised
if virus infection rate through email is significantly on decline.
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.
Yes and that is the main point of im2000 - don't get what you dont want.
With crypto signatures the overhead to calculate hash is actually a lot
smaller then that required to do RSA, so in reality the crypto effort
itself would be almost the same. But anything that can be done with
non-crypto session authentication is going to have less overhead where
as cryptographic public-key signatures offer most advantages when two
end-nodes are not directly talking to each other.
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
SPF-like includes CSV is you prefer to hear that. And this has nothing
to do about your opinion on possible dns overhead with SPF which has
not shown up to be a problem, in fact this does not directly has to
do with SPF either. The scheme I mention verifies not the incoming
server connection but location of the message store based on store
address (for which in fact RMX or CSV would be better as far as their
design but the reality is that people will use SPF anyway including
for this). Very low overhead, effective and no forwarding side-effects.
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.
You're missing the point. Go work for ISP and you'll know that its a
lot easier to filter incoming ports end-users then it is to filter
outgoing traffic for those users (a lot more complaints for the later).
Necessity for DNS infrastructure is secondary and serves as extra barrier
for spammers to overcome which BTW makes identifying zombies easier as
you only need to monitor certain domains on regular basis (i.e. every 10
minutes for those "transitory" domains).
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://www.lustre.org/
That is OT to email infrastructure design and in any case no such
complexity is going to be there for most who use email.
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.
Its the other way around actually especially as far as attachments go.
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.
Encumbered, oversimplified and limited by design - a lot worth then
it would have been, have it been a full IETF design effect like MASS
was supposed to provide for (which is how IETF usually operates,
i.e. designing protocol in open basis at WG). It is only now being
fixed and those fixes can not fully change some of the limitations
deliberately put in the WG charter.
---
What I said is valid for any im2000-like scheme and its just a matter
of how much of the advantages the sheme can provide (i.e. if it can
fully take advantage of retrieval architecture or has limitations
that only allow some features to be useful).
But in any case I'm not going to bother on this thread against only
Doug as otherwise it can go on forever with same arguments and no
benefits to anybody.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg