spf-discuss
[Top] [All Lists]

[spf-discuss] Re: Relay

2008-01-23 08:57:48
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.
http://www.cdt.org/privacy/eudirective/EU_Directive_.html#HD_NM_28
http://law.kuleuven.ac.be/icri/documents/privacylaw/chapter_01.php
http://www.privacy.it/privacycode-en.html#sect4

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
it fit.

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
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=88949163-beaacb
Powered by Listbox: http://www.listbox.com