其他回答者建议答案是“否”。
另一方面,html 附件可能会在运行 Javascript 的环境中打开。
编辑:有人建议我没有正确回答这个问题,所以这里需要更完整的努力。
总结:我希望许多或大多数用户收到包含嵌入式 Javascript 的 html 格式的电子邮件时会看到它运行并运行测试以确认这在某些环境中是正确的。但是 Javascript 将被某些用户阻止。
协议(特别是 RFC2854)通过以下语句显式处理脚本(在 text/html 消息正文类型中):
此外,引入脚本语言和
HTML 4.0 中的交互功能引入了许多
与程序自动执行相关的安全风险
由发送者编写,但由接收者解释。用户
执行此类脚本或程序的代理必须非常小心
确保不受信任的软件在受保护的环境中执行
环境。
所以协议确实支持 Javascript,但哪些用户代理支持?
我的(古老的)电子邮件阅读器使用一个表格来指定每个 mimetype 使用哪个查看器软件,将 html 内容转移到我最喜欢的网络浏览器。几乎所有当前的 Web 浏览器都支持 Javascript(当您尝试将其关闭时,有些会发出可怕的警告!)现代电子邮件代理是否包含内部 html 解释器,如果是,javascript 是打开还是关闭?我检查了关于 Thunderbird 的文档,发现 javascript 似乎默认打开但可以关闭:http://codeverge.com/mozilla.support.thunderbird/simple-html-tags-reference-docume/2030160
我注意到一些(?很多?)用户现在直接从浏览器访问他们的电子邮件(webmail 就是这样一个平台),而不是运行单独的电子邮件软件。到目前为止,我测试过的所有此类平台都运行嵌入在电子邮件 html 中的任何 Javascript。但是,根据用户安全设置,某些此类环境不会自动获取外部链接(Javascript 或图片或其他),因此只能从作为邮件附件包含的文件中运行外部 Javascript。没有当前互联网连接的设备上的任何离线电子邮件阅读器也是如此。
以上内容适用于嵌入在电子邮件正文的主要消息部分中的 javascript。还可以将 html 作为“附件”明确给出,如果保存然后打开,将显示在 Web 浏览器中,其中 Javascript 很有可能可用。因此,可以将启用 javascript 的电子邮件的第二份副本作为 html 附件包含在正文/html 中的替代文本/纯正文和/或标记,将用户引导至附件。
我一直在考虑这个问题,因为我的一些熟人坚持要给我发送“电子邮件贺卡”,其中包含一条将我引导至一个链接的短信,我发现该链接非常不满意,以至于我什至拒绝考虑加载它只是原则上。我使用嵌入式 javascript 编写并发送了包含交互式图形和音乐甚至游戏的电子邮件贺卡,并对结果感到满意。
因此,我认为正确答案是“是”,因为协议专门针对脚本编写,而且我个人使用的所有电子邮件代理都在我的测试电子邮件中运行了 Javascript。