On Fri, 18 Jun 2004, Dave Crocker wrote:
F> I could
TF> (should?) more explicitly divide my addressing layer into the envelope
TF> addresses and the header addresses (2821 vs. 2822), and my content layer
TF> into human-readable header content and body content (2047 vs. 2045).
Addresses are an independent construct. They do not changed based on
the layer they are used in.
Indeed, but the way they are used does. The addresses in the envelope
often change while the message is being transported, even if they are only
subsetted; a more obvious change is aliasing. The addresses in the message
header are generally left alone, though they may be added to in the case
of re-sending; mailing lists and the Sender: header are an exception to
this rule.
TF> 5. Two levels of store-and-forward
...
TF> I generally agree. My main complaint is that the document assigns the
TF> functions to either the MUA or the MTA, despite the fact that they are
TF> frequently implemented by software that is acting in a different
TF> architectural role.
let's discuss the details of that view, because I think it works ok.
The catch is that it shows that MUA is, itself, potentially
multi-layered.
I don't disagree with you on the point of mailing lists. I do disagree
w.r.t. aliasing (an MDA function) and gatewaying & firewalling (MTA).
Perhaps your multiple MUA layers are called MUA and MDA :-)
TF> I think a more useful division is whether or not end-to-end responsibility
TF> for the message has been assumed, which is indicated by changing the
TF> reverse path, i.e. taking over interest in what errors may occur.
Well this certainly sounds like a perspective that has promise.
Still, I'm not sure I understand how to apply it. "Interest in what
errors may occur" sounds pretty clear, except I am not sure it helps
as much as it should. It suggests that the bounces role (and the
like) is an intermediary in the sequence, but it will might not be.
I'm not sure I understand that last sentence. The bounce handler only ever
gets involved if there's a problem, so they aren't an intermediary as
such. However there is usually some kind of agreement (which is outside
the scope of the protocols) between the sender and the bounce handler
about what to do in case of a problem. In the usual case where they are
the same person, the response is often to re-send with a correctly typed
email address. In the case of a mailing list bounce handler the response
might be to unsubscribe recipients that persistently bounce. Etc.
Hmmm. Perhaps the MSA is the stuff of the oMUA that pertains to
transfer and the MDA is the has the same role for the rMUA. So, the
instant a user hits send, the MSA module takes over?
I think that is right, yes. It means that the SUBMISSION protocol is used
inside a split MSA, though, which means that the lines joining up the
agents' boxes in the diagram don't correspond to Internet protocols.
E.g. a diagram of common implementations might be:
+----------------+
| originator MUA |
+----------------+
| client MSA |
+-------+--------+
|
SUBMISSION
|
+-------+--------+
| server MSA |
+----------------+
| client MTA |
+-------+--------+
|
SMTP
|
+-------+--------+
| MTA |
+-------+--------+
|
SMTP
|
+-------+--------+
| MTA |
+-------+--------+
|
LMTP
|
+-------+--------+
| MDA |
+----------------+
| message store |
+-------+--------+
|
IMAP
|
+-------+--------+
| recipient MUA |
+----------------+
--
Tony Finch <dot(_at_)dotat(_dot_)at> http://dotat.at/