At 05:23 PM 11/11/2006 +0000, Julian wrote:
David MacQuigg wrote:
> It seems to me we should follow a simple
> rule - prepend every new header in exactly the order it is generated.
> If the SPF check is done before the body of the message is received, it
> ought to go just below the Received: header.
You seem to assume that the usual "Received:" header is generated only
after the body has been received. There is, however, not a single RFC out
there mandating that. There is no defined point in time when the
"Received:" header must be generated.
My assumption is based on the fact that "Received" is past tense. I would
guess a lot of people make this same assumption.
It certainly can't be any earlier than RCTP TO:, because recipient
information is included in Received: headers. I guess we could check the
timestamp for a few MTAs.
Thus it would be most logical to always generate the "Received:" header
first, before any other trace headers.
Only if you make an assumption contrary to the past-tense of the word
"Received". I would guess this assumption is also not supported in the RFCs.
Again, I will follow the standards, and as Frank pointed out, the SHOULD in
RFC 4408 should determine the placement of Received-SPF. My concern is
what to do with a new header, one that includes authentication and
reputation information, not just SPF results.
The "Received:" header is a well-
known, trusted concept understood by many e-mail header parsers, and thus
it is the best authority for a message's transport path for the purpose of
message parsers such as SpamAssassin. All other headers should be added
above of it so that parsers can be certain that they belong to the same
hop as the trusted "Received:" header.
This might be the most compelling argument. If in fact SpamAssassin and
other such programs have already "wired in" an expectation that a Received:
header marks the boundary, then that is more important than keeping things
simple by maintaining strict chronological order. I would like to learn
more about what programs make this assumption, and how it will impact the
use of our new header.
In our Border Patrol MTA (TM), I authenticate the HELO name first, then run
additional checks (SPF, DKIM, etc.) as required by the sender, then run
SpamAssassin on any messages that are not from authenticated, reputable
senders. I haven't had any problem with SpamAssassin getting confused over
the strict chronological order of my headers. Here is a small section of
headers from a typical incoming message:
Received: from open-mail.org (open-mail.org [207.210.221.26]) by
fence.pobox.com (Postfix) with ESMTP id 330E37558 for
<xxx(_at_)pobox(_dot_)com>;
Tue, 31 Oct 2006 15:22:37 -0500 (EST)
Received: from mailout00.controlledmail.com (mailout00.controlledmail.com
[72.81.252.19]) by open-mail.org (8.13.1/8.13.1) with ESMTP id
k9VKMEC0001259
for <xxx(_at_)box67(_dot_)com>; Tue, 31 Oct 2006 15:22:15 -0500
X-Authent: 72.81.252.19 controlledmail.com DNS PTR ratings=(5,9,1001)
Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by
mailout00.controlledmail.com (Postfix) with ESMTP id 998315CC174 for
<xxx(_at_)box67(_dot_)com>; Tue, 31 Oct 2006 20:14:48 +0000 (UTC)
Received: from [192.168.111.103] (static-72-81-252-22.bltmmd.fios.verizon.net
[72.81.252.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested) by mailout00.controlledmail.com (Postfix)
with ESMTP id 74AD75CC167 for <xxx(_at_)box67(_dot_)com>; Tue, 31 Oct 2006
20:14:48
+0000 (UTC)
From: Scott Kitterman <xxx(_at_)kitterman(_dot_)com>
The path is kitterman.com --> verizon.net --> controlledmail.com -|->
open-mail.org --> pobox.com. The border between the sender's and
receiver's administrative domains is marked -|->. The X-Authent: line
marks this border in a confusing pile of Received headers. Everything
above that line is trusted, anything below may be faked.
I appreciate Alex's point that spammers may insert a fake X-Authent: header
just below the real one. The second is a forgery, or at least a seriously
messed up sender deserving an SMTP REJECT. X-Authent: should never occur
in outgoing mail.
-- Dave
************************************************************ *
* David MacQuigg, PhD email: macquigg at open-mail.org * *
* President, Open-Mail dot org phone: USA 520-721-4583 * * *
* Postmaster, Box67 dot com * * *
* 9320 East Mikelyn Lane * * *
* http://purl.net/macquigg Tucson, Arizona 85710 *
************************************************************ *
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735