邮件服务器运作原理

java

http://linux.vbird.org/linux_server/0380sendmail.php
邮件服务器运作原理：
Mail 与 DNS 系统的相关性：
既然我的主机需要 DNS 来转译主机名称使成为 IP ，那么我真的就得必须要架设 DNS 吗？当然不是！
假设我的主机名称对应 IP 已经成功的在 Internet 上面完成合法注册了，这样就好了吗？是这样没错啦！确实，只要有主机名称对应到 IP ，亦即是有 A ( Address ) 这个 DNS 的标志后，那么就可以架设 mail server 了.
然而， DNS 系统本身还有其他的功能可以支援 mail server ，使 mail server 更稳定与具有更佳的避免信件遗失功能，所以，就有 MX 这个 DNS 的标志产生啦！MX 这个 DNS 设定中的标志，主要就是要给 mail server 用的，
基本上， MX 就是 Mail eXchanger 的缩写，他可以让 Internet 上面的信件马上找寻到 Mail 主机的位置，此外，由于 MX 后面可以接数字，因次，一个 domain 或者是一部主机，可以有多个 MX 标志，这有什么好处呢？
主要的好处就是可以让，当主要的 mail server 挂点时，由于有 mx 标号，因此，信件不会直接退回，而是跑到下一个 MX 设定的主机去，并且暂存在该处，等到主要的 mail server 起来之后，这个 MX 设定的主机就会将信件给他传送到目的地！
如此一来，甚至可以达到异地备援的功效呢！不只如此喔！MX 的功效还很多！最大的优点就是有点类似 router 的功能，我们或许可以称之为 邮件路由 吧！当有了 MX 标志之后，由于这是 DNS 的设定，所以当你要传送 mail 的时候，
那么就可以直接依据 DNS 的 MX 标志直接将信件传送到该设定的 mx 邮件主机，而不需要去寻问到底邮件要寄到哪里去！这功能相当的不错的！因为可以让你的邮件很快的而且正确的送达到目的地呢！此外，由于可以设定多个 mx ，
因此，假设‘此路不通’，也就是先使用的 mx 邮件主机不通的时候，那么信件就会往下一个 mx 邮件主机传送！这样可以避免信件被退信的机会！当然就更加的稳定啰！不过，这里也要特别强调， MX ‘一定’要设定正确，否则，
呵呵！反而会让你的信件永远在 Internet 上面流浪呢！

一般来说，邮件位址的写法为： account@server.name 的写法，在小老鼠 ( @ ) 前面的指的是‘帐号’，至于 @ 后面的则是主机的名称！当你寄出这样的一封信时，首先，你的邮件主机会先去 DNS 系统寻找 server.name 这个主机名称对应的 IP 与 MX 标志，
若有 mx 标志，那么这封 e-mail 将会把信先送到该 mx 主机，然后再由该 mx 主机将信件送达目的地 ( 就是 server.name 这个主机啦 ) ，而如果有多个 mx 标志时，那么这封 e-mail 会送到最优先的 mx 主机去(也有可能这部主机就是目的地主机喔！)，
然后交给该主机来处理啰！而如果没有 mx 标志的话，那么在查得 IP 之后，信件才会慢慢的送达该邮件主机啰！在送达到邮件主机后，该主机则以前面的‘帐号’将信件发送到各个使用者的邮件目录下！


///////////////////////MUA ( Mail User Agent )：
顾名思义， MUA 就是‘邮件使用者代理人’，通常我们 Client 端的电脑都无法直接寄信的(不然干嘛要邮件主机？)，所以，需要透过 MUA 来帮我们传达信件，不论是送信还是收信，Client 端的用户都需要透过各个操作系统提供的 MUA 才能够使用邮件系统。
MTA ( Mail Transfer Agent ) ：
MUA 是用在 Client 端上面的软件，那么这个 MTA 就是用在邮件主机上面的软件啦！他也是主要的邮件服务器喔！这个 MTA 就是‘邮件传送代理人’的意思。
也来顾名思义一下，既然是‘传送代理人’，那么使用者寄出的信，与使用者要收信时，就是找他 ( MTA ) 就对啦！因为他要负责帮我们使用者传送嘛！没错！基本上， MTA 的功能有这些：

1.收受外部主机寄来的信件：既然是邮件主机，那么‘接收信件’想必就是主要的功能啰！呵呵，答对了！所以啰， MTA 最主要的功能就是收受外部来的信件，只要这个信件里面有 MTA 内部的帐号时，那么这封信就会被 MTA 收下来；
2. 帮使用者传送 ( 寄出 ) 信件：既然可以收信，那么自然也就可以发信啰！没错啦！只要使用者具有合法的使用 MTA 的权力，那么该使用者就可以利用这部 MTA 将他把信传送出去！不过需要注意的是， MTA 会将信件送给目的地的 MTA 而不是目的地的 MUA 喔！不要搞错了！
3.让使用者自己的信可以收回去：使用者可以将放置在邮件主机的信件收到自己的个人电脑上面收看。

注：MUA都是直接找MTA不会直接找MDA，是由MTA找MDA

大致的功能就是这些啦！通常我们所说的 Mail server ( 邮件服务器 ) 就是指 MTA 而言的！

MDA ( Mail Delivery Agent ) ：
‘邮件递送代理人’主要的功能就是将 MTA 所收受的信件，依照信件的流向 ( 送到哪里去 ) 来将该信件放置到本机帐户下的邮件文件中 ( Mailbox )！
或者是再经由 MTA 将这个信件送到下个 MTA 去！而如果信件的流向是到本机当中时，这个邮件代理人的功能可不止是将由 MTA 传来的邮件放置到每个使用者的 Mailbox 而已，
他还可以具有邮件分析 ( filtering ) 与其他相关的功能呢！这个功能很了不起喔！怎么说呢？具两个例子来说好了：

1.如果你知道某个广告信件的主旨都是固定的，例如‘AV情色XXX’，你想将这种信件直接给他丢掉垃圾桶，可以吗？当然可以啰！透过 MDA 邮件分析的功能，就可以将信件丢弃啦！
2.如果有一天你要出差去，看样子可能一个星期碰不到电子邮件了，但是你又不想让一些朋友认为你在耍大牌都不回信的....这个时候你就可以利用 MDA 的功能，
让邮件主机分析到，当要送给你这个使用者的帐号的信出现时，就自动回覆一封回信，让寄件者知道你在忙碌中....呵呵！这样的功能是否很不错呢？还不止这样喔！其他的等一下后面再提吧！

Mailbox ：‘邮件信箱’说穿了，就是在你主机上面的一个目录下的，某个人‘专用’的信件收受文件啦！举个例子来说，系统管理员 root ，
在默认的情况下，他会有个信箱，默认的文件是在 /var/spool/mail/root 这个文件就是了，一个帐号都会有一个自己的信箱喔！
然后，当 MTA 收到 root 的信时，就会将该封信件存到 /var/spool/mail/root 这个文件中啰！使用者可以透过程序来将这个文件里面的信件资料读取回去喔！

/////////////

Step 1 使用者利用 MUA 寄信到 MTA 上面：通常我们使用 MUA ( 例如 Outlook express ) 写信的时候，你总是要定义出几个咚咚：
发信人与发信网站：对啦，总是要有这个信息才行的嘛！这个发信网站就是等一下 Step 2 接收信件的那个 MTA 啦；
收信人与收信网站：是的，就是 account@e-mai.server 的样式啦！那个 account 就是该 e-mail.server 里面的帐号啦！
好了，你在图一左上角的那部机器上面，也就是‘本地端用户使用电脑’利用 MUA 的功能 ( 例如 Outlook express 好了 ) 写好了信之后，按下 MUA 的那个‘传送’的按键，MUA 就会依据你所定义的主机位址将信发送到 MTA 上面；

Step 2 MTA 收到自己的信件，交由 MDA 发送到该帐号的 MailBox 当中：如果在 Step 1 所收到的信件中，那个 e-mail.server 就是 MTA 自己，此时 MTA 会将该信件交由 MDA 去处理，将信件放置在收进者的信箱中；


Step 3 MTA 将信再转送出去：如果由 Step 1 来的信件的收件人并不是 MTA 的内部帐号，那么该封信将会被再转送出去！由 Step 1 及 Step 3 的动作，我们也称为 Relay (邮件转递) 的功能喔！


Step 4 远端 MTA 收受本地的 MTA 所发出的邮件：远端的 MTA 会收受我们这部 MTA 的信件，并将该信件交给他的 MDA 来处理 ( Step 5 ) ，此时，信件会存放在远端的 MTA 上面，等待使用者登录读取或者下载回去！


整个流程大致上就是这样。这个时候，你由左上角的 MUA 将信件寄出之后，最后信件将会存放在右边那部 MTA 主机里面喔！还没有到达你的朋友的电脑 ( 就是右边的 MUA 那部电脑 ) ！这个时候，就要继续谈到收信的动作了！收信的动作有点像这样：
远端用户使用的电脑直接连接到他的 MTA ，跟 MTA 要求察看自己的 mailbox 是否有信件，而 MTA 透过 MDA 去检查之后，如果有信件的话，就会将他传送回使用者的 MUA 中！
同时，根据 MUA 的不同设定， MTA 会选择将该 mailbox 清除掉，或者继续保留！若继续保留的话，那么下次使用者再次的接收信件时，保留的信件会再次的被下载，因此，通常使用者 MUA 都是默认删除掉 MTA 上面的 Mailbox 内容的！

使用的协定
总是得瞭解一下使用的协定吶！我们在寄信的时候，亦即由 MUA 将信件发送到 MTA 的过程中，以及 MTA 将信转递到下一个 MTA 的功能，目前绝大部分的邮件主机都是使用 SMTP ( Simple Mail Transfer Protocol ) 这个协定，port number 为 25 啦！在寄信的时候，你的 MUA 会主动的连接 MTA 的 port 25 ，然后将信经由 MTA 的 smtp 协定 ( port 25 ) 而送出去！而邮件主机 MTA 在转递的时候，也是经由下一部 MTA 的 port 25 来将信送出去的！所以啰，不论你是使用什么 MUA 或 MTA 邮件架设软件，只要大家都支援 smtp ，那么信件就可以顺利的流传啰！
收信呢？收信则是 MUA 经由 POP ( Post Office Protocol ) 协定来连接到 MTA 的使用者 Mailbox，以读取或者下载使用者在 Mailbox 当中的信件。，目前常用的 POP 协定为 POP3 ( Post Office Protocol version 3 )，这个协定产生的 port number 为 110 ，所以，你的 MUA 经由 MTA 的 port 110 将信件由 MTA 的 mailbox 当中将信件收到本地端的 MUA 上面供你浏览！同样的，只要 MTA 与 MUA 同时支援 POP3 这个协定，那么信件就可以自由的收受了！此外，目前也很流行使用 IMAP 这个协定来收受信件。在 pop3 的收信协定中，一般来说，当 client 端收完了主机端的信件之后，则该信件会主动的被主机端所删除！不过， IMAP 则可以避免这个问题！ IMAP 具有让使用者 ( client 用户端 ) 自行定义信件放置的目录功能，以及是否要储存下载的信件之后，原信件是否保留在主机上面的功能！目前我们常见的 Web 接口的电子邮件使用，大部分就是以 imap 来达成的！
所以我们知道了！通常一部提供收发信件的 MTA ( 不考虑 Web 接口的邮件主机 ) 至少需要两个协定，分别是 SMTP 与 POP3 ！而且，只要你的 MUA 与 MTA 同时均支援 SMTP 与 POP3 ，那么彼此就可以沟通啰！这也是为什么你使用 Outlook express 寄出的信，但是你的朋友可以使用 Netscape 收下来的原因！总之，就是‘网络协定’的沟通啦！
什么是 Relay 与认证机制
由图一的寄信流程图里面的第三步骤 ( step 3 ) 中，我们知道， MTA 在分析收到的邮件之后，如果收件者不是本身主机的帐号，则会将该信件再传送到下一个 MTA 上面，这个由 MTA 帮忙转信的功能就称为 Relay 啦。那么在这个功能当中，您有没有发现一件奇怪的事情啊！那就是：‘是否任何人都可以使用我的 MTA 邮件主机服务器来传送他的邮件呢？’这个问题涉及到 Mail Server 的设定技巧了！如果设定不良的话，例如早期的 Sendmail 版本中，他就没有针对使用者来进行管制，也就是说，任何人都可以使用这样的一部邮件主机来达到信件传送的目的！这种主机我们称为‘Open Relay’的电子邮件主机喔！这里请仔细的思考一下，如果我的 MTA 对于寄信的人没有一个限制的话，结果会如何呢？呵呵！没有错，结果就是任何人都可以使用你的 MTA 来发信了！那有什么好可怕的？我们在前言的地方就已经稍微说过了，那个所谓的‘广告信、垃圾信件’的问题，而如果你的 MTA 没有对寄信的人作限制的话，由于任何人都可以使用你的 MTA 来发信，你的 MTA 将会变的‘很笨重！’什么意思？那就是，你的 MTA 将会帮任何人寄信，如此一来，你的‘网络带宽将会被广告信件所用光！’结果将导致你的 MTA 变成‘Open Relay 主机黑名单的一份子～’！！！

为了避免这个问题，所以，目前所有新版的邮件主机服务器架设软件 ( Mail server packages ) 默认的情况之下，都不会对外完全的开放 Relay 的功能的！默认通常仅‘针对主机 ( localhost ) 开放 Relay 的功能！’，不过，这样的 MTA 是可以收受来自 Internet 上面的，注明收件者是我们 MTA 主机内部帐号的信件的，因此， MTA 在‘收信’上面是没有问题的！

但是关闭了 Relay 之后，虽然可以避免掉我们 MTA 主机被当成广告信发送站，不过如此一来又造成了一些困扰！何解？因为通常我们仅针对主机，或者一些规范的 IP 或者是网段等信任的主机来开放他们的 Relay 的功能，所以在这个设定的范围内的 Client 端电脑可以自由的收发信件，至于没有规范到的 IP 来源的寄信信件，将完全的挡掉。然而万一您使用的是 ADSL 计时制的呢？又或者您是常常在外面出差的大老板，则你的 IP 将‘不会固定’，完蛋啦～怎么办？既不能完全开放 Relay ，又没有固定 IP ，无解了吗？呵呵！还好，有所谓的 邮件认证机制 来帮我们解决这个困境啦！

所谓的‘邮件认证机制’就是在刚刚我们图一的寄信流程图中，在 MTA 当中加入需要检查发信者的‘帐号与密码’比对的功能，当 MTA 接到来自 Client 端的传信需求时，会检查来自 Client 端的认证比对(帐号密码)，如果帐号与密码比对正确，则开始接受信件并帮忙转信，如果比对不正确则将该 MTA 并不会接受该封信件，直接在 Client 端显示‘不接受您的信件’之类的信息喔！目前有相当多种的邮件认证机制，这里我们偏向于介绍目前广为使用的 SMTP 邮件认证这个机制。

所谓的 SMTP 邮件认证机制，顾名思义，就是在 smtp 这个协定上面动手脚的一个机制啰！亦即是在寄信的时候，(由 MUA 到 MTA 那个 step 1 的步骤中 )，我们的 MTA 主机‘一定要求检验 MUA 发信者的帐号与密码！’这样的功能！果真能做到这一点的话，那么你的 MTA 就可以在经过认证之后，提供认证者的 Relay 功能，而不需要针对某些信任网域或 IP 来分别设定开放 Relay 的功能啦！因为经由‘认证’的机制，你的 MTA 会去分析寄信者的相关信息，通过后才会接受信件并帮他们寄信，否则就不接受信件！呵呵！没错！就是这样！透过这样的机制，您将不需要规范 Relay 的 IP 或网段，直接交给 SMTP 邮件认证来帮你管理你寄件者的 Relay 功能，从此以后，你的 Clients 就不会常常向你抱怨说 MTA 不稳定啰！
介紹使用 cyrus-sasl 這種密碼驗證的認證機制囉