附带垃圾邮件更难用目前描述的技术阻止，因为它通常来自使用标准邮件传输软件（如 Sendmail、Postfix 或 Exim）的合法站点。 挑战在于区分这些消息与有效的投递状态通知，后者是响应于从您自己的用户发送的邮件而返回的。 以下是一些人们执行此操作的方法
大多数时候，附带垃圾邮件是由防病毒扫描程序生成的病毒警告[1]。 反过来，主题这些病毒警告的行和/或其他特征通常由防病毒软件本身提供。 因此，您可以创建更常见特征的列表，并过滤掉此类虚假病毒警告。
好吧，您不是很幸运吗 - 已经有人为您做了这件事。 :-)
Tim Jackson<tim (at) timj.co.uk>维护着一个用于 SpamAssassin 的虚假病毒警告列表。 此列表可在以下网址获得：http://www.timj.co.uk/linux/bogus-virus-warnings.cf。
发件人策略框架的目的正是为了防止 乔布斯；即防止伪造有效的电子邮件地址。
如果您在域的 DNS 区域中发布 SPF 记录，那么包含 SPF 检查的接收主机将不会首先接受伪造的消息。 因此，他们不会向您的站点发送投递状态通知。
我目前正在试验的另一种方法是在外发邮件的信封发件人地址的本地部分添加签名，然后在接受传入的投递状态通知之前，检查信封收件人地址中是否包含此签名。 例如，生成的发件人地址可能采用以下格式
localpart=signature@domain |
普通邮件回复不受影响。 这些回复将发送到发件人或回复至消息的字段，这些字段保持不变。
听起来很容易，不是吗？ 遗憾的是，生成适合此目的的签名比听起来要复杂一些。 需要考虑几个相互冲突的因素
为了从此方法中获得任何好处，您生成的签名信封发件人地址对于垃圾邮件发送者来说应该是无用的。 通常，这意味着签名应包含最终会过期的时间戳
sender=timestamp=hash@domain |
如果您向包含灰名单的站点发送邮件，您的信封发件人地址对于该特定收件人应保持不变。 否则，您的邮件将持续被灰名单。
sender=recipient=recipient.domain=hash@domain |
邮件列表服务器还会出现另外两个问题。 通常，对请求邮件（如“订阅”/“取消订阅”）的回复在发送时没有信封发件人。
第一个问题与将响应发送回请求邮件的信封发件人地址的服务器有关（如<discuss@en.tldp.org>的情况）。 问题在于邮件列表服务器的命令（如 subscribe 或 unsubscribe）通常发送到一个或多个不同的地址（例如<discuss-subscribe@en.tldp.org>和<discuss-unsubscribe@en.tldp.org>，分别）而不是用于列表邮件的地址。 因此，订阅者地址将与发送到列表本身的消息中的发件人地址不同 - 在此示例中，也与为取消订阅请求生成的地址不同。 因此，您可能无法发布到列表或取消订阅。
折衷方案是仅将收件人域合并到发件人签名中。 发件人地址可能看起来像
subscribername=en.tldp.org=hash@subscriber.domain |
第二个问题与那些将响应发送回请求邮件的消息标头中的回复地址的服务器有关（如<spam-l-request@peach.ease.lsoft.com>）。 由于此地址未签名，因此来自列表服务器的响应将被您的服务器阻止。
对此您无能为力，只能“白名单”这些特定服务器，以便允许它们将邮件返回到未签名的收件人地址。
此时，这种方法开始失去一些优势。 此外，即使是合法的 DSN 也会被拒绝，除非原始邮件是通过您的服务器发送的。 因此，如果您的用户不漫游，或者通过您控制之外的服务器发送他们的外发邮件，您才应考虑这样做。
也就是说，在上述所有问题都不适用于您的情况下，此方法为您提供了一种很好的方法，不仅可以消除附带垃圾邮件，还可以教育（可能是无意中）生成它的站点所有者。 此外，作为一项额外的好处，执行发件人回呼验证的站点只有在原始邮件确实是从您的站点发送的情况下才会从您那里获得肯定的响应。 本质上，您正在减少垃圾邮件发送者伪造发件人地址的风险。
您可以允许您的用户指定是否对发出的邮件进行签名，如果是，则指定应允许哪些主机将邮件返回到其地址的未签名版本。 例如，如果他们在您的邮件服务器上拥有系统帐户，您可以检查其主目录中给定文件的存在和内容。
| [1] | 防病毒软件的作者为什么如此愚蠢，以至于信任包含病毒的电子邮件中的发件人地址，这也许是一个值得更深入的精神分析研究的主题。 |