On August 23, 2005 at 16:13, Douglas Otis wrote:
DKIM should provide the mechanism to facilitate accountability in
an acceptably reliable fashion.
Therefore, you are implying that domains may practice policies that
selectively sign messages based on what they want to account for.
Signing will have greater value for a legitimate sending domain. An
attractive feature of DKIM should include an ability to quickly
correlate abuse and facilitate feedback aimed at rapid control.
Signatures provide a means for the sending domain to add account
tracking tags. I strongly feel this should be done as a standardized
convention. This tagging should allow opportunistic identifications
of authors, without any formal association through various records.
Attempts to publish all associations needed at the author level would
be prohibitive, but opportunistic methods where the MUA captures
bindings of identifiers would be practical, and this also allows the
detection of cross-domain forgery, even when no outbound server
offers any mailbox-address constraint.
Why do you keep going does this route when that is not what is
being discussed? I'm not being rude, but you repeat this multiple
times without addressing the particular issue at hand.
The question was accountability and will domains want the same level
of accountability regardless of their role when they sign a message.
I can care less (right now) how a domain maps ids to users, yadda,
yadda, I am talking about roles.
Let's take a real-world example. CPAN provides a permanent email
address for all CPAN account holders. CPAN account holders specify
where to forward all messages address to their CPAN addresses.
This type service is not unique and provided by multiple entities,
e.g. SourceForge, Savannah, college alumni services, etc.
Now, is there value for CPAN to DKIM sign messages that it forwards?
If so, should it be held as accountable for those messages as the
originating domains of the messages?
If it should not sign, why, and does this go against the goal of
trying to get everyone to sign messages?
For example, an ISP may sign all messages from their customers that
submit messages for transmission, but not sign messages that pass
through a forwarding service they offer to customers (regardless if
the messaging being forwarded is signed or not).
Not re-signing a message already signed makes good sense.
I would not use the term "re-signing". I am talking about adding a
signature. Re-signing implies any existing signature is invalidated
and/or removed.
It all goes back to my discussion about roles.
Passing
unsigned messages retains the tracking difficulty which benefits no
one but the abusers.
So CPAN should be held to the same accountability standards as the
originating domains?
If accountability is fixed, CPAN has no, and should not, claim any
accountability for the messages that pass through it. Therefore,
signed or not, CPAN will not sign any messages to avoid undesired
and unwarrented accountability.
The only motivation for CPAN to sign messages is if the signature
is a "transmission signature" to provide a verifiable trace of the
message, and not to claim any form of accountability on the content
of the message.
If transmission signature are deemed to have no real value, then we
should throw out the goal of trying to get every entity to sign
all messages it processes.
You seem fixated on mailbox-level forgery when no one is really
discussing it wrt DKIM. Please focus your arguments on domain-level
forgery, which appears to be what DKIM currently tries to address.
Once anyone suggests DKIM will protect the mailbox-domain from
unauthorized use, this becomes an endless debate with respect to
which header's mailbox-domain is involved.
I agree that rfc2822 originating headers are an issue since there
is a reliance on MUA rendering characteristics. For MUAs that
are DKIM-aware, it is a non-issue since the proper rendering to
the recipient can be done.
The problem is with non-DKIM-aware MUAs. There may be solutions
to address this with verifiers running at the MTA/MDA level that
"re-write" the message for display any non-aware MUAs.
--ewh
_______________________________________________
ietf-dkim mailing list
http://dkim.org