Tony,
TF> I don't think Internet email has clear layering at any level :-)
we try to stay consistent with the spirit of the rest of the Internet
protocols...
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.
The issue with headers is not readability but what I will
euphemistically call "domain of discourse".
Envelope headers -- no matter where they are placed -- is about
message handling by the transfer service. User headers (or whatever we
ought to call them) are from the author to the recipient.
TF> Identities.
Having a discussion of identities, as separate from protocol layers,
was intentional. An address is the same, no matter the level in which
it is used.
TF> Yes, but hostnames are not email addresses are not message IDs. I also
TF> like being able to say to MARID people that assuming that a "from" email
TF> address (whether 2821 or 2822) has some association with the SMTP client's
TF> details is a layering violation.
unfortunately, the pressure of the spam problem is doing a remarkably
effective job at minimizing people's concerns about this, not just as
a matter of architecturalo purity but more importantly as a matter of
administrative and operational nightmare. Requiring an author to
register all the paths (MTA sequences) their mail will take does not
work for quite a few scenarios.
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. In the case of a mailing list, there is a third 'user'
involved, besides the originator and recipient (author and reader).
Namely there is the mailing list administrator. So, in effect mailing
lists create another layer above the basic one-way end-to-end transfer
model. (At some point we also have to deal with the iterative nature
of email, folding in the occurrence of responses and forwarding, to
formulate a more complete model of email as a human service.
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. (I'm
TF> being explicit about end-to-end responsibility versus hop-by-hop
TF> responsibility, because RFC 2821 talks a lot about responsibility of the
TF> latter kind, whereas careful discussion of the former kind of
TF> responsibility is relatively rare.)
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.
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?
TF> This distinction corresponds more
TF> closely to my understanding of whether the action is implemented by an
TF> MUA-line entity or an MTA-like entity. E.g. in the case of aliasing,
TF> end-to-end responsibility is not taken, so my distinction puts it on the
TF> MTA side of the line;
Again, I think we will find more productive if we view aliasing and
mailing lists as a function that is in the MUA world, doing something
higher level. In both cases, the mail gets delivered to a RCPT-TO
address, so one-way transfer and delivery is completed. These
additional function go beyond that.
TF> If I were to assign aliasing to an architectural
TF> component I'd give it to the MDA (c.f. section 5.2.5), and in practice the
TF> MDA is often a function of the MTA.
I'm fine with that, especially as I'm growing to view the MSA and MDA
Sounds reasonable.
TF> I think there are roughly two kinds of gateway, which should be kept
TF> more distinct in this document.
TF> Security gateways that do content filtering, but otherwise act like MTAs.
Those are called firewalls. Real gateways are about translation.
TF> OK. They're becoming so common that I think they are worth a mention. They
TF> seemed to fit into the Gateway category because of the sentence "When it
TF> connects environments that have technical similarity, but may have
TF> significant administrative differences, it is easy to think that a gateway
TF> is merely an MTA."
good point.
TF> 2.2 Domain Names
TF> "sub-names" should be "labels" perhaps?
I don't understand.
TF> The DNS RFCs refer to the compondents of domain names as labels. In the
TF> email specifications they are syntactically atoms. I prefer to use
TF> existing terminology where possible.
oh. now i understand. ok.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>