vesely at tana
Jan 23, 2008, 7:13 AM
Post #7 of 7
Frank Ellermann 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 control this.
> In the real world a user responsible for the "info"
> account at A arranged forwarding to "staff" at B.
I proposed "perpetrator" as a term to designate that user.
However, "data controller" or just "controller" may be a
better term, since it is used in some European privacy
directives and it's useless to reinvent the wheel.
"data controller" shall mean any natural or legal person, [...]
that is competent, also jointly with another data controller,
to determine purposes and methods of the processing of personal
data and the relevant means, including security matters;
For more definitions, ("data subject", "persons in charge",
etc.), see e.g.
What looks reasonable in those directives, is that either
the admin or the controller should provide some means for
the data subject (the owner of the forwarded-to address)
to inquiry, modify or delete the relevant data.
> 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.
Providing full control is not quite feasible. If "x"'s
and "y"'s policies differ, A cannot simultaneously apply
both. Thus, the controller of "staff" should mediate in
order to make a possible arrangement.
IME, as your description implies, in the real world those
settings are configured manually. Along the path to an
ideal world, a good point would be to establish a way to
inquiry, modify or delete those configurations.
>> 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.
Traditionally, unprivileged users are not even allowed to
use sendmail's -f switch to change the MAIL FROM address.
A compliant forwarding mechanism should provide for
whitelisting A at B and B at C. That is particularly
difficult because it requires the admins of B and C to
"trust" A and B, respectively.
Because that is the point where forwarding gets broken, I
think we should make an attempt at fixing it. Michael
mentioned an "U"-protocol for simultaneously fixing backup
MXes. I only have vague ideas about how that might work,
but discussing it here perhaps we'll get a better focus
and eventually specify, implement and test it, if we see
> 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.
That's how it currently is. However, allowing that "trust"
to A from the POV of B is not quite like giving A carte
blanche. It would just imply that A will forward some mail,
which it would do as an unknown stranger in case B won't
grant it the possibility to do otherwise.
The trust may be specific for staff[at]B, or it may be for
any user at B in case A is a backup MX of B. If we want
that backup MXes keep a database of user mailboxes, that
doesn't really change much.
Granting the trust may allow B to verify that A acts
correctly and blacklist it if not. Once blacklisted, a
B-admin's manual intervention might be required to let
A send mail to _any_ B's user. (Auto-blacklisting.)
Another advantage is that links may be prepared to allow
"staff" to inquiry, modify or delete that forwarding.
Adding some control over A's acceptance policy would be
a plus. A should declare its capabilities when it applies
for the trust, B may require that specific capabilities
be enforced or relaxed for future messages to staff[at]B.
Info[at]A becomes known to "staff" as the address that the
spammers harvested, in case of spam reports.
When C, D, or E grant forwarding trust to B, any link and
control information might be transferred too, so that "x",
"y", and "z" become aware about info[at]A. Just sketching.
> 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.
But A and B may earn a bad reputation as a consequence.
Sender Policy Framework: http://www.openspf.org
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=88939798-e78c68
Powered by Listbox: http://www.listbox.com