Ok I am with you now.
But the draft is really only in its initial stage. the Author states that
quite emphatically.
So it is far too early to say "It won't work because"
There may be problems that need to be overcome. and can be.
Perhaps for the problem you mention do not include the "normal" headers in
the Domain Key digest
but add some special headers e.g.
DK-FROM: someone(_at_)example(_dot_)com ; the original sender
DK-SENTBY: someone(_at_)myemailforwarders(_dot_)com ; for mail forwarding
roaming etc..
Then sign the message body and the special headers. leave the rest alone.
software that knows how to deal with DomainKeys can use those fields. other
software is on its own.
if an intervening MTA changes those headers or changes the body then the
mail could be seen as tainted and then refused.
Regards
Chris
-----Original Message-----
From: William Leibzon [mailto:william(_at_)completewhois(_dot_)com]
Sent: Friday, 21 May 2004 5:07 PM
To: Chris
Cc: ASRG
Subject: RE: [Asrg] [Fwd: Yahoo! Mail Publishes Specification for
DomainKeys]
You're missing the point. You can't assume that everybody would start
running DomainKeys systems all over the world. As such any proposal
should ensure that if sender system is using it, that the MTA server on
the recepient side can safely verify the email even if somewhere in
between it passed through MTA systems which have no idea about what
this proposal is about. Domainkeys in the way its been published does
not meet this criteria as there are many cases when intermediate MTAs
change or add additional headers.
On Thu, 20 May 2004, Chris wrote:
Big problem I have with it is that yahoo domain keys breaks with email
forwarders, mail lists and roaming users
I don't understand why you say this.
Roaming users still have to log into an ISP somewhere to send
their email.
if The ISP is prepared to let them access the mail system the
ISP becomes
responsible for what they do. So they should at the very least validate
them.
Mail forwarders can sign the mail. they must accept
responsibilty for the
forwarding as above.
Mailing lists must also be held accountable for what they send. they are
simply another 'injection point' and can validate the sender before
inserting it into the list.
email content must be changed in process
of tranmission
Why 'must' content be changed?
headers need to be added and those should be signed off as well as the
previous mta's signature. granted this additional signing
increases the load
especially for the MTR, but if Spam is reduced then the initial
load would
be reduced anyway.
If content MUST be changed then the authority changing the
content becomes
the owner. and therefore responsible for the 'new' email.
Regards
Chris
-----Original Message-----
From: asrg-admin(_at_)ietf(_dot_)org
[mailto:asrg-admin(_at_)ietf(_dot_)org]On Behalf Of
William Leibzon
Sent: Thursday, 20 May 2004 4:17 AM
To: ASRG
Subject: Re: [Asrg] [Fwd: Yahoo! Mail Publishes Specification for
DomainKeys]
And frankly, I'm less then satisfied after so many promises
and lots of
wait for it. Its long document (which I ready fully) that
primarily just
pounds on rather old idea of entering public key in dns and
using private
key to add signed header to email, this idea had been around
for at least
4 years (possibly more) and I thought they found ways around
above listed
and other similar problems when email content must be changed
in process
of tranmission by intermediate server, but unfortunetly they
did not. Nor
do they address entering keys too well, again we're back to
reusing TXT
(where as what we need is standard for entering public keys in DNS and
this is needed not only for email but for several others things and in
general would come usefull, there have been drafts about this
actually).
On Tue, 18 May 2004, Yakov Shafranovich wrote:
From MARID list.
-------- Original Message --------
Subject: Yahoo! Mail Publishes Specification for DomainKeys
Date: Tue, 18 May 2004 10:46:32 -0400
From: Larry Seltzer <larry(_at_)larryseltzer(_dot_)com>
To: 'IETF MARID WG' <ietf-mxcomp(_at_)imc(_dot_)org>
(see http://antispam.yahoo.com/domainkeys in particular)
LJS
Yahoo! Mail Publishes Specification for DomainKeys
E-mail Authentication Solution Filed with IETF;
Alpha Version of Open Source Code Available
WHAT:
On Tuesday, May 18, Yahoo! announces the publication of its
specification on DomainKeys,
a cryptographic e-mail authentication solution to help fight spam.
DomainKeys: In order to attack spam at its roots, a powerful
solution is
needed that can
verify the identity of the e-mail sender and put an end to
spoofing and
forgery.
DomainKeys help fight spam by providing strong assurance of both the
sender's identity
and the integrity of the e-mail content through the use of
public/private key
cryptography.
On Monday, May 17, the company filed the spec as an
Internet-draft with
the IETF
(Internet Engineering Task Force) standards body to begin the
standardization process.
Additionally, Yahoo! is currently developing a reference
implementation
for DomainKeys
that can be plugged into Message Transfer Agents (MTAs),
such as qmail.
An alpha version
of this software will be released under a royalty free license at
SourceForge.net.
WHERE:
The specification, license terms and FAQs are posted on Yahoo!'s
Anti-Spam Resource
Center: http://antispam.yahoo.com
The alpha version of the software will be hosted at
SourceForge.net at:
http://sourceforge.net/index.php
--
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"There is nothing new under the sun" (Eccls. 1:9)
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg