Mailing List Archive

Frank Ellermann confused "left" and right" :-(

-------------------------------------------
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=1311532&id_secret=88456639-9a59c6
Powered by Listbox: http://www.listbox.com

Frank Ellermann wrote:
> Frank Ellermann confused "left" and right" :-(

Thus you meant:
> BTW, the latest state of the community page
> (with only one border) states that anything on
> the right hand side is one "MRN". I've no idea
> if that is what Keith meant when he coined the
> term.

Possibly not. His wording,

A Mail Reception Network (MRN) is a set of
MTAs that accept mail on behalf of a set of
mail domains and deliver each message to
each recipient's message store.

suggests that the set of domains is determined
beforehand, for all messages.

> When a "forwarder" enters the picture it is an
> MRN, so far it's clear. But to its right it's
> an MON sending mail over a second border to a
> second MRN.

David insists about the uniqueness of the border.
Perhaps that's not nonsensical as it may appear at
a first glance: There is no second border. The MTA
on the right of a forwarder may alias-expand each
recipient address and forward the message, but it
is still acting within that message's 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.

Making the union of all MRNs that a server may
serve can possibly result in the whole global
network. As configurations may change while a
message is being transported, we cannot even say
that the MRN can be determined in advance. As I
understand it, the point in determining where
the border lies is that spam should be stopped
there.

-------------------------------------------
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=1311532&id_secret=88508967-514939
Powered by Listbox: http://www.listbox.com

On Tue, 22 Jan 2008, Alessandro Vesely wrote:

> that the MRN can be determined in advance. As I
> understand it, the point in determining where
> the border lies is that spam should be stopped
> there.

No, the point in determining where the border lies is that forgeries detected
via SPF can only be rejected there. While forged implies spam, the converse is
not true (not forged does not imply not spam).

The problem of forwarders getting their reputation with a recipient sullied by
forwarding spam at the explicit request of same recipient is not an SPF
problem.

While all these ideas of new protocols to allow large ESPs to properly handle
forwarders (whether for rejecting on SPF or to avoid reputation problems as
with forwarding to AOL) are nice, the only simple SPF forwarding solution for
large ESPs that "works now" I've heard is the very simple "reject with 551" so
that the sender can resend to the real target address. This has the additional
benefit of obviously deprecating the forwarded address in the eyes of the
sender. If you *don't* want to deprecate the forwarded address, then set up a
proper forwarding relationship! Even if it means you have to setup your own
MTA instead of using gmail or aol.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
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=1311532&id_secret=88539771-f5878f
Powered by Listbox: http://www.listbox.com

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=1311532&id_secret=88551337-75290f
Powered by Listbox: http://www.listbox.com

Stuart D. Gathman wrote:
> On Tue, 22 Jan 2008, Alessandro Vesely wrote:
>
>> that the MRN can be determined in advance. As I
>> understand it, the point in determining where
>> the border lies is that spam should be stopped
>> there.
>
> No, the point in determining where the border lies is that forgeries detected
> via SPF can only be rejected there. While forged implies spam, the converse is
> not true (not forged does not imply not spam).

Yup, that's a more precise statement.

> The problem of forwarders getting their reputation with a recipient sullied by
> forwarding spam at the explicit request of same recipient is not an SPF
> problem.

Strictly speaking, it's not. However,

* forwarding (a.k.a. alias expansion) is broken since rfc 1123,
* even forwarding from backup MXes is broken because of spam,
* the MSA protocol is not universally practiced yet, and
* many postmasters set ~all or avoid SPF entirely because of forwarding
or submitting problems.

Because of the latter point, I think this list is a good place to also
discuss the former ones.

> While all these ideas of new protocols to allow large ESPs to properly handle
> forwarders (whether for rejecting on SPF or to avoid reputation problems as
> with forwarding to AOL) are nice, the only simple SPF forwarding solution for
> large ESPs that "works now" I've heard is the very simple "reject with 551" so
> that the sender can resend to the real target address. This has the additional
> benefit of obviously deprecating the forwarded address in the eyes of the
> sender.

This is good for all cases where the forwarded address is a leftover.
There are cases when the recipient wants to keep it. In some of those
cases the recipient doesn't want to disclose what the expanded alias.

> If you *don't* want to deprecate the forwarded address, then set up a
> proper forwarding relationship! Even if it means you have to setup your own
> MTA instead of using gmail or aol.

Yes, and that's where our discussion begins...

-------------------------------------------
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=1311532&id_secret=88937420-119d35
Powered by Listbox: http://www.listbox.com

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=1311532&id_secret=88939798-e78c68
Powered by Listbox: http://www.listbox.com