Re: Email System Model
2009-05-19 20:05:45
Alessandro Vesely wrote:
David MacQuigg wrote:
I'm looking for constructive criticism. If you believe the model is
oversimplified, give me an example of an important system that the
model should cover.
Backup MXes. Nowadays, having good connections and much spam, backup
MXes are avoided by the organizations whose networks would require to
outsource them (while primary MXes are contracted in.) Should
connections worsen, e.g. for solar activity[1], war, or terrorism,
those organizations may be in for a hard surprise.
I had hoped that a protocol for configuring forwarding would have
smoothly lent itself to also configure secondary MXes[2], so as to
kill both birds with one stone, but either I lack the brain resources
to see its simplicity, or it is by far more complicate than what I can
manage in my spare time :-(
The model at http://open-mail.org/MHSmodels.html is an
administrative-level model, not a relay-level model. We are modeling
Actors (Users and Agents) and their roles in an email system. Backup
MXs are relays under the control of the Receiving Agent, even if they
are actually subcontracted to a hosting service in another city.
To add a Backup Agent to the model, I would need to see an example of
how this might make a difference to any Actor interacting with the
Receiving Agent. Yes, there are many problems with backup MXs not
having current information on a sender's greylist status, not knowing
when the primary MX is back in operation, etc., but how is that
different than a Receiver Agent that simply fumbles its internal operations?
I also have suggestions (off list) to add a Mail Storage Agent and a
Webmail Agent. Again, I need to see an example where we cannot simply
consider these as machines under the control of the Delivery Agent. We
want to keep the model simple, but not oversimplify to the point of
missing something essential.
I went ahead and added Mediator to the Model. A fully-automated
Mediator could be treated as an Agent, but we will treat it as a special
kind of User, one that Receives, Processes, and automatically Resends a
message, perhaps to multiple new Recipients. This doesn't add much
complexity to our simple model. A system with a Mediator can be shown
as two simple systems connected at the User level by a Mediator
(Recipient/Author).
I have suggestions (off list) to avoid the plain-English meaning of
Actor and Agent, and use these words to mean only a machine or process.
I don't have any suggested alternatives, however, and ADMD will not mean
much to students. My preference is to use these words first with their
plain-English meaning, introducing the administrative-level model, then
explain that an "Agent" can also be a machine, and the acronyms MSA,
MTA, and MDA are commonly used for machines. I don't see a problem in
using the same name for a machine and an Agent operating that machine.
The few places where there might be confusion can easily be avoided by
spelling it out - MDA Agent, or MDA Relay.
I would like to avoid using the same name for *different* functions at
different levels. Thus, I would like to resolve a possible conflict
over the word Receiver. At the administrative level, a Receiver Agent
has certain responsibilities, including authenticating the Transmitter
Agent and other things related to its position at the Border (Edge of
the Internet). One Agent can perform both Receiving and Delivery roles,
but often there are two separate Agents. When that happens, the model
must show the Receiving Agent ahead of the Delivery Agent.
This conflicts with the latest rev of email-arch, Figure 3. The name of
the final relay was changed from Destination to Receiver. I don't
recall any discussion on this change, but I may have missed it. I think
Destination is a good neutral word that won't conflict with future
developments in email system modeling.
Many thanks to all who have made suggestions.
-- Dave
|
|