Cheney, Edward A SSG RES USAR USARC wrote:
The idea is that security vulnerabilities on the internet occur most
significantly as a result of client-side scripting [...] Client-side scripting
cannot be removed unless an alternative convention is proposed.
[...] The idea is that interactivity from client-side scripting can be replaced
by transaction interactivity. Since mail servers are intermediate agents [...]
Apparently, moving scripts execution to mail servers would also
transfer vulnerability issues along the same path. Is it difficult
to state whether a compromised server is better than a compromised
client, but it is certainly better if at least one of them is not
compromised. (Considering that many mail server also function as
http servers, for handling email via web forms, it seems unlikely
that the vulnerability added to the servers would thus be removed
from the clients.)
In addition, it may be overly difficult to obtain real interactivity
without local scripting. Indeed, the draft defines what minimal code
a client has to be allowed to execute. Allowing some more seems
likely to come as an optional feature...
Finally, if the model is meant for widespread use, it shouldn't rely
on users' ability to obtain and maintain CA certificates on their
clients, or similar requirements, whose fulfillment doesn't seem
more likely than S/MIME or PGP deployment. IMHO, ensuring that the
server who has relayed the message is vouched for sending
transactions by a trusted authority may be more viable (see RFC
5518). I would additionally provide for an SMTP extension whereby
that relaying server grants that it knows where the message has
originated from, and takes accountability for its content.