Re: [spf-discuss] Instead of ADMD, MON, MRN ...

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