How about we use
|---- Sender's Network -----| |-------- Recipient's Network ---------|
/
Sender(s) ==> MSA/Transmitter --> / --> Receiver/Forwarder ~~> MDA ==> Recipient
/
Border
This emphasizes who is actually in control of each network, and avoids the
problem Ale pointed out - the "MRN" including all possible relationships set up
by every Recipient, expanding to include the whole globe! When we say
Recipient's Network, we mean specifically the network of Agents set up by the
Recipient to handle his own mail.
The situation Frank describes doesn't fit this picture, but do we care about
such "networks"? There will always be idiots signing people up for mail they
didn't want, and email will never be reliable for those who are completely
clueless, but the people I care about are smart enough to recognize when
something is wrong and ask their admin to "fix it". We're not there yet.
At 07:16 PM 1/22/2008 +0100, Frank wrote:
Alessandro Vesely wrote:
Each hop within the MRN must result from a
previously established agreement.
Let's make an example. Message arrives at info [at]
A, forwarded by A to staff [at] B, alias-expanded
by B to x [at] C, y [at] D, z [at] E. B looks up C,
D, and E to find the corresponding MXes and sends
the message in the same way that the original MSA
would have done if the final destinations were
spelled out explicitly from the start. However,
x, y, and z, whether they are individuals, lists,
aliases or whatever, have a forward link configured
at B and thus they must be able to control it. In
particular, they should be able to also control
what policies A enforces.
In an ideal world they might be able to contol this.
This ideal is not too far off. It just needs a little push.
The "control" we mean is not detailed control over the policies of the
Forwarder, but simply the ability to terminate the Forwarding relationship if
those policies are not acceptable. The Forwarder is always the Agent of the
Recipient.
In the real world a user responsible for the "info"
account at A arranged forwarding to "staff" at B.
This user isn't necessarily an admin of A (or B).
Then A is a spam relay, and B should not have allowed it special Forwarder
privileges to staff at B.
The same user, or somebody else responsible for the
"staff" account at B, arranged the forwarding to
"x", "y", and "z" at C, D, and E.
Now B is also a spam relay, and should not have been given Forwarder privileges
to Recipients x, y, and z. Forwarding relationships should be set up by each
Recipient for their own mail.
It would be indeed bad if "x", "y", and "z" cannot
cut this odd forwarding at either A or B if their
mailboxes are flooded by spam to "info" at A. But
demanding that they have control over what policies
A enforces is rather far stretched.
See above regarding "control".
the point in determining where the border lies is
that spam should be stopped there.
Yes. And from the POV of the admins of B, C, D, E
(not to be confused with "staff", "x", "y", "z",
who might be ordinary users under thousands) their
inbound border is where an MX gets mail from an
"unknown stranger" like A or B.
The Border is determined by the Recipient, not the admin. If Recipient "x"
sets up Forwarding from B to his account at C, then the Border is no longer
between B and C. The admins of B and C need not be aware of this arrangement,
although they could certainly look at the user's setup and see it.
That some of their users, here "staff", "x", "y",
and "z", should know that A or B are no "unknown
strangers" for mails related to these accounts is
kind of beside the point for admins of B, ..., E.
Likewise the admins of A and B could tell their
users "info" and "staff" that all side-effects of
forwarding are a problem of those who use it.
Agreed. The instructions to Recipients should be simple: Whitelist any
domains you have set up as Forwarders. Do not click "This is Spam" on any
whitelisted messages. Such reports will be ignored.
-- 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=88593984-da9e51
Powered by Listbox: http://www.listbox.com