邮件系统的组成

MUTT的官网上有些材料对邮件系统里各个部分的作用做了详尽解释。很早以前我就看过这些东西了，但最终还是没能搞清楚谁是谁。

MUA直接根用户打交道，MUTT即是如此。它遵循“一个程序只做一件事”的原则，既不能收邮件，也不能发邮件。这是我见过对“一个程序只做一件事”最蛋疼的信奉。MUTT在整理邮件方面确实好用，至少潜力非凡，工作方式合程序员口味。但如果要使用它还得装一个fetchmail，装一个sendmail，然后配置好这三个东西才能正常工作，这不是蛋疼是什么？

如果不了解邮件系统中各个部分的作用，确实不好理解为什么MUTT不能XXX，以及fetchmail或者sendmail是做什么的。最简单的邮件系统组成，只需要MUA和MTA。用户与MUA打交道，编辑邮件，告诉MUA把邮件发出去。MUA把邮件传给MTA，MTA再经过网络上一些MTA最终到达另一台主机，另一台主机的MUA就可以读取文件了。

一个问题是：第一MTA在本地还是外部？Thuderbird之类的邮件客户端看起把MUA和MTA集合在一起了，上述流程第一次数据传输在这种情况下是虚拟的（程序内部的）。用户写邮件时Thuderbird是MUA，用户发送邮件时Thuderbird是MTA。它用SMTP协议将邮件发转至你的邮箱提供商服务器（比如Gmail），后者再将邮件发至最终目的地。

Gmail服务器显然也是一个MTA，它与最终接收邮件的主机间也是用SMTP协议通信。在那台主机上，也有一个MTA，它接收Gmail传来的邮件。这是到此为此的描述中，MTA第一次不是用来发邮件，而是用来接邮件。

等一下，既然Thuderbird知道SMTP协议，为什么不直接把邮件发到最终目的地而要通过Gmail间接传输邮件？可能的解释是，SMTP协议需要确认，发完邮件之后，MTA要等到最终MTA的回应，不然就报告失败。如果Thuderbird要跟最终主机通信，那么它同时也得做为一个server，等待着目的MTA的消息。

发往Gmail是什么情况？只需等待Gmail的回应，即Gmail报告已成功从Thuderbird接到邮件。Gmail服务器上的MTA是真正的MTA，可以接受Thuderbird的消息，将邮件往其它MTA传（发）；也可以接收其它MTA的消息，将邮件保存在服务器上（收）。Thuderbird只是将邮件交给Gmali转发，大概就是所谓的relay。从这个角度上来说，Thuderbird只能算半个MTA，msmtp可以实现这个半个MTA的功能，其官网上的描述为SMTP Client。

如果Gmail向最终主机投递失败要怎么通知Thuderbird呢？不需要通知，只要新生成一封报告错误的邮件就行了，Thunderbird下次同步邮箱时，用户就可以看到这封报告邮件投递失败的邮件。

MUTT是什么情况？且认为MUTT真的只是个MUA，即么起初MUA到MTA的通信就确实存在了。这个MTA是个本机程序，MUA用管道或者其它IPC方式与之通信。如果sendmail是MTA，信件最终 就是通过sendmail发送出去的。sendmail真的是个MTA，不像Thunderbird只有一半的MTA功能。所以，用sendmail可以直接把邮件投向最终目的地，不需要将邮件relay到全功能的MTA。当然通过设定应该也可以让sendmail只将邮件中转到指定MTA而非直接投向最终目的地。网络上搜到的一些用sendmail将邮件中转到Gmail的博客看起来蛮复杂的。不知道是Gmail的原因还是sendmail的原因。

这样一来，MUTT为什么要配sendmail就很清楚了。显然，一般人根本不用着sendmail：谁会把自己的电脑配成一个邮件服务器？而且，据说，如果对方服务器不能反向通过IP查到域名，很可能就将这封邮件当成垃圾邮件了。绝大部分的MUTT用户都会想使用网络上邮件提供商的服务，如Gmail。所以，MUTT需要的不是一个完整的MTA，而是像Thuderbird那样半调子的MTA：能将邮件relay到一个全功能的MTA即可。前文提到的msmtp就很好，MUTT需要的是STMP Client功能，真正做事的MTA在邮件提供商的服务器上。

想来，git send-email也是一个STMP Client。这个MUTT情何以堪呐，人家git一个插件都可以relay邮件，虽然人家的功能是用Perl实现的。其实较新的MUTT有内含SMTP Clinet功能的版本，看编译时怎么配置的。我在Ubuntu仓库中装的MUTT是有这个功能的。如果配置文件中设定了smtp的地址，MUTT会忽略$sendmail这个变量，邮件便会通过SMTP relay到某个服务器，而不是通过管道传给$sendmail所指定的程序(sendmail或msmtp)。

接收端又是如何？回到Thunderbird的例子，用户查看邮件时，Thunderbird会先通过IMAP或者POP3协议将邮件下载到本地。这时，它扮演了MRA的角色。但这个角色只在这种情形下才有意义。想象一下，如果你能ssh到Gmail的邮件服务器，在上面开个MUTT直接读邮件，那还要个毛的MRA。据说，国外的ISP都会提供邮件服务器，你直接登上去看邮件就行了。我这个年代的人，恐怕已经将用MRA把邮件下载下来看视为理所当然了。

如果MUTT仅仅是一个MUA，那么我们需要一个下载邮件的软件。而且，这时的情况跟发送时有些不一样。发送时，MUA要找到MTA（配置里指定），要通过某种方式与MTA交流。而接收时，MRA和MUA没有类似的关系，甚至MUA都不管你用的啥MRA：我只要在本地文件系统看到邮件就行了。它们间用文件系统交流，这个关系比上一个关系弱得多。fetchmail就是一个MRA。令人吃惊的，每一封邮件在本地文件系统中竟然不是一个文件：一个本地邮箱居然是一个文件，所有属于这个邮件的邮件都写在这个文件里。当这个文件更新以后，你就可以用MUTT打开它，查看邮件了。

和发送的情况一样，较新的MUTT也是内置MRA功能的版本。打开邮箱时不指定本地邮箱路径，而用imap://之类的路径，即可打开远程邮件。这就跟Thunderbird差不多了。转了半天，原来MUTT就可以和Thuderbird一样用，不需要其它软件配合。这已经足够大多数人用了。

但我需要fetchmail。为什么？因为用MUTT当MRA时，邮件不经过MDA。MDA的作用是根据规则及邮件的内容将邮件存放在文件系统中不同的地方。fetchmail将邮件全部下载到默认本地邮箱，可以对它进行配置，把邮件传给MDA，由MDA来确定邮件在文件系统上的归宿。这是个将邮件分类的好时机。每天的邮件量有几百封时，如果能根据细致的定义规则将邮件分类，那该有多爽。比如，我订阅了linux-kernel，kvm，linux-fsdevel三个邮件列表，linux-kernel简单是洪水猛兽，kvm和linux-fsdevl邮件量是有可能每天看完的。如果将来自三个不同邮件列表的邮件分类，另外将发送或抄送给我（虽然近期内还不会有这种情况。。。）的邮件单独列出来，如果将来自自己比较关注的几个开发者的邮件单独分类来自，每天按优先级看一看，那就多好。Lotus Notes就有类似功能，可以说，它内部集成了一个MDA。

MUTT虽有MRA，却无法通过配置将邮件交给MDA，这对我来说是极不方便的。还是用fetchmail将邮件下载到本地，再用procmail把邮件分类吧。这个过程不需要对MUTT做什么额外的配置，MUTT只要能在本地文件系统上看到邮件就行。

还有一个MSA的概念，大意是，拦在MTA前面，进行一些安全认证。其它MTA完全可以（而且有理由）集成这样一个功能。可以说，SMTP Client其实是与邮件服务器的MSA交流，这个过程有各种安全验证，一切顺利的话，MSA才会接收邮件，最后再把邮件交给MTA。