spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Forwarder whitelisting reloaded

2008-01-11 19:14:04
At 08:56 AM 1/11/2008 -0700, Edmig wrote:
On Jan 10, 2008 11:18 AM, David MacQuigg 
<<mailto:dmquigg-spf(_at_)yahoo(_dot_)com>dmquigg-spf(_at_)yahoo(_dot_)com> 
wrote:
At 11:05 AM 1/10/2008 -0500, Stuart wrote:

C: MAIL 
FROM:<<mailto:bla(_at_)example(_dot_)com>bla(_at_)example(_dot_)com> 
AUTH=<http://forwarder.org>forwarder.org

You would want

C: MAIL FROM:<<mailto:bla(_at_)example(_dot_)com>bla(_at_)example(_dot_)com> 
AUTH=<mailto:mailbox(_at_)forwarder(_dot_)org>mailbox(_at_)forwarder(_dot_)org

A receiver might want to whitelist only selected mailboxes at 
a forwarder (e.g. their own).

You must mean a *recipient* might want to whitelist only their own mailbox.  
Receivers are often unaware of the forwarding arrangements made by recipients.

I wish we had a shared terminology for the various entities in an exchange.  
From this and other recent discussions on this list, I'm trying to build a 
mental picture of how this group views the transfer of a typical email.  Is 
this a good picture: 

Sender --> Relay --> /Border/ --> Forwarder(s) --> Receiver --> Recipient

I'm following Julian's use of "Relay" to distinguish an MTA on the Sender's 
side from the "Forwarder(s)" on the Recipient's side.  I have included the 
possibility of multiple Forwarders, but only one Relay, assuming any MTA's 
closer to the Sender really *belong* to the Sender, and don't add anything 
useful to the picture. 

Is this a good model, or at least good enough that we can use it as a basis 
for simple discussions, and clarify when we need to add something?

I like this diagram.  It will certainly help clarify our discussion on using 
HELO names.  As I understand it, the objection was that Relays often handle 
mail for multiple Senders, and we want to authenticate the Sender, not the 
Relay.  I suggest we include multiple Sender(s) in the diagram.

Good suggestion.  This does not add complexity to the diagram, and does capture 
an essential part of what we are discussing.

On Jan 10, 2008 9:54 PM, Frank Ellermann 
<<mailto:nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
wrote:
And the last case, that's what we are talking about here, is 
a non-local alias, where the receiver changes RCPT TO a 3rd
party, and forwards the mail across a *second* border, again
coupled with query=mx etc. as at the first border.  Because
this is a third party it can normally check SPF again, and 
for an unmodified

Should we show multiple Border(s)?

The *Border* in my definition is the one place where there is no relationship 
between sender and receiver.  I would leave these other boundaries out of the 
basic diagram, and add them as needed for a specific discussion.  We need to 
keep the basic diagram simple.

The same reasoning applies to "backup MX's" and other alternate paths that the 
mail might flow.  Showing all these possibilities could make the diagram much 
more complex, and less useful for communicating with non-experts.

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

At 05:54 AM 1/11/2008 +0100, Frank wrote:
Let's stick to the existing terminology, 

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").  We should either agree on a distinction between "relay" and 
"forwarder", or a use more awkward, but complete phrase, like "border MTA on 
the sender's side", or use a new term that doesn't conflict with anything 
already in use, perhaps an invented acronym BMoSS.  

I like the word "transmitter" to designate the border MTA on the sender's side 
- no conflict with existing email terms, and an appropriate analogy with its 
more common use in radio and TV broadcasting.  It is unlikely to generate 
confusion, even for people coming into the middle of a discussion.  See 
http://open-mail.org/3strikes/QnA.html for more on email "transmitters".

Other _terms_ that I see causing a problem in communication include:
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.  Although there are _secondary borders_ within 
this network, there is at least an indirect relationship between the parties, 
e.g. 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, and putting the burden on the Recipient to 
make sure mail flows smoothly between *his* Forwarder and *his* Receiver.

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_.  Should I change the 
diagram, use a different word, or what?  

How about this for rev 2 of our basic Mail-Handling System:

                              /
Sender(s) --> Transmitter--> / --> Receiver --> Forwarder(s) --> MDA --> 
Recipient
                            /
                         Border

-- 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/?member_id=2183229&id_secret=85055569-8f4e94
Powered by Listbox: http://www.listbox.com

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