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=2183229&id_secret=85469177-394fb5
Powered by Listbox: http://www.listbox.com