Alessandro Vesely wrote:
Thus you meant
[...]
Thanks for fixing it, and also for quoting Keith's
original definition of MRN.
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.
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).
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.
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.
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.
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.
Frank
-------------------------------------------
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=88553649-d5248b
Powered by Listbox: http://www.listbox.com