RHEL - Uuencode + mailx =胡言乱语

Question

据我所知，uuencode用于编码文件，而mailx则发送邮件。不过，我不太明白.

1. 为什么uuencode file file | mailx -s "subject" email_adress总是在电子邮件中发送带有编码内容的消息而不是附件。(以及如何修复它.)
2. 我试过了echo | mailx -s "subject" -a <file> <email_address>，我的文件似乎很好。但这是否意味着我没有编码的保护，还是-a给你的？
3. 我想过了，也许还有更好的选择。真的要走这条路吗？我对事物的*零方面不是很流利.mutt是一个很好的起点吗？还有其他建议吗？

这是在RHEL 6.4，uuencode (GNU sharutils) 4.14上

更新

mailx版本是传家宝邮件版本12.4 7/29/08有关系吗？问题是否在于mailx如何对待uuencode输出的行为差异？它是一个mailrc设置还是某个环境变量？

嗯，我发现了另一个帖子，它似乎有关于邮件标题的更多细节.我发现它帮助我更好地理解这个问题，所以我在这里保留了一个链接。

Answer 1

Uuencode将二进制数据转换为文本，这是第一种通过电子邮件发送二进制文件的方法(这只是uuencode的用法之一)。Uuencode不会保护您的电子邮件。

然后，MIME被发明，它定义了邮件的主体和附件。

要发送MIME邮件，我使用mpack

mpack -s "subject" -d description_file file address1 address2...

description_file是电子邮件文本(可选)

文件是附加的文件。

Answer 2

管道将流发送到stdin，因此它是消息的内容。-a创建了一个附件，它将被base64编码--基本上与uuencode相同。

Answer 3

为了补充和稍微解压其他答案中的信息，让我以相反的顺序回答。

1. 是的，mutt是一个很好的起点。它是合理的无处不在和良好的支持，并有良好的支持MIME附件。命令行界面不是很通用，但它可以快速获得一条带有一些附件的消息，这些附件提交给您的邮件服务器。

(如果您没有配置邮件服务器，这将使所有这些讨论变得更加复杂。让我们假设你知道。有些初学者因此受到阻碍，所以我想在我们继续之前，我应该把这作为一个基本的理智检查。您在本地的25端口有什么反应吗？或者，您是否将邮件客户端配置为连接到远程服务器以进行邮件提交？如果不是，先解决这个问题。)

1. 如果mailx有一个-a选项，该选项接受要附加的文件的名称，则完全正确，并将该文件发送为(通常是base64 64编码的) MIME附件。

有多个mailx实现这一事实使事情变得有些复杂。详情见这里。

1. uuencode远早于MIME或“附件”的概念。它所做的正是你所描述的，它的可用性问题无疑是用MIME取代它的动机之一。在这个千年里，不应该有任何理由使用uuencode。

除了将电子邮件分割成带有零或多个“附件”的内联“主体”的可用性改进之外，MIME还通过明确和可靠地标识每个附件的文件类型和文件名，大大改进了uuencode。它也是任何类型的多媒体和/或多语种内容的先决条件。(从根本上讲，MIME之前的电子邮件只是文本，而英语是唯一的。在很多地区都有地方黑客可以推翻它，但是..。你会大吃一惊的。