Hector Santos wrote:
Keep in mind that this proposal will only work if the RFC specifications are
clarified due to one its central criteria. Quoting Yahoo:
"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
Therefore, like other proposals, if the bounce system is not reliable or
considered or interpreted as "optional", then there can only be one
assumption to be made; throw the message away.
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. I
would assume their "bounce" here is referring to the industry standard
way of doing bounces today, not anything esoteric.
In essence, the baseline compliance for this proposal is two MUA systems.
The middle ware is not really required. However, trust increases as a 3rd
party component is involved in the validation process.
If a compliant MUA sender is used, does the SMTP route have a role of
validating the key or simply pass it on to the final destination?
If a non-compliant MUA sender is used, where in the SMTP process does it
add the private key? or does it?
This proposal is specifically geared toward MTA signing messages, NOT
MUAs. Trust between the MUAs and MTAs is accomplished via SMTP AUTH, and
then the MTA signs the message before it is sent out. While it can be
done through the MUAs, based on all information that is available to us,
it is done on MTA level.
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Why are both drug addicts and computer aficionados both called
users?" (Clifford Stoll)
Asrg mailing list