谢谢反馈！从截图里的 invalid peer certificate 看，登录失败似乎更像是证书校验相关的问题，不一定是账号配置本身有误。
方便说一下你用的是什么邮箱服务吗？是手动配置的 IMAP/SMTP 账号，还是其他登录方式？我这边可以按这个方向检查一下。
小屏幕下显示不完整的问题也记下了，我会一起看看。
是的，手动配置的IMAP/SMTP 账号，本来想设置POP3的，发现没有的配置。是否使用SSL端口也没的选择。
mark一下。
目前在用的foxmail邮件搜索就是一坨
。
不好意思是我没说清楚，我现在用Sylpheed，但是因为它不支持OAuth认证，所以我想找个支持的替代。
看你后续的表述，要审核通过才能支持是吗？
我虽然不用邮件客户端但这个要支持一下，看上去很不错。不过我对不使用WebView有一点不同的想法。
首先如果是像Tauri一样使用系统提供的WebView并不会显著增加内存占用，因为代码页和只读数据页是系统级共享的，增加的内存占用有限。而且邮件客户端的HTML普遍远比普通Web页面简单，一般也不会像浏览器一样开几十个Tab，所以我觉得总体的内存占用是可控的。而利用第三方的HTML渲染库会引入大量的代码，且这些代码是无法与其它进程共享的，在解析并展示HTML时需要动态分配的内存也未必比WebView的Working Set小多少，在优化方面可能做的也没WebView那样好。
这都是次要的，最主要的一个是这个你提到兼容性问题，这个问题往往不容易解决，因为Web page的rendering很复杂。我不了解Blitz，应该是一个很新的项目，我已经十年没有做浏览器相关的开发了，不过之前我做过很久，所以我还是有点儿经验的。我觉得Blitz现在会给你带来维护上的Burden，将来可能会成为你的绊脚石。没人知道这个项目会活多久，如果将来死了，你面临的选择是自己Fork并维护、改成其它的第三方，或者被迫换回系统WebView。
最后，也是最重要的一点是安全性，我不知道你是否考虑过这个问题。用第三方库渲染HTML如果有Bug会直接导致你的进程Crash，而WebView是多进程的，不影响你的主程序。邮件里的HTML展示是一个很大的攻击面，是应该在沙箱里处理的。我不知道Blitz是怎么做的，但似乎是没有的。Chromium在这方面做的非常好，WebKit和Firefox现在也都赶上了。
我觉得作为一个产品，为了省内存（也许省不了多少）而牺牲了安全性和兼容性，而且花更多的维护成本是得不偿失的。
1 个赞
明白了，那你的需求正好相反 
你是想找一个支持 OAuth 的 Sylpheed 替代品。
Flectar Mail 现在已经支持 Google / Microsoft OAuth，功能本身是有的。只是我们的官方 OAuth 应用目前还在 Google / Microsoft 的审核流程中。
所以目前如果你愿意自己创建 OAuth 应用并填入 Client ID 等信息，现在就可以使用；如果你希望像普通应用一样直接点击 Google / Microsoft 登录，不需要自己配置这些凭据，那就需要等官方审核通过。
审核通过后这些配置会直接内置，普通用户就不需要自己处理 OAuth 凭据了。
2 个赞
首先非常感谢你花时间写这么详细的回复。这些问题其实都很重要，而且有些也是我们在选择这条路线时反复考虑过的。
关于 Blitz 的维护风险，我基本理解你的担忧。依赖一个相对年轻的渲染引擎，肯定会比直接使用系统 WebView 带来一些额外的不确定性。我们选择它的一个原因是 Blitz 并不是一个孤立的小项目，它是 Dioxus Native 很重要的一部分，而 Dioxus 本身在 Rust 生态里已经是一个相当活跃、并且有商业支持的项目。当然，这不能保证任何项目永远不会改变方向，但至少它不是一个个人业余时间维护的小型库。
如果未来真的出现 Blitz 停止维护的情况，对我们当然不是好消息。不过这里也有一个对我们有利的地方，就是邮件 HTML 所需要的范围其实远小于完整的 Web 平台。虽然现实中的邮件 HTML/CSS 有大量历史遗留和奇怪写法，但我们不需要 JavaScript、完整的 Web API，也不需要实现一个真正的浏览器环境。
我们现在其实已经维护了一些 Blitz 上游之外的补丁，也希望尽可能把这些改进贡献回上游。如果未来 Flectar Mail 有足够多的用户，而 Blitz 又真的停止维护，那么维护一个专门针对邮件场景的 fork 也会是一个现实的选择。它当然会增加维护成本，但范围会比维护一个完整浏览器引擎小得多。
关于内存，你提到系统 WebView 的代码页和只读数据页可以在进程之间共享，这一点本身没错。不过我们最终放弃 WebView，并不是基于理论推测，而是因为我们真的沿着这条路线做过一个完整版本。
Flectar Mail 最早其实是一个云端 Web 邮件客户端。后来因为 Gmail、Microsoft 等服务的 OAuth 和验证流程，尤其是 Google CASA 不同等级的验证成本，我们决定把方向改成本地优先的桌面客户端。
第一版桌面客户端就是基于 Tauri。那个版本已经相当完整，UI 甚至比现在更成熟。我们也投入了很多时间专门优化内存、渲染和交互性能，并不是拿一个普通的 Tauri 应用直接和现在的版本比较。
测试时我们的使用场景也比较重，包括多个 Gmail、Outlook 和 IMAP 账号，以及大约 8 万封未读邮件这样的数据量。即使经过大量优化，在这种真实负载下，Tauri 版本通常仍然在大约 460 MB 左右，同步期间很容易达到 750 到 850 MB。
而且真正促使我们换方向的不只是内存。我们一直无法完全消除操作过程中那种细微的延迟感。我们的目标从一开始就不是“做一个资源占用还不错的邮件客户端”，而是想把速度和响应性做到明显超过 Spark、Aerion 这类客户端。
所以最后我们想，与其再做一个基于 Tauri、Electron、Wails 等 Web 技术的邮件客户端，不如尝试一个真正不同的方向。
现在的 Flectar Mail 在实际使用中大约可以保持在 20 到 180 MB，而且启动、列表滚动、切换邮件以及大量数据下的响应体验都有非常明显的区别。一整个 Gmail 网页标签本身有时就可以接近几百 MB，而这里我们运行的是完整的邮件客户端，包括多个账号、同步、日历、联系人等。
另外，这条路线也让我们可以使用同一套组件和设计系统，从 Linux、Windows、macOS 一直到 Android 和 iOS 保持非常一致的体验，而不依赖不同平台各自的 WebView 实现。
至于安全性，这也是我们从一开始就非常重视的部分。Blitz 本身没有 JavaScript 引擎，邮件中的脚本不会执行，也不存在完整浏览器里的大量 Web API。因此和嵌入一个完整浏览器运行时相比，我们实际上从设计上就减少了相当一部分攻击面。
当然，我们仍然把邮件 HTML 当作完全不可信的输入。HTML/CSS 解析、布局和资源处理这些路径都需要持续做防御性处理和测试，这也是我们在完善 Blitz 集成时非常关注的部分。
所以我们选择 Blitz 并不只是为了省一些内存。它确实是一条工程上更有挑战的路线，但换来的性能、资源占用、跨平台一致性，以及一个更小、更可控的邮件渲染环境，对我们来说都很有价值。
我自己当初迁移到 Linux 时，邮件客户端也是最先让我觉得缺少一个真正满意选择的地方之一。所以我们还是很希望 Flectar Mail 最后能在这里找到自己的位置，做出一个真正快速、轻量，而且和现有方案明显不同的邮件客户端
再次感谢你这么认真地分析这些问题，这种反馈对我们真的非常有价值。
5 个赞
没有JS引擎确实能减少攻击面，但是并非高枕无忧。HTML/CSS解析处理的Bug，UTF8编解码的bug都可能产生漏洞。另外，用Tauri来做App和只用WebView渲染HTML邮件是两码事。用Tauri做App意味着所有的渲染和逻辑都是基于Web的，内存占用自然很大。而主程序用Rust，只是在HTML Mail用WebView应该会好很多。
不过这都是我的猜测，你们肯定是经过深思熟虑的，不用在意我的看法。希望你们的产品越来越好。
1 个赞
你们对产品的打磨和技术的研究非常令我敬佩，得手动给你赞一个 
在微软毙掉了 UWP email后一直没有找到一个合适的Email客户端，等OAuth通过了就试试。
非常感谢大家这几天的讨论、建议和鼓励！这个社区的氛围真的很好，也给了我们很多有价值的反馈
后续有比较重要的里程碑，比如 Google / Microsoft OAuth 审核通过、重要功能更新等，我会回来同步一下进展，让大家可以继续关注项目的发展。
再次感谢大家！
1 个赞
有个需求，希望开发者能考虑一下。
能否给每个邮件账号指定不同的代理？
比如这样：
[email protected] 默认网关
[email protected] cocks5 服务器A
[email protected] cocks5 服务器B
[email protected] Https 服务器C