I love receiving spam mail! — No one ever.

我喜欢收到垃圾邮件！ - 没有人。

I use Gmail, which does a fantastic job of weeding out spam and sending them straight into the spam folder. Over time, however, it’s still frustrating watching the spam folder count increase and having to periodically sift through it for false positives.

我使用Gmail，它可以很好地清除垃圾邮件并将其直接发送到垃圾邮件文件夹中。 但是，随着时间的流逝，看到垃圾邮件文件夹数量增加并不得不定期筛选它以防误报，仍然令人沮丧。

The types of spam email that irritate me most are not emails claiming of generous Nigerian fortunes or wondrous enhancement drugs, but emails from legitimate companies who I’ve never interacted with before. So how did they get my email? Someone must have sold or disclosed my email address to them and I would really like to know who they are.

最让我烦恼的垃圾邮件类型不是声称拥有大量尼日利亚财富或奇妙的增强药物的电子邮件，而是来自我从未接触过的合法公司的电子邮件。 那么他们是怎么收到我的电子邮件的呢？ 肯定有人出售或向他们透露了我的电子邮件地址，我真的很想知道他们是谁。

But there is no way of knowing exactly who disclosed my email address, and no way of taking action/stopping the email, right?

但是无法确切知道谁公开了我的电子邮件地址，也无法采取措施/停止电子邮件，对吗？

Well, not quite.

好吧，不完全是。

Disposable, single-use email aliases allow you to shield your actual email address, while forwarding all received emails to your personal inbox.

一次性使用的电子邮件别名可让您屏蔽实际的电子邮件地址，同时将所有收到的电子邮件转发到个人收件箱。

(Link to project.)

( 链接到项目。 )

为什么使用Heimdall (Why use Heimdall)

To be clear, this idea certainly isn’t novel.

需要明确的是，这个想法当然不是新颖的。

A quick Google search turns up a number of different products and services that do exactly this.

快速的Google搜索会发现许多可以做到这一点的不同产品和服务。

I could easily have opted to use any of those, but here are three reasons why I decided to build Heimdall:

我可以轻易选择使用其中任何一个，但是出于以下三个原因，我决定构建Heimdall：

1. Third-party services are either paid, or offer a free tier with limitations. Depending on which service you use, you may or may not find the limitations acceptable for your use cases.第三方服务要么是付费的，要么提供有限制的免费套餐。 根据您使用的服务，您可能会也可能不会发现用例可接受的限制。
2. Using a third-party service means having to trust that company with your emails. Most services are closed-source and proprietary — you can’t ever be sure that your data isn’t stealthily harvested. Even if it’s open-source, you can’t be 100% sure that the service you are using is running on the same codebase.使用第三方服务意味着必须通过您的电子邮件信任该公司。 大多数服务都是开源的和专有的-您永远不能确定自己的数据不是偷偷收集的。 即使它是开源的，您也不能百分百确定所使用的服务正在同一代码库上运行。

Even as far as open-source projects go, Heimdall isn’t the first or only one. There are a bunch of those on GitHub. But from what I could tell, those projects are one or more of the following:

就开源项目而言，Heimdall也不是第一个或唯一一个。 GitHub上有很多。 但是据我所知，这些项目是以下一项或多项：

1. They are codebases of actual services (either free or paid) and does not include setup instructions. Heimdall is meant for individual users to deploy and use and contains user-friendly setup instructions.

   它们是实际服务(免费或付费)的代码库，不包括安装说明。 Heimdall供个人用户部署和使用，并包含用户友好的安装说明。

2. They have very complicated setup instructions, including server configuration requiring in-depth technical know-how. Heimdall runs on serverless computing, so there is zero server configuration or provisioning.

   他们有非常复杂的设置说明，包括需要深入技术知识的服务器配置。 Heimdall在无服务器计算上运行，因此服务器配置或置备为零。

3. I actually found a project that is very similar to Heimdall (it runs on AWS Lambda and SES) but contains manual, lengthy setup instructions. Heimdall uses the Serverless framework (not to be confused with small-letter serverless in Point 2 above) so you can deploy with a single command.

   我实际上找到了一个与Heimdall非常相似的项目(它在AWS Lambda和SES上运行)，但是包含手动的冗长的设置说明。 Heimdall使用 无服务器框架 (不要与上面第2点中的小字母无服务器混淆)，因此您可以使用单个命令进行部署。

But more importantly, I built Heimdall because it’s fun! I’ve always enjoyed working on pet projects, and this is a great opportunity for me to pick up AWS and learn about the Serverless framework.

但更重要的是，我创建了Heimdall，因为它很有趣！ 我一直很喜欢从事宠物项目，这对我来说是一个很好的机会，可以选择AWS并了解Serverless框架。

基础设施 (Infrastructure)

I’m using AWS’s Simple Email Service (SES) to send and receive emails, S3 for storage, and Lambda functions for serverless computing. Here’s how it works:

我正在使用AWS的简单电子邮件服务(SES)发送和接收电子邮件，用于存储的S3和用于无服务器计算的Lambda函数。 运作方式如下：

All received emails trigger SES to store the email as a file in a S3 bucket, which triggers a Lambda function. Depending on the email, one of several things could happen:

所有收到的电子邮件都会触发SES，将电子邮件作为文件存储在S3存储桶中，从而触发Lambda函数。 根据电子邮件的不同，可能会发生以下几种情况之一：

1. The email gets forwarded to your personal email address电子邮件将转发到您的个人电子邮件地址
2. The email gets forwarded to the original sender (when you reply)电子邮件将转发给原始发件人(当您回复时)
3. A command is invoked by you (e.g. to generate a new alias)您调用一个命令(例如，生成一个新的别名)
4. Nothing happens (when someone emails an invalid/disabled alias)没有任何React(当有人通过电子邮件发送无效/禁用的别名时)

I chose to use AWS for practical reasons: I’m totally new to cloud computing, and AWS being the most popular cloud computing service means it is easier to find guides and resources online.

我出于实际原因选择使用AWS：我是云计算的新手，并且AWS是最受欢迎的云计算服务，这意味着更容易在线查​​找指南和资源。

指令 (Commands)

Most email aliasing/forwarding services provide either a web or mobile application to generate, update, or delete aliases. Building a web application — even a simple one — would require significant effort and resources.

大多数电子邮件别名/转发服务都提供Web或移动应用程序来生成，更新或删除别名。 构建Web应用程序(甚至是简单的Web应用程序)将需要大量的精力和资源。

Since Heimdall is already in the business of sending and receiving emails, I thought: “Why not let commands be issued through email too?”

由于Heimdall已经从事发送和接收电子邮件的业务，因此我想：“为什么也不要通过电子邮件发布命令？”

Command emails are used to generate, list, update, and delete aliases. For instance, if I want to generate a new alias, I’d email generate@mydomain.com. Apart from the whole laziness thing, I thought this is a really cool and convenient way to interact with the service.

命令电子邮件用于生成，列出，更新和删除别名。 例如，如果我想生成一个新的别名，请发送电子邮件至generate@mydomain.com 。 除了整个懒惰之外，我认为这是与服务交互的一种非常酷且便捷的方法。

This alias is actually valid and live! Feel free to say hi, but please don’t spam it.

该别名实际上是有效且有效的！ 随时打个招呼，但请不要向其发送垃圾邮件。

接收邮件 (Receiving emails)

Forwarding emails that are received on aliases to the user’s personal email address is perhaps the most important function. In building this functionality, there were a few considerations at the forefront:

将通过别名收到的电子邮件转发到用户的个人电子邮件地址可能是最重要的功能。 在构建此功能时，首先需要考虑以下几点：

最小，无损的修改 (Minimal, non-destructive modifications)

As much as possible, I want to preserve the information contained in the original email — user-visible or otherwise. For instance, if the email was sent by Acme Corporation to me while cc-ing Alice and Bob, it should arrive in my personal inbox with Alice and Bob still in the cc list. Removing them would be a destructive modification to the original email, because I will have lost some of the email’s original information.

我想尽可能地保留原始电子邮件中包含的信息-用户可见或其他。 例如，如果电子邮件是Acme Corporation在抄送Alice和Bob时发给我的，则它应该到达我的个人收件箱，而Alice和Bob仍在抄送列表中。 删除它们将是对原始电子邮件的破坏性修改，因为我将丢失一些电子邮件的原始信息。

Heimdall should operate as transparently as possible, as if it wasn’t even there.

Heimdall应该尽可能透明地操作，就好像它不在那儿一样。

Here, I used my secondary email address to send an email to the alias I created above, while CC-ing my university email address. As you can see, the CC information is preserved.

在这里，我抄送大学电子邮件地址时，使用了辅助电子邮件地址将电子邮件发送到上面创建的别名。 如您所见，CC信息被保留。

隐形隐私 (Stealthy privacy)

To do the above, all I have to do is to keep Alice and Bob on the cc list when forwarding the email from the alias to my personal email address, right?

为此，我要做的就是在将电子邮件从别名转发到我的个人电子邮件地址时，将Alice和Bob保留在抄送列表中，对吗？

Nope. Doing that means Alice and Bob gets a second copy of the same email. Plus, they would be able to see that the email has been forwarded to my personal email address. So much for privacy.

不。 这样做意味着爱丽丝(Alice)和鲍勃(Bob)将获得同一封电子邮件的第二份副本。 另外，他们将能够看到该电子邮件已转发到我的个人电子邮件地址。 保护隐私非常重要。

Therefore, what I need is to forward the email to my personal email address, keep Alice and Bob on the cc list, but not have them know about it.

因此，我需要将电子邮件转发到我的个人电子邮件地址，将爱丽丝和鲍勃保留在抄送列表中，但不要让他们知道。

This is a surprisingly tricky feature to build, and resulted in a day of diving deep down into a rabbit hole on how email works. I wrote an in-depth technical article about that here. It has to do with the magic that is SMTP envelopes and email headers.

这是一个令人难以置信的棘手功能，导致一天深入研究电子邮件的工作原理。 我在这里写了一篇深入的技术文章 。 它与SMTP信封和电子邮件标题有关。

匿名回复 (Replying anonymously)

For most use cases, being able to receive emails anonymously and reliably is adequate. But for Heimdall to be feature-complete (at least as a minimum viable product), it should also support replying to emails anonymously.

对于大多数用例，能够匿名可靠地接收电子邮件就足够了。 但是，要使Heimdall具备完整的功能(至少作为最低限度的可行产品)，它还应该支持匿名回复电子邮件。

To implement anonymous replies, I had to figure out a way to include information about the original sender (OS)’s email address in the forwarded email. Obviously, replying directly to OS is out of the question (it exposes your personal email address in the “from” header). Associating an alias with an OS is also wrong, because an alias could potentially receive email from multiple senders.

为了实现匿名回复，我必须想出一种方法在转发的电子邮件中包含有关原始发件人(OS)电子邮件地址的信息。 显然， 直接答复操作系统是不可能的(它将您的个人电子邮件地址显示在“发件人”标头中)。 将别名与操作系统相关联也是错误的，因为别名可能会接收来自多个发件人的电子邮件。

What I wanted was a way to easily reply to the original sender while maintaining anonymity.

我想要的是一种在保持匿名的同时轻松回复原始发件人的方法。

Eventually, I opted to include OS’s email address in the email address to which replies will be sent. The easiest way to do this is to set the “from” header in this forwarded email (from alias to personal email) in such a way as to include information about OS’s email. To accomplish that, I’m using this format: alias+originalSenderEmailAddress@mydomain.com.

最终，我选择将操作系统的电子邮件地址包含在要发送答复的电子邮件地址中。 最简单的方法是在此转发的电子邮件中(从别名到个人电子邮件)设置“发件人”标头，使其包含有关操作系统电子邮件的信息。 为此，我使用以下格式： alias+originalSenderEmailAddress@mydomain.com 。

For sanity of parsing, I encoded originalSenderEmailAddress in Base64 representation. This prevents multiple “@” symbols from appearing, such as in alias+marketing@company.com@mydomain.com. This is weird as hell and would probably screw up the email address parsing library that I’m using. Base64’s character set doesn’t include the “@” symbol, nor the “+” symbol, which makes it extremely apt for this purpose — it’s guaranteed that there will only be one “+” separator character and one “@” character.

为了使解析更合理，我以Base64表示形式对originalSenderEmailAddress进行了编码。 这样可以防止出现多个“ @”符号，例如alias+marketing@company.com@mydomain.com符号。 这很奇怪，可能会搞砸我正在使用的电子邮件地址解析库。 Base64的字符集不包含“ @”符号，也不包含“ +”符号，这使其非常适合于此目的-确保只有一个“ +”分隔符和一个“ @”字符。

Therefore, as an example, an email sent from marketing@company.com to alias@mydomain.com will be forwarded to my personal inbox as being from: alias+bWFya2V0aW5nQGNvbXBhbnkuY29t@mydomain.com.

因此，例如，从marketing@company.com发送到alias@mydomain.com的电子邮件将被转发到我的个人收件箱，其发送地址为： alias+bWFya2V0aW5nQGNvbXBhbnkuY29t@mydomain.com 。

You can see this clearly in the screenshot above (the Base64 representation of my secondary email address is contained in the long, blacked-out portion of my alias).

您可以在上面的屏幕截图中清楚地看到这一点(我的辅助电子邮件地址的Base64表示形式包含在我别名的较长的涂黑部分中)。

Finally, when Heimdall receives this email (and detects it as originating from my personal email address), it parses the email address to obtain alias and marketing@company.com (after decoding). It repackages the email as being sent from alias@mydomain.com to marketing@company.com, while preserving the email subject and body.

最后，当Heimdall收到这封电子邮件(并将其检测为来自我的个人电子邮件地址)时，它将解析该电子邮件地址以获得alias和marketing@company.com (在解码后)。 它将电子邮件重新包装为从alias@mydomain.com发送到marketing@company.com ，同时保留电子邮件主题和正文。

测验 (Tests)

So far, I’ve described an intricate system of multiple logical components working together. Considering that email is a critical service — in many circumstances, it is the primary channel of communication — I need to be 100% sure that my implementation works correctly.

到目前为止，我已经描述了一个由多个逻辑组件协同工作的复杂系统。 考虑到电子邮件是一项至关重要的服务-在许多情况下，它是沟通的主要渠道-我需要100％确保自己的实施能够正常运行。

I built Heimdall with reliability as my utmost priority. In this case, reliability refers to the fact that new features or bug fixes do not accidentally break something else. (Since the service is run on AWS, I have no control over infrastructure reliability.)

我将可靠性作为Heimdall的首要任务。 在这种情况下，可靠性是指以下事实：新功能或错误修复不会意外破坏其他功能。 (由于该服务在AWS上运行，因此我无法控制基础架构的可靠性。)

In the early stages of development, I set up continuous integration on Travis CI and integrated Code Climate to track code quality and test coverage. Almost all business-logic modules are 100% unit-tested, and many are integration-tested as well. With a comprehensive set of tests covering almost every aspect of functionality, I can be relatively confident in deploying new builds (although there is no such thing as perfect code!)

在开发的早期阶段，我在Travis CI上进行了持续集成，并集成了Code Climate，以跟踪代码质量和测试覆盖范围。 几乎所有业务逻辑模块都经过100％单元测试，并且许多模块也都经过了集成测试。 通过涵盖几乎所有功能方面的全面测试，我可以相对自信地部署新版本(尽管没有完美的代码！)

判决 (Verdict)

This has been a 10/10 experience with a ton of learning, trial-and-error, and now a working MVP that I’m using on a daily basis (yay dogfooding!).

这是10/10的经验，有大量的学习，反复试验，现在我每天都在使用MVP(可以吃狗肉！)。

Time taken: Approximately 1 week to build the core features, and 0.5 weeks for refinement and preparation for release.

花费的时间：构建核心功能大约需要1周，而完善和发布准备则需要0.5周。

In case you missed out the link to the project at the start of the post, you can check out Heimdall here.

如果您在帖子开头错过了该项目的链接，可以在此处查看Heimdall 。