Re: [ietf-dkim] A perspective on what SSP is attempting
2007-12-10 10:17:30
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
|
|