从写信到收信的服务链
用户通常通过邮件用户代理编写和阅读消息。提交服务将新消息引入邮件处理系统，传输代理继续中继，投递后再由收件人的访问工具取用；这些角色可以分布在不同程序和机构中。
这种结构允许发送者和接收者不同时在线。地址告诉系统往哪个邮箱投递，但个人、组织账号、邮件列表及自动程序都可能使用邮箱，不能仅凭地址格式判断真实作者。
参考：[1]
消息字段与正文
互联网邮件格式把消息分成字段区和可选正文，两者由空行隔开。From、To、Subject等字段为读者或软件提供信息，却不应与服务器传输时使用的信封路径混为一谈。
消息标识和回复相关字段可以帮助客户端组织会话，但客户端如何显示对话并不等于网络只有一条持续连接。邮件是可以保存和再次处理的消息，而非只在屏幕上出现的一次通知。
附件与编码的分层
MIME为正文增加媒体类型、字符集及传输编码等表示规则，让文本之外的内容能够被识别和处理。客户端需要根据内容类型选择展示方式，不能把所有正文都当作同一字符编码的纯文本。
Base64等传输编码解决表示问题，不提供秘密性。附件是否可靠、发件人是否获授权以及消息如何加密，仍需要其他检查或协议，不能由“符合邮件格式”推导出来。
一封邮件还可用multipart把正文、附件或其他内容拆成各自有字段和正文的部分，Content-Type中的boundary参数规定它们之间的分隔行。分隔依赖这种结构，而不是看到附件文件名就自行断开；各部分可有自己的媒体类型和传输编码。RFC 2045还限制multipart整体的传输编码，不能简单把整套嵌套结构一律再套Base64，假定所有接收端都能按原语义处理。