On July 29, 2005 at 02:09, "Hector Santos" wrote:
ISP: isp.com
customer: customer.com
The customer is just using an MUA. His domain is hosted by the ISP. All
mail is routed via the ISP. The ISP offers an optional DKIM signing
service.
...
Lets assume the ISP creates its keys and allows the customer to define a OA
SSP policy record.
...
The customer will see one of the above OS SSP policies
Option 1: o=? WEAK (signature optional, no third party)
if message is signed, the ISP must verify this message.
If the message is not signed, the ISP *MUST* not do any signing whatsoever.
Sounds good.
Option 2: o=~ NEUTRAL (signature optional, 3rd aparty allowed)
if the message is signed, the ISP *SHOULD* avoid additional signing just in
case the customer has purchased a new MUA with DKIM signing capabilities.
Does it matter that the existing signature is valid or not?
if the message is not signed, the ISP *MAY* sign and it can use either its
own ISP.COM or CUSTOMER.COM:
DKIM-Signature: s=ispcustomer; d=isp.com; ...
From: user @ customer.com
or
DKIM-Signature: s=ispcustomer; d=customer.com; ....
From: user @ customer.com
I do not think the ISP can use CUSTOMER.COM, unless the nameserver
for customer.com contains the proper key data for the OA.
This gets into the key management policies of the ISP. If the ISP
is hosting the customer.com domain, it should probably put the key
data in customer.com DNS and not isp.com DNS. All messages it sends
out for customer.com would always use d=customer.com (and possible
an appropriate i= tag).
If ISP does not have control over customer.com nameserver (but the
customer does), then the customer must define proper key records
to facilitate ISP doing signing (if allowed by OA SSP or hosting
agreement, see below).
Now, if the ISP does not support, or allow, the customer to define
a DKIM signing key for customer.com, then the ISP can never use
d=customer.com, and it can never sign messages with an OA domain of
customer.com unless 3rd-party signing is allowed by the OA SSP.
Option 3: STRONG (signature required, 3rd party allowed)
if the message is signed, the ISP *MUST* avoid additional signing just in
case the customer has purchased a new MUA with DKIM signing capabilities.
if the message is not signed, the ISP *MUST* sign and it can use either its
own ISP.COM or CUSTOMER.COM:
See comments above.
Option 4: o=! EXCLUSIVE (signature required, no 3rd party)
if the message is signed, the ISP *MUST* AVOID additional signing just in
case the customer has purchased a new MUA with DKIM signing capabilities.
if the message is not signed, I am not sure if the ISP should assume
responsibility for the signing, but if it does, it must ONLY use
CUSTOMER.COM only:
This will depend on the hosting arangement between the ISP and the
customer. If the ISP is allowed to act as an agent for customer (due
to (legal) agreement), then the ISP can sign the message using
d=customer.com.
Option 5: o=. NEVER (no mail expected)
The ISP should reject all mail from the customer.
Sounds correct. Of course, such rejection may occur at the message
submission level since the customer may not even have the ability
to submit messages to the ISP MTA.
Option 6: o=^ USER
I don't know enough about this option.
Hmmm. According to the DKIM SSP draft, per user policy records can be
defined with the record:
user._policy._domainkey.<domain>
So if o=^ is specified at:
_policy._domainkey.<domain>
Then the verifier must query user._policy._domainkey.<domain> for
the SSP.
My comments about this:
* How "user" is determined by the verifier is not specified in the
draft. Is "user" the <local-part> of the OA address?
* It only takes one user of the domain to have a user-level SSP to
require user-level SSP records for all users. Why? In order to
support a per user SSP, o=^ has to be defined at the _domain_ level.
Therefore, once one user has an SSP, the DNS admin must define
user-level SSP for all users since the o=^ causes verifiers to
query for a user SSP.
The per user SSP is close to my
<local-part>._policy._domainkey.<domain>
comments, but it appears that verifiers should first check for
per user SSP, and if not defined, check for domain-level SSP (due
to comment above about o=^). This potential requires to DNS lookups
by the verifier, but this may be neglible compared to the overall
cost of verifing/processing a message.
The DKIM SSP spec also needs to clarify how "user" is determined
by the verifier.
--ewh