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:
https://mail.google.com/support/bin/answer.py?answer=185812
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.
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.
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
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
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.
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
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
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
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.
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.net) dkim=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.
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.net) dkim=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.