[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Sam
Hartman
"Douglas" == Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> writes:
Brief summary: we disagree a lot.
Douglas> This mechanism is the only means to make the validation
Douglas> of the local-part explicit. It may not be reasonable, if
Douglas> this causes a proliferation of user-keys beyond normal
Douglas> capacity.
That's unclear to me. I'm not sure whether current domainkey
semantics say that the local part is validated. If they do
not, allowing a policy attribute to be attached to a
signature saying that the local part is validated seems
sufficient to address your concern.
If you think about it I think you will agree that the policy attribute
has to be attached to the key. The signature can weaken the policy
statement and say that the signature meets a lower criteria but should
not raise the criteria.
The use case that is important here is the ability to give a bulk mailer
the ability to sign email from junkmail(_at_)example(_dot_)com but no other user
account.
I disagree that it is desirable to discourage the use of
per-keys. I disagree that it is acceptable for per-user keys
not to validate a local part and will block any IETF document
that attempts to do so.
I think that there is an honest diagreement here as to the reasons why
specifications are not implemented. The people arguing for 'simplicity'
seem to think that its complexity that discourages implementation. I
think that the issue is marketting.
The proposals being made to limit the scope of the spec do not in fact
reduce the complexity and in my view make implementation of required
functionality either much more complex or impossible. This leads to the
real reason for complexity in most specs, the base spec is
underspecified so people do ad-hoc extensions which are much more
complex in aggregate.
I disagree that it is acceptable to force sites to move
addresses into subdomains to make a signature scheme work or
to support a site's policy.
I think that it is irrelevant since it will be ignored.
We are not writing a standard here, we are writing a sugestion for a
standard. The market can and will ignore silly suggestions like trying
to limit per-user keying or stating that there 'can' only be one
signature per message - not on my implementations you can't.