Mailing List Archive

Mail System Terminology (was: Forwarder whitelisting reloaded)
Starting a new thread, as there seems to be some serious interest in this topic. Here is what we have so far for a Basic Mail Handling System.

/
Sender(s) --> Transmitter--> / --> Receiver --> Forwarder(s) --> MDA --> Recipient
/
Border

This is mostly an Administrative Level description, although the terms Transmitter, Receiver, and MDA are borrowed from the Machine Level description. We could use phrases like Receiving ADMD, or Mail Distribution Service, if the distinction is important. An MDA might handle such functions as mail storage, webmail, POP and IMAP access, virus removal, etc., and it seldom matters whether it is one machine or many.

A minimum mail system includes at least an MSA (Mail Submission Agent), a Transmitting MTA, a Receiving MTA, and an MDA. The MSA and Transmitter could be one machine, and the Receiver and MDA could be another. There are always at least two machines and a Border.

At 02:22 PM 1/13/2008 +0100, Alessandro Vesely wrote:

>FWIW, I wouldn't deem "transmitter" as defined in
>http://open-mail.org/3strikes/QnA.html
>is a useful term. Indeed, its definition implicitly refers to a boundary
>even though that doesn't transpire from the term itself --as it does, for
>example, in "MON", where "N" for Network implies a network boundary.

We could call it a Border MTA, but that could be either Transmitter or Receiver (using our new definition of Receiver, which I am starting to like better than my original definition).

>And it conflicts with the generic use of "transmitter" as the receiver's peer.

I don't see the conflict, particularly if we move the Receiver to the Border, rather than as I have defined it previously.

What I like about "Transmitter" is the understanding that it initiates communications, and it communicates with unrelated parties. This makes it unique among all the machines in our Basic Mail Handling System.

>David MacQuigg wrote:
>>Again, no recognition of a single, most-important Border.
>>Even worse from an SPF point-of-view, this diagram
>>implies there are "Transit ADMDs" with no relationship to
>>either side.
>
>Borders are particularly insidious for SPF. "ADMD" has different meanings
>when its administrative management affects DNS, IPs assignment, or SMTP
>configuration. In addition, large organizations are partitioned into
>internal subunits, which may wish to carry out SPF checking one against
>the other. I don't think we can pull out any useful topology from that.

Can we at least sub-divide the mess into an MON and an MRN, with a clearly defined Border? I really don't like the idea that there are Transit ADMDs, floating in cyberspace, not a part of either MON or MRN. I would call such networks ORNs (Open Relay Networks), to put them on the same level as MONs and MRNs. I don't think they belong in any legitimate mail system.

That's not to say we can't draw some "secondary boundaries" between the ADMDs on the Receiver's side, and discuss how to handle problems of miscommunication between these "independent" parties.

For example, I would like to see a well-publicized webpage listing email services that are willing to provide MDA services, and not screw up mail that has been forwarded. That isn't difficult technically, but right now there doesn't seem to be any motivation on the part of some big service providers. These services need to see some demand from their own customers, or even potential customers. It can't be just a few geeks complaining.

-- Dave

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=85468914-f2d4cc
Powered by Listbox: http://www.listbox.com