Defining the Layers

Here is a first stab at defining "Layers" based on who handled the message, 
and what data changes at each stage.  (This is not really a proposal, yet, 
but I am hoping to be able to come up with one based on this.)
Using these definitions, Layer 1 is where both SPF and CID really shine, 
because the association to IP is strong.  The trouble is, SPF depends on 
the idea that MAIL FROM will be rewritten at each injection (MAIL FROM + 
SRS) and CID depends on a header being added to make PRA work, so neither 
exactly matches the way email is used today.
From:, Sender:, and MAIL FROM (non-SRS) are described here as Layer 2, and 
they don't currently have a strong tie to verifiable IP information. 
However, if you give some level of trust to the forwarding agent, it might 
be possible to stretch a Layer 1 PASS result to a Layer 2 result you can 
accept.  See description below in Layer 2.
______________________________________________________________________

Layer 0:  Hop / Relay / MTA receive

Identities:  2821: HELO

Set by: last hop client

Association to IP: Strong (if domain fully qualified)

Purpose of checks:  To catch fraudulent MTAs that lie about their own name, 
if the name is protected by LMAP info.
Description:  If LMAP information exists for the HELO name, check to see if 
the current IP is allowed to use the name.  If this check fails, reject the 
mail.
Justification for rejection: The domain owner is responsible for publishing 
LMAP info that includes use of her name in MTA HELO, if the name is allowed 
to be used by any MTA to identify itself.

______________________________________________________________________

Layer 1:  Injection / Redirection

Identities: 2821.SUBMITTER, 2822.PRA (i.e. Resent-From, Resent-Sender, 
Delivered-To, Sender, From), [2821.MAIL FROM only if SRS is used]
Set by: A layer 2 identified party (on 1st injection), or forwarding agent 
if forwarding is requested by the receiver.
Association to IP: Strong (checking at receiver's edge)

Purpose of checks:  Match IP information to "some" domain claiming 
responsibility, EITHER for the message OR its redirection to you.
Description: If PRA/SUBMITTER pass an LMAP IP check, the mail should be 
considered "Verified Indirect Mail" (unless it also passes at Layer 2).  If 
these identities fail an LMAP IP check, mail should be rejected.
Justification for rejection:  The domain owner at the first injection is 
responsible for listing all MTAs that may pass the message from an agent of 
the sender to an agent of the receiver.  The domain owner of the 
forwarding/redirecting domain lists its MTAs similarly.  The 
forwarding/redirection agent is responsible for adding his information in 
the appropriate header to override PRA (and SUBMITTER if available).
Only perform this check at receiver's edge, not at further relays within 
the receiver's organization.

______________________________________________________________________

Layer 2:  Message / Transaction

Identities:  2822.From, 2822.Sender:, 2821.MAIL FROM

Set by: MUA of person who authored the message, or person who forwarded the 
message via old-fashioned manual Fwd: (if Direct), or a mailing list robot
Association to IP: Weak

Description: If From:, Sender:, or MAIL FROM pass an LMAP IP check, the 
mail should be considered "Verified Direct Mail".   The mail should be 
identified as coming from whichever identity passes its IP check (From: 
Sender: or MAIL FROM:)
Reason for not rejecting: If these identities don't pass an LMAP IP check, 
proceed to per transaction checks.  The mail still may be allowed as 
Indirect.  Currently no rejection takes place at this layer using LMAP 
because the association between its identities and the relaying IP is weak, 
but if a Pass result is received, this is valuable information.
More info: A Pass result from checking layer 2 can be recorded along with 
the Received: information.  Another party receiving the message later may 
decide to go ahead and use the layer 2 information recorded by a previous 
layer 1 receiver, IF the layer 1 IP validates the forwarder AND the 
receiver implicitly trusts the forwarder.  For example, joe(_at_)aol(_dot_)com sends 
the message to frank(_at_)pobox(_dot_)com, who forwards it to 
frankie123(_at_)earthlink(_dot_)net(_dot_)  If pobox.com is able to validate layer 2 
(because joe(_at_)aol(_dot_)com passes based on the first IP) then pobox.com records 
this fact.  When frankie123(_at_)earthlink(_dot_)net receives the message, checks that 
it is from pobox.com's IP, and pobox.com is on his trusted forwarders white 
list, joe(_at_)aol(_dot_)com's identity is verified through the "chain of trust". 
(Note, for the chain of trust to work, the END recipient must trust ALL the 
forwarding agents involved and ALL the forwarding injections must result in 
a layer 1 PASS).

______________________________________________________________________


(In this model, mailing list robots set the Sender: and MAIL FROM, but not 
the From:, so they might be considered as the endpoint of one Layer 2 
transaction and the start of a second Layer 2 transaction.  So, it might 
make sense to talk about a Layer 3 that is truly end-to-end-delivery.  I 
think only crypto proposals are going to be effective at layer 3 if layer 2 
checking does not suffice.  For now I am lumping From: into layer 2 along 
with Sender: and MAIL FROM.)
Thoughts, comments, flames?  Though I know it's kind of incomplete as of 
yet...
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>