Mailing Lists, SPAM, DKIM and other unpleasant realities

Standards groups frequently use mailing lists to contribute, for example to discuss security standards such as DKIM, DNSSEC, OAuth, OpenID, etc.  Unfortunately those mailing lists are encountering a growing problem which is that REAL posts by members to the lists are being FALSELY marked as SPAM when received by others on the list.

Currently there are very few mailing list products/services that support the newest standards needed to avoid this problem.
  • Google Groups
  • mailman (open source contributions are being worked on, but are not yet available and probably will not for a few months)
  • Yahoo mail (in progress, but not yet finished)
  • ...if you know of others, contact esachs AT google.com
The cause is one of those unfortunate situations where security is being improved in one area, but having some unfortunate side effects.  The area where security is being improved is in phishing/spam.  New techniques like DKIM and SPF are being used to more accurately verify the source of a message.  For example, when a webmail service like Gmail receives a message that claims to be from Paypal, but it does not have the proper DKIM/SPM information, then it is generally marked as a phishing or spam message.  This article gives an example:
Unfortunately if a REAL message with proper DKIM/SPF information is sent to a mailing list that remails it to the subscribers, then that DKIM/SPF information is lost.  The mailing service the receives the message then incorrectly thinks it is a phishing or spam message.

Since 2009 there has been growing use of DKIM/SPF:
  • by web-services like Gmail/YahooMail/Hotmail for sending mail
  • by spam/phishing filters services/products like Postini
  • by enterprises like Paypal/Google/Facebook/etc. for sending mail, especially to reduce impersonation of their employees
As this usage has grown, so has the unfortunate side effect on mailing lists, especially those that work on Internet standards.  To reduce this problem, a standard has been proposed called x-original-authentication-results which can be used by mailing lists to pass through some DKIM/SPM information.  Below is a copy of one draft of the standard.  At the top of this article is a list of the mailing list products/services that support this standard.

If you work with a mailing list that is impacted by this problem, we suggest you circulate this information to the members of that list, as long as your message on the topic does not get marked as SPAM :-(  The community that uses the mailing lists should consider migrating the mailing list to a product/service that supports this standard.  If the community includes many employees of companies who use DKIM/SPF then their contributions will be the most negatively impacted.  So sadly the companies who are most focused on being good citizens in terms of security are in the near term going to have the most problems contributing to standard development on mailing lists, including for development of other security standards.

X-Original-Authentication-Results for preserving authentication results across trusted forwarders

Introduction

Mail forwarders break DKIM authentication when they modify the body of the message.  Sometimes this breakage is expected and benign, such as when a mailing list adds an unsubscribe footer.  If the original DKIM signature is broken, it cannot be used to verify the original author of the message.  Mail forwarders can preserve results of the original DKIM verification through a new X-Original-Authentication-Results header.  The intent of this header is to convey the results of authentication checks on the original message to the user.  This memo defines the format of this new header field and discusses the implications of its presence or absence.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Definition and format of the field

X-Original-Authentication-Results takes its format and definition from Authentication-results, except the field is called X-Original-Authentication-Results.  There MUST be no more than one such field in any given message.

Example:

X-Original-Authentication-Results: mr.google.com; spf=pass (google.com: domain of foo@example.com designates 10.140.187.8 as permitted sender) smtp.mail=foo@example.com; dkim=pass header.i=foo@example.com

Definition of trusted forwarder

The X-Original-Authentication-Results header is only useful if the forwarder is trusted.  The forwarder is free to modify the headers and body of the message however it wishes and can generate new signatures over arbitrary X-Original-Authentication-Results headers.  Thus, the user SHOULD only trust X-Original-Authentication-Results if the message was delivered by known good forwarders, and forwarders SHOULD NOT propagate X-Original-Authentication-Results unless the previous forwarder is known to be good.

For the purposes of this memo, a message was delivered through trusted forwarder if:
  • The DKIM signature passes
  • The DKIM domain is a trusted forwarder

Adding the new header field to a message

When an MTA receives a message without X-Original-Authentication-Results, it performs authentication checks as in RFC 5451 and puts the results in the new header.  It MUST generate a DKIM signature including the new header.

Removing the new header field from a message

When an MTA receives a message with X-Original-Authentication-Results, it performs authentication checks as in RFC 5451.  If any of the following conditions is met, the forwarder MUST strip X-Original-Authentication-Results from the message:
  • DKIM verification fails or the DKIM signature is absent
  • The DKIM signature does not include X-Original-Authentication-Results
  • The DKIM domain is not a trusted forwarder

Keeping the new header field in a message

When an MTA receives a message with X-Original-Authentication-Results, it performs authentication checks as in RFC 5451.  If all of the following conditions are met, the MTA MUST generate a new DKIM signature including the X-Original-Authentication-Results header:
  • DKIM verification passes
  • The DKIM signature includes X-Original-Authentication-Results
  • The DKIM domain is a trusted forwarder

Security considerations

A malicious sender could generate a message with X-Original-Authentication-Results (purporting that the original message authenticates from example.com) and a valid signature with DKIM domain evil.com.  The recipient must decide whether or not to trust evil.com.

Trust is transitive.  If a message traverses multiple mailing lists, the final recipients must trust all intermediate mailing lists to take advantage of the new header.  Further, there is no specification for determining how many or which mailing lists the message passed through before delivery.

Examples

Header absent

Received: from mail-router.example.com (mail-router.example.com [192.0.2.1])
by server.example.org (8.11.6/8.11.6)
with ESMTP id g1G0r1kA003489;
Fri, Feb 15 2002 17:19:07 -0800
From: sender@example.com
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.org
Message-Id: <12345.abc@example.com>
Subject: here's a sample

Hello! Goodbye!

The header is absent.  The MUA makes no assumption about the origin or validity of the message.

Header present but DKIM signature broken, not present, or does not include X-Original-Authentication-Results

Authentication-Results: mx.google.com; spf=neutral (google.com: 98.136.44.50 is neither permitted nor denied by domain of noreply@foo.net)
smtp.mail=noreply@foo.net; dkim=hardfail (test mode) header.From=noreply@foo.net
Received: from dialup-1-2-3-4.example.net (dialup-1-2-3-4.example.net [192.0.2.200]) by mail-router.example.com (8.11.6/8.11.6) with ESMTP id g1G0r1kA003489;
X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: 98.136.44.50 is permitted by domain of sender@example.netdkim=pass header.i=sender@example.net

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
t=1241199942; bh=QEhHJ/j5vfrx5vc41XbkI/JJltY=;
h=DomainKey-Signature:X-Sender:X-Apparently-To:Received-SPF:
Authentication-Results:Mime-Version:Content-Type:From:Date:
Message-ID:Subject:To:X-System-Of-Record:Sender:Precedence:
X-Google-Loop:Mailing-List:List-Id:List-Post:List-Help:
List-Unsubscribe:X-BeenThere-Env:X-BeenThere; b=Z5vM83n7lJLDjq0IF5
HymgX20/5J7B0GSEhdZUBSBrnJfl+iQ15aUK6AlekI58Tv6Jyv+kblZhI02z1SyWql2
A==
Fri, Feb 15 2002 17:19:07 -0800
From: sender@example.net
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.com
Message-Id: <12345.abc@example.net>
List-Id: <list@foo.net>
Subject: here's a sample

Hello! Goodbye!

The header is present, but the MUA cannot assume that sender@example.net is the original author of the message.

Header present, DKIM signature passes

Authentication-Results: mx.google.com; spf=pass (google.com: 98.136.44.50 is  permitted by domain of noreply@foo.net)
smtp.mail=noreply@foo.net; dkim=pass (test mode) header.From=noreply@foo.net

Received: from dialup-1-2-3-4.example.net (dialup-1-2-3-4.example.net [192.0.2.200]) by mail-router.example.com (8.11.6/8.11.6) with ESMTP id g1G0r1kA003489;
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta;
t=1241199942; bh=QEhHJ/j5vfrx5vc41XbkI/JJltY=;
h=DomainKey-Signature:X-Sender:X-Apparently-To:Received-SPF:
Authentication-Results:Mime-Version:Content-Type:From:Date:
Message-ID:Subject:To:X-System-Of-Record:Sender:Precedence:
X-Google-Loop:Mailing-List:List-Id:List-Post:List-Help:
List-Unsubscribe:X-BeenThere-Env:X-BeenThere:X-Original-Authentication-Results; b=Z5vM83n7lJLDjq0IF5
HymgX20/5J7B0GSEhdZUBSBrnJfl+iQ15aUK6AlekI58Tv6Jyv+kblZhI02z1SyWql2
A==
X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: 98.136.44.50 is permitted by domain of sender@example.netdkim=pass header.i=sender@example.net
Fri, Feb 15 2002 17:19:07 -0800
From: sender@example.net
Date: Fri, Feb 15 2002 16:54:30 -0800
To: receiver@example.com
Message-Id: <12345.abc@example.net>
List-Id: <list@foo.net>
Subject: here's a sample

Hello! Goodbye!


The header is present, and the message authenticates from a trusted forwarder foo.net.  The MUA can assume that the original sender of the message is sender@example.net.
Comments