Re: [spf-discuss] Instead of ADMD, MON, MRN ...
2008-01-22 20:50:50
Dave,
I ran into your wikipedia work on behalf of spf the other day - looks
good and your attached enhancements will make it look even better (clearer).
I agree with making the delineation of the sender's and receiver's
networks crystal clear. It helps in explaining to people who are
less familiar with how email works what is going on at a 30k level.
FWIW, looking at this message in a proportional font, the Sender's
Network does not quite reach the end of the MSA/Transmitter -->
/ entry. If you cut and paste into an ASCII editor with fixed
fonts, it looks great.
Best,
AlanM
The Commerce Company
TZ.Com - Travel Zippy
At 01:16 PM 1/22/2008, you wrote:
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/?&
Powered by Listbox: http://www.listbox.com
-------------------------------------------
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=88750099-d8b78c
Powered by Listbox: http://www.listbox.com
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [spf-discuss] Re: Forwarder whitelisting reloaded, (continued)
- [spf-discuss] Re: Relay, Frank Ellermann
- [spf-discuss] Instead of ADMD, MON, MRN ..., David MacQuigg
- Re: [spf-discuss] Instead of ADMD, MON, MRN ...,
WebMaster <=
- [spf-discuss] Re: Relay, Alessandro Vesely
- Re: [spf-discuss] Re: Forwarder whitelisting reloaded, Michael Deutschmann
- Re: [spf-discuss] Re: Forwarder whitelisting reloaded, Michael Deutschmann
- [spf-discuss] Re: Re: Forwarder whitelisting reloaded, Frank Ellermann
- Re: [spf-discuss] Re: Re: Forwarder whitelisting reloaded, Michael Deutschmann
- [spf-discuss] Re: Forwarder whitelisting reloaded, Frank Ellermann
- Re: [spf-discuss] Re: Re: Forwarder whitelisting reloaded, Alessandro Vesely
- [spf-discuss] DNSBL (was: Forwarder whitelisting reloaded), Frank Ellermann
- Re: [spf-discuss] Re: Forwarder whitelisting reloaded, David MacQuigg
- Re: [spf-discuss] Re: Forwarder whitelisting reloaded, Michael Deutschmann
|
|
|