Re: [ietf-dkim] A perspective on what SSP is attempting

Bill(_dot_)Oxley(_at_)cox(_dot_)com wrote:
> SSP consists of what the following statements mean
> 1. I sign all mail
> 2. I sign some mail
> 3. I sign no mail
> 4. I sign other domains mail
> 5. Other domains sign my mail
>
> Number 3 has been declared out of scope.  
That has always been a very ambiguous declaration and I believe many 
take the literal meaning incorrectly unfortunately, and began to ram it 
down other people's throats.
The fact is, SSP-01 specifically highlights the potential for it.

     NON-NORMATIVE RATIONALE:  Strict practices may be used by
     entities which send only transactional email to individual
     addresses and which are willing to accept the consequence of
     having some mail which is re-signed appear suspicious in
     return for additional control over their addresses.  Strict
     practices may also be used by entities which do not send
     (and therefore do not sign) any email.

Specifically, you can have a strict SSP policy and no DKIM key or NULL 
key, and this is effectively a NO MAIL EXPECTED situation.  Both Eric 
and Jim clearly pointed that out as a reason to not require a specific 
tag saying "No Mail" as the original SSP-00 has.  The end result is the 
same using a bad key, null key with a strict policy.
So in other words, a "no mail" concept is quite possible if a company 
domain owner chooses to lock out any usage of its domain property for 
unauthorized, erroneous external email usage.  Companies should not be 
restricted from implementing this policy.
> 4 and 5 appear problematic 1
> and two are clearly defined and somewhat in agreement when it comes from
> a single FROM: address with a single signature. 
This has always been viewed as contractual issues between two parties: 
the domain owner and any mail handler for it.
Its the same like many systems today that have "IP Allow Relay Tables" 
or require some authentication concept for Smart Hosting.  Otherwise, 
you can have harms that an undoubtedly Open Relay can give you today.
Same idea with the 3rd party signers (3PS) issue.  So either its open 
ended (Unmanaged) or its restricted (Managed) 3PS.
The problem has been how it is implemented.  How do you expose the 
managed 3PS?
Conceptually, you need some "list" concept. There has been proposals 
(Doug's proposals, my own DSAP) who provided various forms of that 
"List" concept.
SSP-01 choose not to use that idea and simplified it with the t=s (1st 
party only tag).
        DKIM=strict, t=s      ; 1st party only

> In what circumstances is SSP to be used.
> When a signature arrives broken and possibly, no signature=broken
>
> What to do with broken signatures?
> Receiver side policy determines that.
The toughest part is dealing with mail integrity issues, but I think it 
is generally viewed that this is mostly a problem when the domain is 
being used outside the domain owner's submission source.  i.e., a 
mailing list or some ESP web mail service or roaming users.
In my view, this is all natural and part of the domain owner's policy 
making decision in how its domain is going to be used internally and 
externally.
In addition, it should also be a natural part for an DKIM/SSP ESP 
implementator to leverage this information when a user tries to use a 
domain that is exclusive in its operations.
Of course, if the domain owner expectation is such that its domain can 
be used externally, then it really doesn't make any sense for them to 
use strong policies.  They are really not a candidate for DKIM/SSP 
because with a relaxed policy, as with all thing relaxed, they can 
exploited and it just make things very complicated for all parties.
So you're right, local policy dictates, but we risk the problem of "Cry 
Wolf" where the incoming mail is so filled with broken messages that 
there is high risk of apathy to occur where more and more verifiers will 
simply begin to stop processing DKIM mail altogether.
In other words, it will be sad when verifiers begin to turn off DKIM 
verifiers for some domains simply because it is always broken.
In the end, it is still the domain's decision on how he plans to use 
DKIM and SSP.  They can't just simply turn it on and hope for the best. 
 It could make things worst for them.  And the implementation, 
including the ESP and Mailing List system, they should leverage SSP as a 
way to help protect the domain owner for unauthorized usage in the first 
place.
Remember, the ESP also needs to take into account the down link 
receivers may be completely ignorant of DKIM/SSP. In fact, that will 
very true for a very long time, hopefully short, but we can't assume all 
receivers will be DKIM/SSP verifier ready.
This idea was also touched upon in past discussions and reflected in the 
DSAP proposal where a high-value domain, such like a BANK, when it 
getting new customer accounts and has a "e-Banking" framework, that it 
is to its benefit it makes sure the  new customers are DKIM/SSP receiver 
ready. If they, they can either create their own intranet email domain, 
or they can enlist a DKIM/SSP ready ESP that will provide this service 
and give the new customer one of these Bank Certified ESP addresses.
These engineering concept is all part of the total policy and operations 
picture to help closed the loopholes in the DKIM/SSP world.

> So that leaves multiple signatures, multiple FROM: and mixed SSP records
> from a list posting.
> No change, receiver side policy determines what to do.
Same thing, this has been worked out too. SSP policies will help here. 
The issue is mostly with 3rd parties or resigning.
As my proposal suggest and other current implementation already do, when 
it comes to a 3rd party, like a mailing list server, it MAY help to 
strip all signatures and add your own - but that should depend again on 
the intentions of the domain owner.  My proposal says that should only 
be allowed if the domain's policy is relaxed.
> Scores can be addeed and subtracted for each scenario, but
> SSP is not so much a technology but a informational description
> of sender intent.

+1

--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html