(changing the subject line since this has clearly drifted off
into a more specialized discussion).
Doug,
I'm not convinced of the merits of the general idea you are
pushing here, mostly because I still believe in the value of
mail systems with relay (or, if you prefer, store-and-forward)
capability. If one requires that one be online to receive
actual messages, with end-to-end connectivity to the sender's
mail holding store, then sites with no direct connectivity to
the Internet are out of luck and sides with intermittent
connections or very long delay connections (think about a lot of
developing areas on earth as well as the interplanetary problem)
are in bad trouble.
An important side-effect of the current mail model is that, if
the final delivery server is network-close to the intended
recipient, it doesn't make much difference to the recipient
whether mail flows into that server at gigabit bandwidth or at a
few kilobits/second or worse or it things flow only at 0300
local time. The only connections that are really
network-performance-sensitive are between the sending MUA and
the submission server and between the final delivery MTA or
message store and the mail-retrieving user. We've used those
properties to very good advantage in the past and, I believe,
will continue to use them to good advantage.
I share Dave Crocker's concern about deployment of replacements
for the current email model (see the article in the recent issue
of Internet Protocol Journal), but maybe it isn't impossible if
the need is significant enough and the solution doesn't make
other things worse (which I think yours may, but I haven't seen
enough of a proposal to evaluate).
One could preserve the relaying by turning message transmission
and delivery into a multiple-stage handshake:
* Message notifying recipient of availability
* Message from recipient to store asking for
transmission of the real message
* Transmission of the real message
but that would be a fairly complex piece of protocol work, with
attacks possible at each step.
I note that, while one would want to update its non-existent
security mechanisms before trying to use it today, the
capability of sending a message structured as
[...]
Content-type: multipart/???; boundary="foo"
--foo
Content-type: text/plain
Hey, Doug sent a message
--foo
Content-type: message/external-body
[...]
has existed since the very first MIME specification and has
never been significantly used. Maybe there is a message (sic)
in that for you; maybe not.
But the main point of this message is that, if you are serious
about this, generate an I-D that specifies all of the details,
analyzes the possible attacks and how you will repel them, and
so on. IMO, you have passed the point at which talking about
what you might propose is helpful. If the ideas have any
utility or applicability (even if that applicability isn't as
general as you believe), we need a real proposal not more
IETF-list traffic.
Just my opinion.
john
--On Thursday, 16 August, 2007 23:45 -0700 Douglas Otis
<dotis(_at_)mail-abuse(_dot_)org> wrote:
On Aug 16, 2007, at 3:10 PM, Keith Moore wrote:
I also think there might be some merit in holding mail on the
sender's outgoing mail server until the receiver's MX is
willing to deal with it, thus pushing more of the costs
toward the sender of a message.
The concept of holding messages at the sender could be a basis
for a change in SMTP for supporting this model, but at a
message granularity. The changes would be similar to that of
BURL but would be Transfer by Reference or To Be Read, TBR.
...
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf