Keith Moore wrote:
If the MDA doesn't understand the extension, then delivery must fail
it's not clear why such an option would be useful or implemented
I'm having trouble thinking of a good applicaiton for this, too. However,
if there is a need for warnings than an extension was not understood, then
there is a pretty good chance that there is a need for insisting that
delivery must fail, allowing the sender to change the options. There are
probably some good usages for this feature in the groupware space but I
haven't really thought about it. "Rescind" is a possibility, although I
would expect that a warning would be sufficient for that.
A trickier proposition is with the ~client settings. What do you do if an
extension listed in the Client-Alert isn't supported? Delete the mail?
Power down the PC?
really wish that people would think about how to make more reliable,
virus-proof, and spam-proof, and about how to solve other problems of
a similar severity, rather than trying to justify designing a new
protocol by promising new features of dubious value.
Recursive signatures of the envelope solve a big part of the spam problem
in that they (theoretically) make it impossible to lie about the transfer
path. As to whether or not it would be faster and easier to change SMTP to
add this feature is certainly open to debate. Personally I feel that it
would be easier to leverage this as part of a new system if it were a
mandatory part of deploying a new protocol. I don't think it is feasible
to mandate that all SMTP servers must support feature X by some date, but
it is feasible to mandate that some new protocol must support feature X
from the beginning.
In the same vein, it is possible to require that the content header blobs
must be signed if some new protocol/format is used, whereas S/MIME is and
always will be optional.
In other words, I don't think that forgery problems can be solved until
the solutions for them are mandatory.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/