C#中类似Craigslist的电子邮件匿名化

9
我正在开发一个网站,希望通过匿名化买家的电子邮件地址来保护他们。类似于Craigslist的系统,当卖家需要联系买家时,他们应该能够发送电子邮件到一个匿名地址,例如1425415125@mysite.com,然后将被路由到用户的电子邮件地址。
我的计划是:
1. 设置一个桶(catch-all)收件箱 2. 为每个买家生成一个随机密钥,这将是电子邮件地址中特定于用户的部分(如上所示的“1425415125”) 3. 监视桶收件箱并解析出此特定于用户的部分。一旦我知道了用户,电子邮件就可以转发到正确的地址。
我的问题如下:
1. 您是否看到上述解决方案存在任何问题? 2. 是否有现有问题的开源解决方案? 3. 在开发这样的系统时,有什么需要注意的地方吗?
谢谢。

尽管下面的两个答案都很有见地,但我发起了一个奖励计划,以查看我能找到什么额外的信息 - 特别是与C#具体解决方案有关的信息。 - JP.
2
虽然这个问题没有给我带来任何赏金,但我认为这个问题在SO上已经被解决了。链接 - Sumo
6个回答

6

虽然不完全相同,但我做了相关的事情。 我在现有的pop3服务器上设置了一个通用收件箱(我猜你可能已经有一个)。 然后,我使用OpenPop.NET定时读取所有新邮件(例如每30秒读取一次)。 在我的情况下,我只停留在处理消息上,但很容易生成一个新消息到适当的地址并复制正文,然后在您的SMTP服务器上发送新消息。

我看到您的设置中存在一个问题,也许这只是我的误解,即尽管您保护了用户的原始电子邮件地址,但他们将继续在1425415125@mysite.com上保持可达性。 基本上永远都是如此。 如果我理解craigslist的工作方式,每个帖子都有一个不同的电子邮件地址,并且在删除/移除帖子(或之后不久)后,电子邮件地址就会停止工作。 这使得人们不能在该电子邮件地址上继续骚扰您。 解决此问题的方法很简单,只需使电子邮件地址与帖子ID或其他ID对应,而不是与数据库中的用户ID对应。 查找将同样快速,但每次都会有一个新的电子邮件地址。


在保护电子邮件地址方面 - 匿名化的电子邮件地址将定期刷新,例如,一天内 1244@mysite.com 将是有效的,稍后该电子邮件地址将不再指向任何人,而是同一用户可通过 9qwdas@mysite.com 联系。 - JP.
1
这很混乱..如果买家和卖家通过电子邮件进行沟通,那么买家将无法再联系到卖家。我同意@Patricker的观点,即Id应该与发布Id相关联。 - Variant
@Variant,有一些关键的业务特定问题你不了解。对于我的目的来说,这正是我想要的行为。 - JP.

1

您可能希望查看邮件“管道” - 这是某人向邮件服务器发送电子邮件的能力,然后立即将其投递到可执行文件,然后根据管道消息中的传入地址从数据库中提取真实电子邮件地址,并将您的邮件转发给收件人。

我个人的建议是查看HMailServer,它具有COM API(管理端以PHP编写,因此需要遗留Interop),是免费和开源的,并且文档非常齐全。它没有内置邮件管道,但是在API和支持运行在服务器端消息事件上的脚本方面易于扩展。

希望对您有所帮助,

本杰明


1

我认为这个解决方案很有道理,并且在很多情况下都在使用。最难的部分实际上是接收消息。如果需要,您可以在Web应用程序中处理所有这些内容。我写了一篇博客文章,介绍了在Web应用程序中接收电子邮件的几种方式。它主要适用于Rails,但概念应该是可转移的。


他们是竞争对手,但是Mailgun也许可以解决这个问题。它们允许你接收邮件到一个中央邮箱并解析出你需要的任何内容。 - JonLim

0
你想要做的方法是我创建类似服务时采用的方法。我不建议你编写自己的SMTP服务器,使用现有的邮件服务器并使用轮询或某些基于事件的API即可。
使用第三方邮件服务器的好处是可以在其上使用现有的备份和管理工具。
编辑:我刚注意到这里已经有更好的解释回答了这个问题。 将传入的电子邮件管道连接到Windows IIS SMTP上的脚本?

0

我认为你的设置没有问题,事实上这是正确的做法,因为如果你的定时应用程序失败了,邮件仍然会在全能邮箱中。只有当电子邮件成功发送给某人后,才应该将其删除。您将能够监视和记录自己的应用程序的活动以监视进度和故障。

我不建议使用管道,因为如果出现任何原因导致管道成功但您的exe崩溃,您将失去该电子邮件。跟踪将很困难。无法安排作业。

如果您的应用程序独立于邮件服务器,则可以轻松管理它并在可能的情况下更换邮件服务器。易于扩展。

在此过程中,您将需要使用一些POP读取器库,并定期安排应用程序运行。


0
除了电子邮件,您可以考虑使用拉取而不是推送的传递机制,例如:消息中心 Web 前端或 RSS 订阅源。我之所以这么说,是因为向各个 ISP 交付可能会出现很难故障排除的问题,并且在我的经验中,用户永远不会相信这是他们的 ISP 的问题。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接