----- Original Message -----
From: "Jim Fenton" <fenton(_at_)cisco(_dot_)com>
Jim, question.
Why isn't the SSP part of the selector key TXT record?
Hector,
In the absence of a signature, there's no selector name to use. If
there is a signature for the origination address which fails
verification but for which it's possible to retrieve the key record, I
suppose that putting the signing policy in key records as well would
save a lookup, but it would be a small savings. A policy change would
then require that all key records change as well, and that seems
burdensome and prone to inconsistency.
Well, I hear you but I am not among those who believe overrhead potential
should be taken so lightly. We have even scratched the surface yet. I am
a firm believer of the CBV and SPF concepts and our package includes it as
part of AVS suite. Yet I understood fully in a wide deployment, the DNS and
call back chaos potential can not be under estimated. So we do want to we
can to minimize all need to do a SPF and CBV and we do our upmost to avoid
any payload transfer.
DKIM is a payload solution so inherently it increases bandwidth, so
comparably, an additional DNS check may be miniscule in the total sum of the
transaction.
Keep in mind DNS lookups does fail some times so the less you have to call
it, the better.
Does it make sense to have it as an override?
I'm not sure what you mean by an override.
The domain policy may indicate one SSP and the selector key policy has
another SSP. The domain SSP is the default, the key SSP is the override.
I might want to have a relaxed domain signing policy, but for a specific key
I might want an exclusive signing policy. The override is an option.
Or vice versa, the domain has an exclusive policy, the key is relaxed.
For example: santronics.com
Mail Flow Requirements:
1) I might want an exclusive policy for general
business/vendor communications where exclusive
outbound is only from santronics.com network.
2) I want a relaxed policy for non-business traffic
sent by our servers, i.e., a mailing list.
The general topology is:
MUA ---> MSA/MTA ---> MDA
The final designation MDA is a DKIM ready verifier and signer too.
Now at my santronics.com MTA, I have a configuration:
SELECTOR business
SELECTOR non-business mailinglist.com
If my target address is mailinglist.com , the MTA will use the non-business
selector. Otherwise, the default will use the business selector.
I use a STRONG policy for non-business
I use a EXCLUSIVE policy for business (which is the default)
Now I have a way to use my santronics.com for both purposes with some level
of control.
When the business MDA receives the mail, it verifies the signature and it
could stop there, but in my opinion, it should see if the selector policy to
see what the SSP is. It might be NEVER (o=.)
If the MDA is a mailing list which does another level of distribution
signing, then I believe it needs to see if the FROM: address allows for 3rd
party signing.
Lets put it this way: I would LIKE for it to check for 3rd party signing
because this is the only way I can have some level of confidence that my
email address will not be exploited by that server.
Anyway, I think the suggestion is backward compatible. Current systems can
still use the domain policy. New systems would use the key policy if the
SSP is present.
If the override or ability to have a different SSP is not available, then I
believe, I will be limited in using my domain outside my own domain.
If you think about, this is similar to SPF forwarding problem.
MUA ---> MSA1/MTA1 ----> MDA2/MTA2 ----> MDA3
As far as my MTA1 is concerned it completed it jobs of sending mail to MDA2.
From the point of view of the MTA1, it reached it final destination at MDA2.
However, MDA2/MTA2 is doing some relaying, forwarding to reached the real
final destination at MDA3.
This is a case where I believe the passthru system (MDA2/MTA2) should avoid
doing any signing. By doing so, then MDA3 will only need to deal with and
verify the original signing at a MSA1/MTA1.
But if that middle ware is going to do some signing, then we have a 3rd
party signing situation and I may or may not want the MDA3 to allow it.
To me, it is pretty clear, all 3rd party signers and verifiers need to
investigate the SSP of the original sender.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com