On Tue, 2005-03-29 at 17:48 -0500, Sam Hartman wrote:
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> writes:
There is some redundant information within domainkeys.
http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-02.txt
I assume the following is saying the sending domain has
confirmed the user is entitled to use the local-part of
either the Sender or From header.
|The current valid tags are:
|
| g = granularity of the key. If present with a non-zero
| length value, this value MUST exactly match the local
| part of the sending address. This tag is optional.
|
| The intent of this tag is to constrain which sending
| address can legitimately use this selector. An email
| with a sending address that does not match the value of
| this tag constitutes a failed verification.
I think the intent here is both to permit per-user keys and to permit
address extensions.
This is extending assurances for the local-part. This is not an
extension for this local-part mailbox address, and the selector already
permits per-user keys.
I don't see the problem you seem to see.
Is it prudent for domainkeys to attempt making assurances for the
local-part of the mailbox address? Not accommodating this local-part
assurance (via individual keys), would acknowledge domainkey's relative
weakness in terms of its ability to scale in this manner. Adding an
assertion (within the key or elsewhere, such as l=y/n) could allow the
domain to assert that the local-part is valid, and permit any number of
users to utilize a single key.
The concern regarding the "g=" mechanism is that it mandates per-user
keys to achieve this assurance. Making local-part assurances for
portable private keys not prudent, as it requires a mechanism that does
not scale. I fear its use. A major feature of the signature, is that
it allows safe application of reputation. Validation of the local-part
is still trusting the domain that makes the validation.
Any organization with the resources needed to establish per-user keys,
will also have resources to ensure mail is submitted through their own
servers. For remote users, a means to indicate the local-part has not
be validated would seem more appropriate. Such a domain could be
isolated, such as remote-clients.example.com, where the key does not
assert a validation of the local-part (l=n).
I would also recommend that selectors be ASCII numeric values 0-65535 to
be compatible with KEY-TAG references within RFC-2538, such as P1234.
If nothing else, this adds a constraint on the selector mechanism. With
concerns regarding rampant inappropriate use, I do not think the "g="
mechanism is wise.
-Doug