邮件问题，清楚解答。

先在网页邮箱中核对同一账户和文件夹。若邮件存在，检查网络、所选账户、授权和客户端同步；若网页也没有，检查服务商的垃圾邮件、规则和容量。重新连接账户前，先保存错误信息。

收信和发信使用不同连接。按服务商文档检查 SMTP 地址、端口、TLS 和登录方式，再对比网页邮箱及另一网络。连接失败、授权失败和收件方拒收需要分别处理。不要为发送邮件而关闭证书验证。

请选择通过 Google 登录。账户普通密码不能替代客户端所需的现代授权。检查应用权限是否被撤销、组织是否施加限制；重新连接时，确认浏览器选择的是原来的邮箱地址。

应用专用密码为客户端提供独立访问权限。是否需要取决于服务和连接方式；支持 OAuth 时通常优先使用 OAuth。手动配置 Yandex 时按最新文档操作，包括启用 IMAP。不要改用主密码，也不要关闭双重验证。

向托管商确认 IMAP、SMTP、完整用户名、授权方式及 TLS 要求。网站域名与邮件服务器地址可能不同。核对自动发现的设置与官方文档，首次测试向外部地址发送一封邮件并接收回复。

IMAP 将文件夹及变更与服务器同步。POP 通常下载收件，并采用不同的副本保留规则，因此一台设备上的删除或已读状态未必影响另一台。更换协议前先保存本地邮件，旧归档可能不在服务器上。

先区分邮件尚未同步，还是已到客户端却没有通知。检查后台运行、电脑睡眠和通知权限。服务器支持时 IMAP IDLE 可及时获取变更，但无法消除断网或设备限制。

频繁建立连接可能触发服务限制。优先使用服务器支持的通知，或能断线重连的持续 IMAP IDLE 连接。调整轮询间隔前先查服务商限制；通知也取决于网络和应用是否运行。

Gmail 的同一邮件可以有多个标签，IMAP 中这些视图类似文件夹，所以邮件可能同时出现在收件箱和所有邮件中。删除前核对 Message-ID 和标签。多处显示未必意味着发送方重复投递。

先确认收件人确实收到两封，还是只有您看到两个副本。服务器和客户端可能各保存一份。对比 Message-ID、时间及已发送文件夹设置。状态不明时再次点击发送，可能造成真正的重复投递。

检查每个客户端使用的协议、服务器垃圾箱位置，以及同步是否完成。POP 的重新下载和保留规则不同于 IMAP。先删除一封测试邮件，再对比网页邮箱。查明原因前，不要批量清空垃圾箱。

客户端需要获取文件夹结构、邮件头及所需内容。大附件、大量标签、慢网络和服务器限制都会延长时间。先等待首次同步完成，再观察新邮件速度。重装并清除缓存可能让下载重新开始。

离线只能使用已经下载的数据。列表里有标题，不代表正文和所有附件都已保存。出行前打开所需邮件和文件，再断网验证。收取新邮件及实际发送仍需网络。

原因可能包括域名或 IP 信誉、发件认证、内容及收件人投诉。请对方检查垃圾箱并标记为非垃圾邮件。自有域名应把邮件头交给管理员，检查 SPF、DKIM、DMARC。换客户端不保证进入收件箱。

检查实际发送路径及收件邮件头中的认证结果。DNS 记录须对应实际服务，DMARC 还要求域名对齐。转发可能改变验证结果。即使认证成功，信誉、投诉和收件方限制仍会影响投递。

打开退信报告，找到错误码、收件地址及服务器说明。地址拼错、邮箱已满、临时拒收和发件方被封锁需要不同处理。先解决原因；状态不明时通过其他渠道确认收件，避免重复发送。

检查文件大小和类型，发送及接收服务都可能设限。可执行文件、危险宏及部分压缩包可能被拦截。大文档应使用公司允许的文件存储，并设置合适权限。不要通过改名绕过危险文件保护。

可能是编码错误，而不是翻译错误。对比网页邮箱中的同一邮件，请发送方用 UTF-8 纯文本重发。诊断时需要原始 MIME 邮件头和 charset。翻译工具不能可靠还原已经损坏的文本。

确认服务是否提供标准 IMAP/SMTP、OAuth 或兼容桥接程序。部分加密服务需要桥接应用，另一些不提供普通 IMAP；企业也可能禁止第三方客户端。服务徽标目录不代表每种登录方式都可用。

核对账户地址、协议、文件夹和最后同步时间。本地文件夹或 POP 归档可能根本不在服务器上。对比网页及两台设备中的同一邮件，也检查筛选和视图：统一列表与单个文件夹显示的范围不同。

把收件分类与实际工作分开。分类时决定需要回复、转为任务、稍后阅读还是仅保存。安排适合自己的查收时段，并约定真正紧急事项的联系渠道。重复通知可用规则整理，但先验证匹配结果，再加标签或归档，不要一开始就自动删除相似邮件。

先处理近期邮件和仍有期限的承诺。旧邮件按发件人、时间和主题分批整理，已完成的归档，需要行动的加入任务。批量操作前检查搜索结果并排除需保留项。收件箱清空不代表工作完成，还要检查等待回复和延期事项。

Gmail 归档会移出收件箱，但仍保留在所有邮件和搜索中，收到回复时会回到收件箱。适合存放已结束的讨论和日后可能查询的资料。真正无用的内容才删除，并了解服务商的垃圾箱规则。找不到邮件时先查归档和搜索范围，再查垃圾箱。

按日后查找方式设计结构。稳定项目不多时，少量分类加发件人或日期搜索通常够用。Gmail 标签不同于文件夹，一封邮件可有多个属性。将行动状态与主题分开，例如等待回复与项目 A。不要为每封临时邮件创建以后不会查看的新分类。

先对比 Gmail 网页和客户端，确认消失的是邮件还是分类。使用 GWSMO 时，Outlook 文件夹会显示为 Gmail 标签，部分旗标和变更同步方式不同。查明范围前不要批量重分，先检查现有规则和备份。同步文档不保证自动恢复以前手动设置的分类。

按发件人、收件人、日期和附件缩小范围。Gmail 可组合 has:attachment、filename:pdf、from: 和 after:。找不到时检查归档、垃圾邮件及垃圾箱，in:anywhere 可扩大搜索。记得文件名也有帮助；搜索附件内文与搜索带附件的邮件不是同一功能。

使用支持所需账户的统一收件视图，它可以汇总邮件而不在邮箱之间搬移；Thunderbird 的统一模式采用这一方式。保留切换单独账户的入口，以检查其文件夹和规则。工作及私人邮件混合显示时，回复前尤其要核对发件地址和收件人。

邮件会话与项目分组用途不同。主题改变可能打断会话，Gmail 文档也说明了这一点。正文有相同订单号或手动改主题，并不保证散落邮件合并。用标签、订单号搜索或关联任务整理订单，让会话保留连续回复的上下文。

继续同一讨论时使用回复并保留主题，不要手动不断增加前缀。开始新话题时另写一封主题清晰的邮件。注意服务差异，例如 Gmail 更改主题会创建新会话。长历史用会话视图阅读，新回复中明确指出所回应的问题或决定。

简单行动只需在特定时间回来处理时，可使用稍后提醒。Gmail 会暂时隐藏邮件，再于指定日期时间放回收件箱顶部。多步骤工作应创建有结果和期限的任务。不要把所有邮件都堆到周一早晨，先估算工作量，再按可用时段安排。

建立明确的等待回复分类，并设下一次检查日期。发送时写清期望结果，适当时约定期限，再稍后提醒会话或创建行动提醒。收到回复后重新评估并移除过期标记。定期检查整个等待列表，单封邮件回到收件箱不代表事项已经结束。

客户端支持时，从打开的邮件创建任务。Gmail 可使用添加到任务，或拖入任务侧栏。创建后将模糊主题改为具体行动，补上期限和细节，并检查能否回到原始通信。一封邮件可能包含多个承诺，建卡前先确定所需结果。

为承诺或结果建卡，不要给每条通知自动建卡。列表示工作阶段，标签可表示主题或客户。Atlassian 建议可视化流程并限制同时进行的工作。先设置较小的在办卡片上限，定期检查阻塞项。产出结果后再完成卡片，并保留原始邮件供查询。

摘出日后需要的约定、决定、订单号及下次沟通问题，保存为标题清楚、注明来源的笔记。把参考资料与待办分开，例如 Google Workspace 用 Keep 记笔记、Tasks 管任务。笔记若产生行动，另建有期限的任务，不要仅藏在笔记文字中。

写好正文并核对收件人与附件，再设置日期时间。确认时区：Gmail 使用安排时的时区，可能延迟几分钟。修改 Gmail 定时邮件时，先取消发送，再编辑草稿并重新排期。周期报告还需单独安排准备工作，一封定时邮件不会建立重复流程。

从精确条件开始，如发件地址、收件地址、专用订阅地址或稳定主题片段。先搜索确认匹配邮件，再创建规则。Gmail 筛选器可加标签、归档或标记邮件。先选择易验证的操作，定期复查匹配范围；会话里的新回复也须满足条件才会触发。

确认打开的是原始邀请，以及客户端是否支持日历邮件。Google Calendar 和 Gmail 可回复接受、拒绝或待定，组织者会收到通知。没有按钮时，到服务商网页或日历查看同一邀请。确认前核对时间、参与者和地点，不要因显示不便再创建一场相同会议。

把完成期限与实际工作时段分开。先估算下一步所需时间，再找空闲时段并留余量。Google Tasks 区分开始时间与截止日期。安排多人会议时，有权限才可在 Google Calendar 查看对方空闲；否则用邮件协商几个选项。优先级变化后重新评估预留时段。

先确定延期原因：优先级变化、缺少资料、受阻或时间估算不准。更新日期，并在描述或评论写出下一步具体行动。Google Tasks 可修改任务、日期和细节。反复延期时，缩小下一步范围或重新考虑承诺；每日检查逾期和等待外部回复的事项。

固定安排可设为重复事件，并检查系列结束日期。Google Calendar 修改时可选择影响哪些事件。提醒要留足准备时间，不要只在开始时通知。单独检查通知权限和所选日历，因为通知设置属于个人。用近期事件测试，即使开启通知也要养成查看当日日程的习惯。

当意思已明确、时间主要花在措辞上时，AI 很有用，例如把笔记写成邮件、缩短长回复或调整商务语气。提供收件人、目的、已核实事实和期望长度，再比较提问及审核所用时间。简短的日常确认手动回复可能更快。

偶尔使用且能控制交给服务的数据时，复制也可行。频繁回复和修改时，内置助手减少窗口切换，也便于对照通信。但有 AI 不代表上下文充分或结果准确，应分别评估回复草稿、改写、翻译及模型能获取的邮件范围。

提供几封已去除个人信息的短邮件，并说明新回复的收件人。用具体特征描述风格，如短句、礼貌称呼、少铺垫、语气平和。生成草稿后对照样例检查。仅说友好通常不够，还要核对意思，以及对该收件人的称呼是否恰当。

先分别列出事实、立场和可接受的下一步。要求 AI 去掉指责和尖锐措辞，同时保留边界，不新增折扣、承诺或未作出的承认。可先承认问题，简述情况，再提出具体行动。发送前确认温和语气没有改变决定或约定条件。

可以。明确只修正拼写、标点及明显语法错误，保留含义、结构和称呼。争议修改可要求先解释。纠错与重写用途不同，明确范围可减少不必要的语气变化。使用前对比原稿和修改稿，尤其检查否定、条件、名称和数字。

明确提供事实，并要求缺少资料时标注。禁止猜测的指令有帮助，但不能替代审核。发送前按原邮件核对姓名、收件人、日期、时间、金额、链接和义务。尤其检查确认、周五前完成等表述，语气有说服力并不代表双方已经同意。

说明目标语言、收件人、商务背景和正式程度。补充简短术语表，要求保留姓名、货号、金额及日期。歧义处应单独标记而不是猜测，并按原文检查条件和否定。明确要求有帮助，但质量仍取决于模型及语言组合。

菜单语言、邮件语言和翻译规则是不同设置。例如 Gmail 在邮件语言与偏好不同时提示翻译，也可手动启动。译文若改变版式，应核对原文中的表格、链接和签名。自动翻译便于阅读，但开启它不代表每个条件都翻译正确。

可以，前提是生成与搜索向量都真正本地执行，所需模型也已下载。逐项检查组件，本地界面仍可能调用外部 API，Ollama 也有云端模型。使用本地模型并核对云功能设置；同步时连接邮箱服务器是另一项网络活动。

查看模型声明的语言、可用内存及典型任务的效果。Qwen3 列出俄文和英文，但不能保证任何邮件的质量。用匿名样例比较短回复、商务邮件、翻译和摘要，并分别评估各语言的事实保留、语法、语气和响应时间。

模型大小、加载方式、CPU 或 GPU 及上下文长度都会影响速度和内存。即使任务简单，大上下文也需更多内存。先用合适大小的模型处理一封短邮件，再逐步增加长度。Ollama 的 ollama ps 可查看模型所在设备和分配上下文，不存在适用所有电脑的统一响应时间。

指定格式，包括讨论主题、已作决定、分歧和未解决问题。模型须按正确顺序获取所需邮件及作者、日期。超出上下文时分段处理，并保留与原文的关联。摘要可帮助快速了解情况，准确措辞、期限和最终决定仍须查原始邮件。

要求分别列出行动、负责人、期限及依据邮件。缺少信息时标记未注明，便于区分明确任务与模型猜测。按通信逐项核实，尤其检查延期和取消事项。自动生成清单应作为个人规划草稿。

要求区分建议、已确认决定和未解决问题，并标明作者与日期。没有前文的简短同意可能针对另一事项。保留解释这类回复的邮件并核对事件顺序。分支互相矛盾时摘要应显示矛盾；最终协议须依据原文，而不是流畅的转述。

关键词搜索查找指定词语及精确特征；语义搜索比较文本向量，可用不同措辞按主题查找，例如不记得标题时寻找延期付款讨论。它寻找相似内容，结果仍需核实。精确发票号或发件地址通常适合直接按字面搜索。

草稿生成只需给定文本和指令。查询整个邮箱还需先获取邮件、建立索引并检索相关片段。嵌入模型将文本转换为向量，索引与查询须使用同一模型，再将找到的邮件交给生成模型作上下文。没有这些访问，它不知道归档内容。

先使用检索相关邮件并提供给模型的方式，即 RAG。通过更新索引即可补充信息，无需反复训练。微调可用于行为或格式任务，但本身不能建立可靠的邮件知识库。按检索到的邮件核实答案，并注意哪些文件夹和日期已入索引。

先按已知发件人、日期范围、主题、订单号或文件名缩小范围，再用语义搜索处理模糊描述，并查原文确认日期。Gmail 可用 from:、after:、before:、filename:。邮件日期、下单日期和付款日期可能不同，先明确要找哪一种。

能读取正文不等于能读附件。需单独获取文件并交给适合的模型，或提取文本；扫描件可能需要 OCR 或图像模型。检查实际处理的文件、页数和可读性。金额、货币和付款信息须对照文档，尤其当模型说没有数据时。

能，邮件中的命令可能被模型误当成指令，这称为提示词注入。把来信当作分析数据，并在模型之外限制真实操作。仅加一条系统指令不能保证安全。检查草稿和摘要中的异常要求，单独确认数据传输和发送操作。

在客户端选择目标语言，先用一封收件测试。有些客户端依据界面语言提示翻译，另一些有独立设置，例如 Gmail 在邮件语言与偏好不同时提示。确认是否每次都要手动启动，并保留核对原文的方式，尤其在回复期限、付款和行动之前。

先写完俄文草稿，用短句说明请求、行动和期限，再选收件人语言并核对发送窗口里的译文。收件翻译与发件草稿翻译可能是不同功能，Yandex Mail 也分别说明。替换草稿前保存原稿，以免修改时丢失含义和约定细节。

要看客户端、所连账户及翻译工具的组合。有翻译功能不代表每个邮箱都能使用；Gmail 文档明确说明该功能针对 Google 账户，不适用于 IMAP 账户邮件。用测试邮件验证所需服务，并确认处理文本的模型及是否需要单独授权。

先查看原文是否需要翻译。短语、签名或其他语言块可能干扰整封邮件的识别。工具支持时明确选择源语言和目标语言，重译所需段落。HTML 群发邮件还应检查模板的语言标记。若收件人已有专门语言版本，可关闭多余的自动翻译。

若能核对回复，可先使用对方来信的语言。简短说明使用了翻译，并询问后续偏好的语言。首次联系可把原文作为独立、有标识的段落附上，帮助解释歧义。不要逐句交错两种版本，也不要仅因对方有国际邮箱就假设其懂英文。

工具接受指令时，先说明收件人和正式程度，再同时检查称呼、代词、问候及签名，礼貌标题不能决定全文语气。部分翻译器仅为某些语言提供正式程度选项。没有此设置时，使用已核实的称呼，请懂该语言的人检查新商务联系的第一份模板。

先列出必须保持可识别的人名、公司、产品及技术术语。使用对方和公司的正式写法，不要直译名称里的普通词。工具支持术语表时可设对应关系。翻译后逐项对照原文和对方签名；文字流畅不保证品牌名正确。

把数字与正文分开核对，包括订单号、金额、货币、数量、日期和时间。国际邮件不要留下未解释的 03/04/2026 等歧义日期；月份用文字、年份用四位数字，通话注明时区。翻译可改变当地书写格式，但不能改变数值、货币或约定期限。

翻译器可能把技术字符串当普通文字，改动空格、符号或地址。逐字符核对 URL、邮箱地址及代码，损坏时使用原链接。自行集成时选择支持 HTML/XML 的处理方式，并在引擎允许时排除不应翻译的块。链接文字与实际地址是不同字段。

先区分已是目标语言的片段及需翻译的片段。不要给整封邮件强行设定不适合部分段落的源语言。出错时按语义块分别翻译，并保留顺序。核对按钮文字、日期和引用；自动通知可能包含多个语言部分，翻译一个段落并不会统一全文。

理解歧义句时结合邻近句子及其回应的问题。保留消息边界、作者和引用，避免把旧承诺误作新回复。部分邮件翻译器会跳过签名和引用历史，重要未译片段应带上下文单独翻译。不要将整段历史译文当作自己的新文字发送。

先区分客户端翻译邮件，还是浏览器翻译整个网页。复杂 HTML 应选理解标记的工具，处理后核对列表、表格行和链接文字。格式损坏时改用短段落和明确标记的纯文本。群发前先寄给自己测试，其他语言较长的词会影响换行和布局。

正文与附件是不同对象。客户端翻译了邮件，不代表处理了 PDF、表格或图片。检查文档工具支持的格式、大小限制和识别文本的能力。扫描件先确认识别文字可读，再核对页数、表格和数字；附件文件名不是其内容的译文。

先确认翻译实际在设备、公司服务器还是外部服务执行。应用装在电脑上本身不能证明本地处理。Ollama 文档区分本地和云端模型，并可关闭云功能。敏感文本应采用已验证的本地路径，遵守组织规则，不把秘密放进诊断报告或未验证的外部翻译器。

取决于引擎和模型。提前安装运行环境、下载模型，再断网测试。使用 Ollama 不自动代表离线，因为它也支持需要联网的云模型。还要区分翻译已有文本与收取新邮件或发送回复，后两者需要连接邮件服务器。

检查是否选中了正文、引擎是否运行及语言组合是否受支持。再用不含引用、图片和签名的一句普通文本测试。邮件功能与独立翻译器的限制可能不同，应查对应功能的文档。简单测试成功后逐步加入原文，记录从哪个片段开始出错。

先修复原文显示再翻译。乱码可能来自编码错误或已丢失的数据，AI 不能可靠猜回未知字符。换客户端比较，必要时请发送方重发修正版。新内容用 UTF-8，并实际以该编码保存；仅修改编码声明并不够。

分别核对含义和显示。这些语言从右向左，但数字、地址和拉丁字母名称可能保持其他方向。不要手动反转整行。HTML 通过方向属性和内容隔离控制显示，收件客户端也有影响。发送测试邮件，请懂该语言的人核对数字顺序、括号、标点和链接。

译文可能仅用于阅读显示，不改变转发内容。打开转发草稿，检查里面实际是什么文本。需要时将核对过的译文放在单独、有语言标记的段落，保留原文及作者信息。不要以为阅读自动翻译规则无需额外设置就会翻译并寄给第三方。

逐项对照原文和译文：谁提出什么要求、附带什么条件、期限何时。检查新增承诺、遗漏限制、否定及原本没有的细节。风格自然不证明准确。重要邮件请懂语言和领域的人独立审核；原文已含歧义时先向作者确认。

取决于架构和授权。客户端需读取邮件来显示，但处理可能在设备上，也可能经过开发者服务器。检查数据政策、同步路径和外部功能。仅有本地这个说法，不能证明不存在任何网络交换。

地址和服务器不变时，服务商仍负责邮箱。安装新界面不会自动搬迁邮件，也不会增加端到端加密。若需不同的隐私模式，应另选服务商及兼容加密方式，同时考虑收件人的能力。

它是显示邮件时可能加载的远程资源，其请求可暴露加载、时间和网络信息。限制外部图片可减少这一渠道，但不能消除跟踪链接等方式。自动加载及代理也可能让打开率失真。

已读回执可被拒绝，跟踪像素只记录资源加载，不证明人理解了正文。代理和预加载会产生误报，禁用图片又会隐藏真实打开。重要决定应请对方简短确认或约定其他渠道，不要只看单项指标。

关闭远程图片可减少加载时的数据传输，但点击个人化链接仍可能被发送方网站记录。这并非完全匿名。可疑邮件应核对链接地址，并手动打开所需服务。外部内容与附件文件也应区别对待。

检查完整发件地址、链接域名和请求内容。不要通过意外邮件中的链接输入密码或付款信息。自行打开服务，并通过已知联系人确认。熟悉姓名、徽标和无错文字不能证明发件人真实，发现可疑情况应通知安全团队或服务商。

二维码同样可指向假网站，而且地址更难发现。不要为了登录或收款而扫描意外代码，直接打开官方服务。若已输入资料，使用官方恢复入口，并通知负责人员。

发件字段可以伪造，地址相同不足以证明被入侵。检查登录历史、已发送邮件、转发规则及原始邮件认证结果。有陌生会话时按官方流程保护账户，不要回复勒索者或打开其链接。

在可信设备上打开服务商官网，恢复访问并更改密码。检查陌生设备、第三方权限、应用专用密码、转发和筛选器；开启多因素验证，更新恢复资料。工作邮箱立即联系管理员。若其他访问仍在，仅改密码可能不够。

不一定，可能有人输错地址或尝试登录。不要分享验证码或批准未知请求。自行打开服务的安全设置，检查事件和会话；发现异常时使用官方恢复流程。检查无需点击意外邮件中的链接。

OAuth 允许应用申请特定权限，无需把主密码交给它。确认前检查应用名称、账户和权限范围，之后也可在服务商处撤销。OAuth 不会让所有应用自动安全，仍应判断开发者及所请求访问的用途。

在服务商账户的已连接应用中撤销不需要的权限。若使用应用专用密码，还要单独删除该密码。卸载电脑应用未必撤销服务器权限。撤销后检查其他设备，确保仍需使用的连接没有受影响。

TLS 保护特定网络连接，不同于只供持有密钥的最终参与者读取内容的端到端加密。邮件服务器和本地副本需分别评估。连接安全标志不意味着电脑上的邮件数据库也用独立密钥加密。

先按服务商文档核对服务器名称、设备日期和 TLS 设置。证书过期、域名不符或颁发机构未知需由管理员修复，不要长期关闭验证。企业服务器应向 IT 部门确认批准的配置方法。

已下载邮件和附件可能仍在磁盘。使用可靠的 macOS 登录、锁屏及 FileVault，并保留 Apple 提供的恢复方式。设备丢失后，还要在服务商处撤销邮件会话和应用访问。磁盘保护与撤销服务器权限相互补充。

不一定，连接机密与邮件主数据库可采用不同存储机制。安全密码库不代表所有附件和正文自动加密。评估时分别检查令牌、邮件缓存、备份、日志和网络功能，也要考虑 macOS 账户安全。

检查所选引擎和执行路径。正确配置的本地模型在设备处理数据，外部服务则收到传给它的上下文。保存和使用规则取决于服务商。核对组织政策及工具设置前，不要传输工作或敏感通信。

可以，正文可能含有试图改变模型行为的指令。将邮件视为数据而非授权，不允许它自行批准发送、泄露秘密或日历操作。检查建议行动和收件人，防护指令可降低风险，但不能保证完全安全。

熟悉地址不保证安全，账户可能被盗，发件字段也可伪造。确认文件是否预期收到，有疑问时通过另一已知渠道询问。不要启用意外邮件中的宏或运行程序。服务商的文件类型限制有帮助，但不能证明每个附件安全。

只提供必要描述：应用版本、邮箱服务商、事件时间、错误码和匿名示例。非诊断所需时遮盖地址、主题、正文、令牌及附件内容。通常无需一开始就导出整个邮箱；工作邮件应先与管理员确认数据传递。