我正在开发一个网站，我希望通过匿名化电子邮件地址来保护买家。与 craigslist 的系统类似，当卖家需要联系买家时，他们应该能够向匿名地址发送电子邮件，例如 [电子邮件受保护] 随后将被路由到用户的电子邮件地址。
我现在的计划是：
- 设置一个存储桶（包罗万象）收件箱
- 为每个买家生成一个随机密钥，该密钥将是电子邮件地址的用户特定部分（上面的“1425415125”）
- 监视存储桶收件箱并解析出该用户具体部分。一旦我认识了用户，电子邮件就可以转发到正确的地址
我的问题如下：
- 您能看到上述解决方案的任何问题
- 吗？是否有针对现有问题的开源解决方案？
- 是否有任何应该注意的问题什么时候开发这样的系统？
预先感谢
JP
I am developing a site for which I would like to protect buyers by anonymizing their email addresses.Similar to craigslist's system, when a seller needs to contact a buyer they should be able to send an email to an anonymized address such as [email protected] which will then be routed to the user's email address.
My plan right now is to:
- Set up a bucket (catch-all) inbox
- Generate a random key for each buyer which will be the user specific ('1425415125' above) section of the email address
- Monitor the bucket inbox and parse out this user specific section. Once I know the user, the email can be forwarded to the correct address
My questions are as follows:
- Can you see any issues with the above solution
- Are there any open source solutions to the existing problem
- Are there any gotchas that one should be aware of when developing such a system?
Thanks in advance
JP
发布评论
评论（6）
我做了一些相关的事情，尽管不完全相同。我在现有的 pop3 服务器上设置了一个包罗万象的收件箱（我猜你可能已经有了一个）。然后，我使用 OpenPop.NET 在计时器上读取所有新消息（例如每 30 秒）。在我的例子中，我只是停止处理消息，但是很容易生成一条新消息到适当的地址并复制正文，然后将新消息发送到您的 SMTP 服务器上。
我在您的设置中看到的一个问题（也许这只是我的一个误解）是，当您保护用户的原始电子邮件地址时，他们将继续通过 [电子邮件受保护] 基本上永远。如果我了解 craigslist 的工作方式，每个帖子都有不同的电子邮件地址，一旦帖子被删除/删除（或不久后），电子邮件地址就会停止工作。这样人们就不能一直通过该电子邮件地址骚扰您。这个问题的解决方案很简单，只需让电子邮件地址与帖子 ID 或其他某个 ID 对应，而不是与数据库中的用户 ID 对应即可。查找速度同样快，但每次都会有一个新的电子邮件地址。
I did something related, though not quite the same. I setup a catch all inbox on my existing pop3 server (you probably have one already I'm guessing). I then used OpenPop.NET to read all new messages on a timer (say every 30 seconds). In my case I stopped at just processing the messagse but it's easy enough to generate a new message to the appropriate address and copy the body over, then send the new message out on your SMTP server.
One problem I see with your setup, and maybe it's just a misunderstanding on my part, is that while you are protecting the users original email address they will continue to be reachable at [email protected] basically forever. If I understand the way craigslist works, each posting has a different email address, and once the posting has been deleted/removed (or shortly after) the email address stops working. This makes it so that people can't just keep bugging you on that email address. The solution to this issue is easy, just make the email address coorespond to a post id or some other id rather then the users id in the database. The lookup will be just as quick but they will have a new email address each time.
您可能希望查看邮件“管道” - 某人将电子邮件发送到邮件服务器的能力，然后该服务器立即将其抛出到可执行文件，然后该可执行文件将您的邮件转发给收件人（通过从邮件服务器中提取真实的电子邮件地址）基于管道消息的传入地址的数据库）。
我个人的建议是查看 HMailServer，它有一个 COM API（管理端是用 PHP 编写的，因此需要遗留互操作），是免费和开源的，并且有很好的文档记录。它没有内置的邮件管道，但考虑到 API 和对在 服务器端消息事件
HTH，
Benjamin
You may wish to look at mail "piping" - the ability for someone to send an email to a mail server, which then gets thrown immediately to an executable, which then forwards your mail onto the recipient (by pulling the real email address from the database based on the incoming address from the piped message).
My personal recommendation would be to check out HMailServer, which has a COM API (the admin side is written in PHP, hence the requirement for legacy interop), is free and open-source, and is very well-documented. It doesn't have mail piping built-in, but is easily extensible given the API and support for scripts which run on server-side message events
HTH,
Benjamin
我认为这个解决方案是有意义的，并且在很多情况下都在使用。最困难的部分实际上是接收消息。如果需要，您实际上可以在网络应用程序中处理所有这些。我写了一篇博文，重点介绍了在您的网络应用程序中接收电子邮件。它主要适用于 Rails，但概念应该是可以转移的。
I think this solution will make sense and is in use in a lot of cases. The hardest part is actually receiving the messages. You can actually handle all of this within your web app if you need to. I wrote a blog post highlighting a couple of ways to receive email in your web app. It applies mainly to Rails but the concepts should be transferable.
您希望这样做的方式就是我创建类似服务的方式。我不建议您编写自己的 smtp 服务器。使用现有的邮件服务器并仅使用轮询或某些基于事件的 API。
使用第三方邮件服务器的好处是您可以在其上使用现有的备份和管理工具。
编辑：我刚刚注意到这个问题已经在这里得到了更好的解释。 将传入电子邮件传送到 Windows IIS SMTP 上的脚本？< /a>
The way you are lookimg to do it is the way I created a similar service. I would not recommend you writing your own smtp server. Use an existing mailserver and just use polling or some event based api.
The benefits of using a 3rd party mailserver is you can use existing backup and management tools on it.
Edit: I just noticed this has beed answered here with a better explanation. Pipe incoming email to a script on Windows IIS SMTP?
我没有看到您的设置有任何问题，事实上，这是正确的方法，因为如果您预定的申请失败，电子邮件仍将位于全部电子邮件箱中。只有当电子邮件成功发送给某人后，才应删除该电子邮件。您将能够监视和记录您自己的应用程序的活动，以监视进度和故障。
我不推荐管道，因为如果出于任何原因管道成功但您的 exe 崩溃，您将丢失电子邮件。追踪将会很困难。安排工作是不可能的。
如果您的应用程序独立于邮件服务器，则很容易管理它并尽可能更换您的邮件服务器。很容易扩展。
在这种情况下，您将必须使用一些流行阅读器库，并安排您的应用程序频繁运行。
I do not see any problem with your setup, infact that is correct way to do because if your scheduled application fails, the emails will still be in the catch-all email box. Only once the email has been successfully delivered to somebody, the email should be deleted. You will be able to monitor and log the activity of your own application to monitor progress and failures.
I do not recommend Piping because, if for any reason piping goes successfully but your exe crashes, you will loose the email. Tracking will be difficult. Scheduling the jobs will not be possible.
If your application is independent of mail server, it is easy to manage it and replace your mail server whenever possible. It is easy to extend.
In this you will have to use some pop reader library, and schedule your application to run frequently.
除了电子邮件之外，您还可以考虑拉式而非推送式交付机制，例如：消息中心 Web 前端或 RSS 提要。我这样说是因为各种 ISP 的传送能力问题可能很难解决，而且根据我的经验，您的用户永远不会相信这是他们的 ISP。
In addition to email, you may consider a pull rather than push delivery mechanism, e.g: a message center web frontend or RSS feed. I say this because deliverability problems to various ISPs can be very difficult to troubleshoot and in my experience your users will never believe it's their ISP.