ietf-smtp
[Top] [All Lists]

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

<Prev in Thread] Current Thread [Next in Thread>