spf-discuss
[Top] [All Lists]

[spf-discuss] Re: Forwarder whitelisting reloaded

2008-01-11 21:27:20
David MacQuigg wrote:

Should we show multiple Border(s)?

For an "interesting" scenario wrt MAIL FROM you need two.

We need to keep the basic diagram simple.

Depends on what you want to focus on, or if you intend to
use the same diagram for anything that's relevant for SPF,
PRA, DKIM, SSP, and BATV.

Showing all these possibilities could make the diagram 
much more complex, and less useful for communicating 
with non-experts.

Don't use Dave's mail-arch diagram for SPF, it won't help 
you, it has a completely othogonal view of "border" based
on different admins who can change things in their "ADMD".
And it's fairly complex.

I'm still concerned that we don't have agreement on basic
terminology.  Without that we can't have a productive 
discussion.

That's at it is.  The top-IETF experts supposed to know
what a mailing-list is have completely different ideas -
e.g. 2821bis + 2822upd don't justify to add Sender header
fields (more precisely they forbid it), nevertheless many
lists do something in this direction.

The problem with existing terminology is that there are
too many words for each thing or action (e.g. your use
in several places of the awkward phrase "forwarded /
relayed / sent" ) and too many different things using
each word (e.g. "sender").

Yeah, the "forward / relay / send" was intentional, and I
forgot "transmit" among others :-)  The "mail-arch" draft
and 2821bis *try* to offer some clearer terms, e.g. the
word "bounce" in 2821bis never means "reject", it means
"send non-delivery report to originator as indicated in
the reverse-path".

For the "mail-arch" draft that's not yet clear, I hope it
will use "envelope sender address" as the DSN RFCs, but
of course Dave hates this, it's too near to the 821 idea,
not his "bounces-to" view.

The SSP folks will replace their bogus "originator" not
compatible with mail-arch, 2822upd, etc. by "author" or
"first author".  I hope.  Of course they are not thrilled
to use correct terminologoy, with "originator" they could
pretend that SSP does something it clearly can't (as is).

Dfferent "terminologies" refelect different "ideologies",
as far as they're not only sloppy or shorthands or wrong.

And I think this isn't the list to improve it, we had our
chances with mail-arch and 2821-bis, to some degree we
used it:  2821bis is far better than 2821.  IMO it could
be still clearer about the problem of "backscatter", but
it's definitely better than 2821.

After that decision it can do whatever it needs to do
to deliver the mail in its "own" _receiving network_.
 
I assume _receiving network_ includes everything on the
receiver's side, from the Border MTA to the final MDA.

Yes, personally I like Keith's terminology, MON + MRN for
Mail Originating / Receiving Network.  Ignore all details
in the MON (=> business of the sender), and all details
in the MRN (=> business of the receiver), and especially
ignore the various ADMDs within MON or MRN.  

But that's not good enough for our discussions, we need
the fact that an MON is also an MRN (and v.v.) to send
those bounces back to the originator.  And we need a big
piece of Dave's terminolgoy ("mediator") for cases with
more than one border.  SPF only needs to worry about one
kind of "mediator", a "traditional forwarder", but Dave's
term "mediator" makes it easier to discuss modifications.

a Forwarder has a direct relationship with a Recipient,
who also has a direct relationship with the Receiver,
thereby forming an indirect relationship between the
Forwarder and Receiver

Were the forwarder might have no idea that the receiver
checks SPF, and the receiver might have no idea that the
forwarder is a forwarder, and the recipient has no idea
at all what this is about, he just clicked buttons... ;-)

Sure, I know what you mean.  And if TENBOX or whatever
allows forwarder and receiver to enter into a direct
relationship it's fine.  Recipient and receiver should be
interested that this works.  It's less obvious why the
forwarder should care about it.  And if he cares, why SRS
isn't good enough.

the _receiver_ only needs to make sure to check SPF
once, at the border,
We have a conflict here in the use of the word _receiver_.

Not really.  I started with the simple case (no forwarding),
and added "forwarding to a third party" as last step.  You
started with a forwarder as given, and used the "receiver"
where I said "third party".  Checking Keith's terminology:

       MON -> MRN + MON -> MRN
originator |  mediator  |  receiver
sender  1st|border   2nd|border 3rd party

 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=2183229&id_secret=85081077-0913d0
Powered by Listbox: http://www.listbox.com

<Prev in Thread] Current Thread [Next in Thread>