好主意？拒绝以我们自己的域名结尾的传入电子邮件？（因为它们必须是假的）

33

我对我们的Exchange Server有一个疑问：您认为拒绝以域名结尾的外部电子邮件是一个好主意吗？

喜欢来自的外部电子邮件fake@example.com吗？

因为如果是来自我们公司的真实发件人，电子邮件将永远不会来自外部？

如果是，执行此操作的最佳方法是什么？

security email-server exchange-2013

— 斯蒂芬·迈尔
source

3

您现在有任何垃圾邮件过滤解决方案吗？

— ewwhite '16

14

您应该仔细检查一下，确认没有任何Web应用程序的供应商试图从您自己的域发送邮件。就像您有一个薪资系统一样，该系统可能会从“ payroll@example.com”向您的员工发送电子邮件。还要检查市场营销或人力资源部门是否可能使用外部批量邮件服务，并且希望员工获取这些邮件。通常，这些消息具有营销或HR中某人的发件人或至少答复地址。在这种情况下，您通常可以将服务的电子邮件服务器放在允许列表上，并且仍然阻止您自己的域传入（这就是我们要做的）。

— Todd Wilcox

6

@NeilMcGuigan那有什么关系？邮件仍然应该来自内部邮件服务器吗？它不会仅仅因为他不在场而来自网络外部。

— 马特

@Matt Gotya，brainfart

— Neil McGuigan

1

如果您有来自一台服务器的自动电子邮件通知，例如，失败的cron作业通知，或尝试违反IDS或资源使用情况监视器，则将它们配置为使用您的域名作为发件人地址。您需要注意通过内部邮件服务器路由这些电子邮件，或将这些服务器列入许可发件人的白名单。

— Lie Ryan

53

是的，如果您知道该域的电子邮件仅应来自您自己的服务器，则应阻止该域的电子邮件来自其他服务器。即使发件人的电子邮件客户端在另一台主机上，他们也应该登录到您的服务器（或您使用的任何电子邮件服务器）中以发送电子邮件。

更进一步，您可以配置服务器以检查SPF记录。这就是有多少主机阻止此类电子邮件活动。SPF记录是DNS记录，TXT记录，它提供了有关允许哪些服务器为您的域发送电子邮件的规则。如何启用SPF记录检查将取决于您的电子邮件服务，并且不在本文讨论范围之内。幸运的是，大多数托管环境和软件都具有用于处理SPF记录的文档。通常，您可能想了解有关SPF的更多信息。这是Wikipedia的文章：https : //en.wikipedia.org/wiki/Sender_Policy_Framework

— DKing
source

3

@Kurtovic，配置良好的电子邮件服务器应退回被拒绝的电子邮件，以便通知发件人。

— Calimo '16

8

@Calimo在拒绝电子邮件为垃圾邮件时不会。这样做只会使垃圾邮件发送者继续尝试，直到他知道您的算法允许和不允许的内容为止。

— 乔恩·本特利

27

@Calimo-不接受并跳出是最糟糕的事情，您正在为垃圾邮件的反向传播做出贡献，并且很快就会被列入黑名单。只是拒绝不需要的邮件-处理发送主机的问题。如果您不能这样做，则接受，检查并丢弃垃圾邮件或恶意软件。永远不要接受并反弹。

— cas

2

@cas：还有第三种选择：在SMTP接受时拒绝。如果这样做，这将使在发送SMTP服务器上产生错误响应的负担加倍，从而使许多合法的发件人可以查看他们的邮件是否被拒绝，同时保证您自己不会产生垃圾邮件。

— R ..

2

@R ..我想您会发现这不是第三种选择，它是我所说的“只是拒绝不需要的邮件-处理发送主机的问题”的表述。

— cas

31

已经有执行此操作的标准。它称为DMARC。您可以使用DKIM签名来实现它（无论如何还是一个好主意）。

较高级别的概述是，您对离开域的每一封电子邮件都使用DKIM标头进行签名（无论如何，这都是一种好习惯）。然后，您将DMARC配置为拒绝来自您拥有的域的，未使用有效DKIM标头签名的所有命中邮件服务器的电子邮件。

这意味着您仍然可以让外部服务将电子邮件发送到您的域（例如托管的服务台软件等），但是可以阻止鱼叉式网络钓鱼。

DMARC的另一个优点是您可以获得故障报告，因此您可以根据需要管理异常处理。

不利的一面是，您需要确保事先对所有内容进行了彻底的整理，否则您可能会开始丢弃合法的电子邮件。

— 马克·亨德森
source

3

强烈建议在测试DMARC之前实施SPF和DKIM。

— Todd Wilcox

DMARC如何处理来自与您自己不同的服务器的电子邮件，例如外部服务，因为这些电子邮件不会由您的服务器签名？

— jpaugh

1

@jpaugh，您将其他服务器的公钥添加到DNS中的DMARC记录中。他们将能够为您添加记录。

— 马克·亨德森

我对该问题+1了，因为它在技术上是正确的-正是DMARC的用途以及它的作用-但如果您想与邮件列表之类的内容进行互操作，则DMARC是一个非常糟糕的主意，因为它违反了RFC和通常行为不端。

— MadHatter支持Monica

11

这样的阻止可能会减少垃圾邮件，并可能使社会工程学变得更加困难，但也可能阻止合法邮件。示例包括邮件转发服务，邮件列表，具有错误配置的邮件客户端的用户，直接从Web主机直接发送邮件而不涉及您的主邮件服务器的Web应用程序等等。

Dkim可以通过提供一种方法来识别从网络发送的消息，通过邮件列表或转发器循环并随后在您的邮件中接收到的消息，从而在某种程度上缓解这种情况，但这并不是完美的解决方法，某些邮件列表会破坏dkim签名而且仍然存在跟踪所有合法邮件始发点并确保它们通过dkim签名者的问题。

小心踩踏，尤其是在现有域上实施时。

— 彼得·格林
source

3

也许可以，但是在进行这种更改之前，您需要考虑一些情况。

1）您公司中的任何人是否使用任何类型的外部服务（例如Survey Monkey，Constant Contact等）来发送似乎是“来自”您域的电子邮件？即使他们今天不这样做，将来也可以吗？

2）是否有外部地址转发给您的用户？例如，假设gmail帐户“ mycompany.sales@gmail.com”转发到“ sales@mycompany.com”，而您的用户“ bob@mycompany.com”发送到“ mycompany.sales@gmail.com”。在这种情况下，消息将从“外部”到达，但带有“ @ mycompany.com”发件人：地址。

3）您的任何用户是否订阅了外部通讯组列表，这些通讯组在发送到该列表的邮件上保留了原始的“发件人：”地址？例如，如果Bob订阅了“ foo-list@lists.apple.com”并发送一条消息，他将收到一条入站消息，看起来像是：发件人：bob@mycompany.com到：foo-list@lists.apple。发件人：

如果您的服务器天真地查看“发件人：”标头（而不是“发件人：”），则它可能会拒绝此消息，因为您是从外部收到的。

由于上述所有原因，总括政策“ ...来自我们公司的真实发件人，电子邮件永远不会来自外部”并不总是可行的。

— 大卫·盖尔哈
source

2

您可以在PowerShell中通过更新接收连接器权限来执行此操作，以排除匿名用户作为权威域发件人发送：

Get-ReceiveConnector <identity> | Remove-AdPermission -User "NT AUTHORITY\Anonymous Logon" -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-DomainSender

但是，当您有需要向您发送状态电子邮件的远程应用程序服务器时，就会出现问题，因为这些服务器通常在其发件人地址中使用您的域名。可以为它们的特定IP地址创建一个附加的接收连接器，这样您就不会无意间将它们排除在外。

— 尼尔
source

1

GMail的设置允许您使用非GMail域发送电子邮件，前提是该电子邮件地址是经过首次验证的。您的决定将阻止这些电子邮件。

您是否有可能使用此GMail功能的用户以及迎合他们的需求在很大程度上取决于公司内部的行为。

— 基督教
source

-1

SPF不会解决此问题，因为信封很可能具有适当的SPF通行证（即，使用受感染服务器的垃圾邮件发送者），同时他们会在信封内伪造电子邮件。您需要的是您自己的域电子邮件中的一个阻止，该阻止在信封上具有您不可接受的原始电子邮件服务器。

— 吉姆
source

“您需要的是您自己的域电子邮件中的一个阻止，在信封上有一个您不可接受的原始电子邮件服务器” -这正是您使用SPF所要做的，为您的域创建合法的原始电子邮件服务器列表。

— GAThrawn