David MacQuigg wrote:
A/B Roles A and B both played by the same Actor
I'd use "Agent" rather than "Actor" for specifying an entity that is
either a client or a server, as it is more commonly used in that sense.
--> Direction of mail flow (no relationship implied)
==> Direct relationship between Actors (e.g. a contract)
~~> Indirect relationship (e.g. both directly related to Recipient)
/ cooperating agent on the same box
Simple Setup with four Actors:
|---- Sender's Network -----| |-- Recipient's Network -|
/
Sender(s) ==> MSA/Transmitter --> / --> Receiver/MDA ==> Recipient
/
Border
Simple Forwarding is quite common:
|-------- Recipient's Network ---------|
/
--> / --> Receiver/Forwarder ~~> MDA ==> Recipient
/
Border
While that diagram is correct when Forwarder ~~> MDA uses the LMTP
protocol, more commonly there is an MTA listening to the Forwarder,
thus that should rather be Forwarder ~~> Receiver/MDA.
Chain Forwarding should be discouraged:
|------------ Recipient's Network ------------|
/
--> / --> Receiver ~~> Forwarder(s) ~~> MDA ==> Recipient
/
Border
It is not much different than the previous case, and there may be
legitimate uses of that schema.
Open Forwarding must be banned:
/ / |-- Recipient's Network -|
--> / --> Forwarder --> / --> Receiver/MDA ==> Recipient
/ /
Border Border
A second border is not possible, if we define the border as the point
across which mail is relayed without any specific arrangement or
agreement. That means a messages is sent through a border because
the domain in its RCPT envelope address indicates the relevant
Receiver as the MX in the global DNS.
Inside a MON one could run a faked DNS that arbitrarily assigns some
smart host to any external domain's MX record, for the mere purposes
of running existing MTA software without having to configure specific
routes for each mail server inside the MON: this _is_ a kind of
contract.
Looking up an alias is obviously some kind of contract.
Therefore the uniqueness of the border is a consequence of the
uniqueness of the MX. If there are more MXes on a given message's
path, the border lies before the first one. Indeed, establishing a
backup MX is some kind of contract.
Actually, what must be banned are Forwarders that just replace the
envelop RCPT address (a.k.a. alias-expansion.) Having a forward
address configured somewhere is certainly some kind of contract. The
recipient cannot verify, inquiry, modify or delete the configured
value. It is not clear where DSNs should go. That's why it is broken
and must be banned.
******************************************************************
Responsibilities assigned to each role - Rev. 0
This part is quite rough. It may help understanding what each role
means, but isn't really necessary for that purpose.
MDA - Mail storage and Distribution Agent
I'd stick to "Mail Delivery Agent." The role description below does
not quite fit in with the standard description given, e.g. in rfc5068.
Perhaps some of my comments above originate from this misunderstanding.
- Authenticate upstream Agent
- Sort and store messages
- Provide access for Recipients
- POP3, IMAP, Webmail
- Manage Recipient accounts/options
- Relay spam reports to Receiver (or don't accept them)
-------------------------------------------
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=89826074-e04e21
Powered by Listbox: http://www.listbox.com