The Famous Brett Watson
2006-01-25 16:46:34 UTC
In my previous message to this list, I mentioned that I am working on a
mail system as part of a PhD thesis. I've been contacted off-list and
mildly berated for being a tease; told that I should share a bit about
it. I don't pretend to be IM2000 incarnate, so I don't consider it
appropriate to discuss at length here, but I'll provide a summary of
what it is. Interested parties can contact me off-list should they wish
to do so.
The first principle of IM2000 is, in a nutshell, "mail storage is the
sender's responsibility." My first principle is a generalisation of this
to cover resources and control in general, such that the recipient gets
to call nearly all the shots. The sending party wants mail to be
delivered: it should go about this task by making that want known to the
recipient (including the limits on its willingness to participate), and
supplying the recipient with the means to drive that process should it
be interested in doing so.
This pattern of behaviour, in which the initiator submits a proposal and
the target executes it if it agrees, can be applied to protocols in
general. Indeed, I submit that it *must* be applied to protocols in
general on the open Internet to limit the potential for abuse. This
arises from a certain model of abuse based around consent, which I can
rant about at length on demand.
I'm currently implementing the first stage protocol, intended for use
between hosts with no established trust relationship (the real problem
case -- inter-domain mail, basically). With this protocol, the sending
MTA invites the receiving MTA to fetch mail. Nothing is said about the
messages themselves at this point: it is merely implied that the sending
domain has mail for the receiving domain.
DNS records are checked by both parties to ensure that the servers are
legitimate representatives of their domains. If the receiving domain
accepts the invitation, it provides an authentication token (a one-time
password) so that it may call back the sending domain and be recognised.
This protocol, as currently specified, operates over UDP. A typical
exchange will involve six packets (three round trips) if the invitation
is accepted and no packets are lost or delays encountered. I consider it
very important that this protocol be lightweight.
This approach could be applied to the existing mail system by using the
protocol just mentioned to establish an ODMR session (which is
essentially recipient-initiated authenticated SMTP). I consider this
insufficient for a number of reasons, and I don't intend to use SMTP in
any form, ultimately. I do intend that the total process be
inter-operable with the existing mail system, and able to replace it in
an incremental manner, however.
This summary is far from comprehensive, but the system is a work in
progress, and I'm still changing my mind about things. What I've
summarised here is the part that's least likely to change.
If you have further questions on this work, please feel free to contact
me at <***@gmail.com>. I expect it to be a work in progress
until at least the end of 2006. If there is broad interest, I'll set up
some kind of mailing list or website or suchlike. I do hope to develop
this thing to the state where it is practically adoptable, but it has to
be a PhD thesis first, so don't hold your breath: "running code" isn't
usually going to be my first priority.
I should also mention that whatever code I produce is very likely to be
Perl, just because it's the language in which I'm most productive. It
will be open source.
Regards,
TFBW
mail system as part of a PhD thesis. I've been contacted off-list and
mildly berated for being a tease; told that I should share a bit about
it. I don't pretend to be IM2000 incarnate, so I don't consider it
appropriate to discuss at length here, but I'll provide a summary of
what it is. Interested parties can contact me off-list should they wish
to do so.
The first principle of IM2000 is, in a nutshell, "mail storage is the
sender's responsibility." My first principle is a generalisation of this
to cover resources and control in general, such that the recipient gets
to call nearly all the shots. The sending party wants mail to be
delivered: it should go about this task by making that want known to the
recipient (including the limits on its willingness to participate), and
supplying the recipient with the means to drive that process should it
be interested in doing so.
This pattern of behaviour, in which the initiator submits a proposal and
the target executes it if it agrees, can be applied to protocols in
general. Indeed, I submit that it *must* be applied to protocols in
general on the open Internet to limit the potential for abuse. This
arises from a certain model of abuse based around consent, which I can
rant about at length on demand.
I'm currently implementing the first stage protocol, intended for use
between hosts with no established trust relationship (the real problem
case -- inter-domain mail, basically). With this protocol, the sending
MTA invites the receiving MTA to fetch mail. Nothing is said about the
messages themselves at this point: it is merely implied that the sending
domain has mail for the receiving domain.
DNS records are checked by both parties to ensure that the servers are
legitimate representatives of their domains. If the receiving domain
accepts the invitation, it provides an authentication token (a one-time
password) so that it may call back the sending domain and be recognised.
From this point on, the recipient acts in a client role, and the sender
acts in the server role, which is the reverse of SMTP.This protocol, as currently specified, operates over UDP. A typical
exchange will involve six packets (three round trips) if the invitation
is accepted and no packets are lost or delays encountered. I consider it
very important that this protocol be lightweight.
This approach could be applied to the existing mail system by using the
protocol just mentioned to establish an ODMR session (which is
essentially recipient-initiated authenticated SMTP). I consider this
insufficient for a number of reasons, and I don't intend to use SMTP in
any form, ultimately. I do intend that the total process be
inter-operable with the existing mail system, and able to replace it in
an incremental manner, however.
This summary is far from comprehensive, but the system is a work in
progress, and I'm still changing my mind about things. What I've
summarised here is the part that's least likely to change.
If you have further questions on this work, please feel free to contact
me at <***@gmail.com>. I expect it to be a work in progress
until at least the end of 2006. If there is broad interest, I'll set up
some kind of mailing list or website or suchlike. I do hope to develop
this thing to the state where it is practically adoptable, but it has to
be a PhD thesis first, so don't hold your breath: "running code" isn't
usually going to be my first priority.
I should also mention that whatever code I produce is very likely to be
Perl, just because it's the language in which I'm most productive. It
will be open source.
Regards,
TFBW