This is exactly the problem with the current model. SMTP *is* an
end-to-end system.
Says who? SMTP explicitly allows for source routing in addresses. This is not
something tacked on as an afterthought -- it is a well documented and
heavily used aspect of the protocol. The host requirements RFCs have
confirmed the status of routing in SMTP.
There's also percent hack routing, and UUCP routing, but I see no reason
for discussing these things here.
This means that right now, if a site accepts
delivery for a message, it has the means under normal circumstances to
deliver it - in essense offering that gaurantee.
Not true. The PP mailing list had a huge debate on this issue some time back --
I suggest you check the archives for that list if you're really interested.
This holds true for MX
forwarders.
MX simply adds more complexity to an already complex situation. The problem
would exist without MX. It is made more complex with MX.
When you use the word ``gateway'' there is a high
likelihood that you have violated that model.
I don't violate the model because there's no model of this type to violate.
The SMTP model is one that allows for routing without dragging gateways into
the picture. This fact alone means that not giving MTAs the authority
to convert message formats is a big problem because it leads to messages
getting caught in the "can't go forward can't go back" trap.
One more time... Suppose we have four systems, A8UA, B7UA, C8MTA and D7MTA.
(The meaning of the names should be self-explanatory.) Let's also suppose that
there's an MX record for A8UA that points at D7MTA.
Now suppose that a user on A8UA sends mail to @C8MTA:USER(_at_)B7UA(_dot_) A8UA
checks
the capabilities of C8MTA and sees that yes, that system is capable of
handling 8 bit mail. It sends the message in 8 bit format. C8MTA receives
the mail. It now checks to see if B7UA can handle 8-bit mail. It cannot.
Conversion by an MTA is not allowed, so C8MTA tries to return the mail.
It looks up A8UA and gets told to send the mail to D7MTA. D7MTA cannot
accept 8-bit mail. The message cannot go forward. It cannot go back. You
have to break a rule to get out of this box.
If you think this is unlikely, think again. If I change the names in
this example as follows:
RANDOM-BITNET-NODE.BITNET <--> A8UA
RANDOM-INTERNET-NODE.EDU <--> B7UA
RANDOM-BITNET-GATEWAY-KNOWN-TO-A8UA.BITNET <--> C8MTA
OFFICIAL-BITNET-INTERNET-GATEWAY.EDU <--> D7MTA
I claim this is more than likely, it is inevitable.
Now, you can unwedge this situation by adding, say, a lookahead step on
C8MTA (it should check the next hop). But no matter how you twist and
squirm, I can come up with scenarios that will cause these sorts of traps
to happen. Hell, I haven't even described one of more-than-average-complexity
yet.
Ned