ietf-asrg
[Top] [All Lists]

Re: [Asrg] 6. Proposals - DNS + PKI - Yahoo's "Domain Keys"

2003-12-08 21:50:37

----- Original Message ----- 
From: "Yakov Shafranovich" <research(_at_)solidmatrix(_dot_)com>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Cc: "Alan DeKok" <aland(_at_)ox(_dot_)org>; <asrg(_at_)ietf(_dot_)org>
Sent: Monday, December 08, 2003 10:57 PM
Subject: Re: [Asrg] 6. Proposals - DNS + PKI - Yahoo's "Domain Keys"

"If the receiving system can decrypt that private key with a public key
registered by the Internet's Domain Name System, then it will be assumed
the
message is authentic. If it can't, the message is bounced back from whence
it came."

In other words,  what will be the RFC guidelines on handling an
unreliable
or incomplete bounce due to a failed decryption of a private key?

I would not rely on their press releases or news stories based on their
press releases until concrete specs for their proposal is released.

duh. <g>

I presumed you are privy to any timeline information? Yahoo does say early
2004.  Doesn't give developers much time which is why I say that they are
basing this on a minimum compliance with MUAs only, like Outlook augmented
with their mail server.   Looks to me they are going to apply this to thier
moronic DATA level validation logic.

I  would assume their "bounce" here is referring to the industry standard
way of doing bounces today, not anything esoteric.

Of course, no details. But any intelligent person can see any generic
concept applied here.

Whether its the MUA or MTA adding the private key, when that message come to
my SMTP server,  it sounds to me we are back to the original issues of MX,
PTR,  and Return Path validation concepts.  The burden is still on the SMTP
system to "determine" how much trust can be put into a transaction with or
without a private key.

No "KEY" from a YAHOO return path message:

         What steps should a SMTP server take?

Or is what YAHOO is telling the world that starting in 2004,  any message
that does not have a private key, should not be trusted?  Plain and simple?
Then as you mentioned, we are left with possible forgery issues.

The key to any successful technology is to tell the SMTP receiver not to
take any further action or minimum action on validating a transaction and it
needs to be done before DATA is received.

-- Hector



_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>