--On Saturday, 13 July, 2002 12:04 +0900 Dave Crocker
<dcrocker(_at_)brandenburg(_dot_)com> wrote:
- consideration of relay
Facsimile is direct, point-to-point. The sending device and
the receiving device are connected to each other at the same
time. They talk with each other directly.
Internet mail is store-and-forward. The sender and the
receiver are not required to be connected to the Internet at
the same time. The email may go through intermediate email
services, when moving from the sender to the receiver. (For
example, it may go from a department's SMTP mail system to the
enterprise system; the enterprise system may send it to the
receiving enterprise's system; the receiving system may then
send it to the receiver's department email server.) This is
like packet switching. Each intermediate system is "relaying"
the email.
It is like packet switching except, of course, in the packet
case, each packet is typically a fragment or component of a
message. The message, or data stream, is sent one packet at a
time; it is not completely assembled at each intermediate host
and then forwarded after it is complete. With email, each relay
host obtains, assembles, and stores the entire message, only then
initiating a new transaction to forward it. That difference is
significant for a few purposes, insignificant for most, but we
should be careful to not push analogies to packet-switching too
far.
The primary difference between relaying versus direct is that
relaying might take much longer. Therefore the sender does not
know when it will receive a response.
I would disagree. The primary difference I see between relaying
and direct is that, in a direct arrangement (characteristic of
e.g., HTTP) the originating sending system can ask the ultimate
receiving one a question by, well, asking. In the relay case,
such questions can only be asked of an intermediate system, which
must respond based on indirect information (which it finds in a
database, see below) or by acting as proxy for a remote system,
using information it has not obtained yet. Some illustrations:
Q: Can mail be delivered to this address?
Direct answer: "yes" or "no"
Relay answer: "I have no idea, but I will accept
responsibility for the mail and promise to forward it to
someone else who will accept responsibility. For each of
us, we understand that "accepting responsibility" means
that we will either deliver the mail to the final
recipient, deliver it to someone else who agrees to
accept responsibility, or return an error message which
will, of necessity, come out-of-band relative to the
original connection".
Note: contrast this with TCP, where the packet-switching
model and the nature of the protocol permits getting the
possibly-analogous "yes, the destination host will accept
traffic on that port" answer back before any data packets
are sent.
Q: Does the recipient support this data format?
Direct answer: "Yes" or "How about one of the following?"
Relay answer 1: "The database says you should try..."
(see below)
Relay answer 2: "I don't have a clue, but I will accept
the message on the assumption that it does, and pass it
on, either to that destination or to some other site
willing to take responsibility. If it turns out the
recipient cannot accept the format, I (or one of the
systems to which responsibility has been passed) will
(preferentially) convert the format to something that can
be accepted or (less preferred) bounce it with an
out-of-band message."
Those seem fairly different to me, much more different than
"slower". In fact, I think that difference is part of what this
discussion is about: if the only difference were "might take
longer", I don't think we would be having this (part of) the
discussion at all.
john
A footnote on the "find out from a database" issue. The more I
think about it, the more I conclude that the database lookup
(LDAP or otherwise) is the only rational way of implementing the
desired functionality here in a case that might involve relaying.
To the extent that speedy and confirmed delivery are often cited
as important values in fax, the "maybe it will get delivered as
requested, maybe it will be downgraded, maybe the format will be
influenced by the format requirements of other recipients, and
maybe the message will be bounced in a form that is hard or
impossible for the originating (or early relay) MTA to detect"
alternatives are unreasonable.
But, if database lookup is the only plausible implementation that
is consistent with the underlying design requirements, then we
should not be looking at capabilities negotiation in the SMTP
stream. Instead, we should be looking at a piece of protocol by
which the sending system (probably the MUA, rather than the MTA)
can figure out the capabilities of the recipient(s) and then
prepare the message, make address grouping decisions, etc.,
cleanly. It seems to me that would be more clear, would put the
responsibility back on the MUA or local system which has maximum
information about sender intent, would avoid layering violations
and other complications, and generally be a cleaner and more
efficient model.