I don't think multi-hop is exactly the problem. I don't really see serious
difference between calling it one-hop or multi-hop as long as actual hop is
well defined. We'll always have remailing/forwarding servers - mailists
is one example of that and its not going aways (I hope...). So with mailing
list this all becomes originator->origMTA->intermediateMTA(listserver)->
recMTA->receiver. There is also a question of certain networks being
separate from each other and only acecssible through gateways.
What I do think is that when *originator* submits messages to *origMTA*
this MTA should decide where to route the message (preferably directly to
endpoint), then it creates possible envelope AND checks that the destination
as per its envelope would accept the message (i.e. it transmits this envelope
and and waits for approval or does goes through some necessary authentication)
if the transmission is accepted, then rest of the message is transmitted.
This routing MTA if its not yet destination will now create its own envelope
and put the envelope it received in the tracking part of this new envelope
(call it repackaging, i.e. you received the letter, without opening it
with its original envelope, put into new one and send it futher although
the reality might also look more like you received the letter, took out
its content cut out the original envelope's portion with address and put
this all into new envelope). This all can repeat several times until it
reaches the actual recMTA where the user will pickup this letter, but as long
as we have the part about tranmission and authentication between MTA well
defined we don't have a problem
On Fri, 13 Feb 2004, Paul Hoffman / IMC wrote:
This may or may not be controversial, but I propose that a
requirement for sane operations is that mail-ng be single hop.
Multi-hop was a good design 20 years ago when many entities were not
online all the time, but it has also proven to be a huge hurdle in
extending SMTP.
From an operational standpoint, a single-hop design makes many other
parts of the design much cleaner. It is also easier to explain to
users.
Of course, if the receiving MTA wants to re-send a message to another
MTA instead of writing it to the message store, that's fine. However,
doing so is not part of the specification. That is, the protocol
specifies just originator->origMTA->recMTA->receiver or
originator->recMTA->receiver, but does not specify
origMTA->otherMTA->recMTA.
--Paul Hoffman, Director
--Internet Mail Consortium
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net