spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Terminology, ADMD, MON, roaming

2008-01-19 11:05:10
At 05:56 AM 1/18/2008 +0100, Frank Ellermann wrote:
David MacQuigg wrote:

I can't think of any example where the MSA and Transmitter
would be in separate ADMDs.

I can, it's onee reason why I don't like the ADMD abstraction,
it's too fine grained.  For the overall picture MON is better,
how it's organized internally in ADMDs is often irrelevant -
as long as you know that there *could* be differents ADMDs.

So for SPF we need to know that there can be relays "behind"
the MSA still belonging to the MON.  And there can be also
different MSAs (e.g. internal RADIUS vs. roaming AUTH users).

Permitting them all in a sender policy is okay, listing only
"mailout" border MTAs is okay, but forgetting a rarely used
border MTA can be fatal.  To what ADMD they belong is less
interesting.  Webmail could be outsourced, or DKIM signing,
or outgoing AV checks.  If the MSAs support RFC 4409 6.1 an
MTA "behind" the MSA (still in the MON) can report errors
to the originator, otherwise I don't understand the setup ;-)

How about we drop ADMD, and all words that seem to imply a relationship between 
domain names and roles in a Mail Network.  I'm OK with MON and MRN.  Those 
definitions are quite simple.

What we are really talking about is actors and their roles, not domains.  MSA 
and Transmitter are two separate roles, but they are often played by the same 
actor.  We can always break a role into smaller parts, and even arrange for 
separate actors to play the separate parts.  That does complicate the diagram, 
so let's do it only when the discussion would be clarified.

In a diagram, we can indicate one actor playing multiple roles using a /, e.g. 
MSA/Transmitter.  We can leave out a role, when it is not important to the 
discussion, e.g. say Receiver ~~> MDA, and it is clear that the Receiver is 
also playing the role of Forwarder.

Again, we can illustrate relationships among actors (and the direction of mail 
flow) with --> no relationship, ==> direct relationship, and ~~> indirect 
relationship, e.g. two actors in an MRN, both having a direct relationship with 
the Recipient.

So, talking now about roles, what I have in mind is an MON that looks like this:
Sender(s) ==> MSA/Transmitter -->
This shows two actors with a direct relationship between them.

What you seem to be thinking of is something like this:
Sender(s) ==> MSA(s) ~~> Transmitter -->
i.e. three actors, and only an indirect relationship between the MSA and the 
Transmitter.  Can we find a real-world example?  What about Crocker's statement 
that there are independent actors (ADMDs) performing an "aggregation and 
routing" role on the Sender's side?  This is relevant to the question of 
whether SPF is good for authorizing an entire MON.

Here is how I would arrange the roles in a typical Mail Handling System with 
four actors:

|----------- MON -----------|           |---------- MRN ---------|
                                   /
Sender(s) ==> MSA/Transmitter --> / --> Receiver/MDA ==> Recipient
                                 /
                              Border
                              
Here are the responsibilities I would assign to each role in the MON.  This 
should work regardless of how we group the roles assigned to each actor.

Sender
- Originate messages
- Provide a password or other means of authentication

MSA - Mail Submission Agent
- Authenticate the Sender
- Manage Sender accounts

Transmitter
- Spam Prevention
  - rate limits, content analysis, alerts
  - respond to spam reports
  - maintain reputation
- Authentication
  - RFC compliance
  - IP authorization (SPF, SID, CSV, ...)
  - signatures & key management (DKIM ...)

Can anyone think of anything important I have left out, or any way to clarify 
these roles and responsibilities?

-- 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=87796543-8293cb
Powered by Listbox: http://www.listbox.com

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