At 05:46 PM 5/9/2005 -0400, Mark Shewmaker wrote:
On Mon, May 09, 2005 at 02:10:33PM -0700, David MacQuigg wrote:
>
> I also
> don't like the confusion with the order of headers. It seems to me that
> headers should be prepended in exactly the order that the events
> occur. Authentication first, then Received header.
But you can only trust the opposite, so it seems to me as if that is
what you should always do, if technically possible.
Here's my reasoning:
If my MUA always trusts the most recent MTA's claims by default, then
when it sees a piece of email starting with example A:
Return-Path
Authentication-Results:
Received:
then it can know that most recent MTA added that Authentication-Results:
line, and trust the info there.
However, if it sees example B:
Return-Path
Received:
Authentication-Results:
Received: (forging MTA)
Then it can't tell the difference between:
The authentication header being placed by the forging mta
and
The authentication header being placed in this order by the latest mta
If it were placed by the forging MTA, there would be *two* authentication
headers, the second one clearly out-of-place.
Since if you trust your incoming mail server you can always trust
top-most authentication results in example A but not in B, IMHO it makes
sense as a blanket rule for MTAs to always add their authentication
headers so they appear above their added Received: header.
Don't we have the same fundamental problem drawing the line of trust at a
Received header? Those headers can be faked just as well as authentication
headers. Either way, you start at the top and go down until you get to the
first name you don't trust.
Here is a typical pile of headers ( from Scenario D at
http://purl.net/net/macquigg/email ). The hypothetical Authent: headers
have been added. The first one I trust, because it is my own ISP. The
second one I trust, because pobox.com is my forwarder. The third one I
don't trust, so it really doesn't matter if the spammer puts an extra
Authent: header in the wrong place. He can't get rid of the real Authent:
header put there by pobox.com. In fact, it will be very suspicious if an
email comes in with an Authent: header at the very top, might even be cause
for an immediate reject.
Return-Path:
<SRS0=BF6T=RK=amazon(_dot_)com=forged(_at_)bounce2(_dot_)pobox(_dot_)com>
Delivered-To: <mailto:dmq(_at_)gainusa(_dot_)com>dmx(_at_)gainusa(_dot_)com
Received: ( **SaniMail 47655 invoked from network** ); 28 Feb 2005 15:35:36
-0000
Received: from unknown (HELO gold.pobox.com) (208.210.124.73)
by mail5.mailsystem.us with SMTP; 28 Feb 2005 15:35:36 -0000
Authent: 208.210.124.73 pobox.com CSV1 PASS
Received: from gold.pobox.com (localhost [127.0.0.1])
by gold.pobox.com (Postfix) with ESMTP id 6CFD67111A
for <dmx(_at_)gainbroadband(_dot_)com>; Mon, 28 Feb 2005 10:42:29 -0500 (EST)
Delivered-To: <mailto:dmq(_at_)pobox(_dot_)com>dmx(_at_)pobox(_dot_)com
Received: from gold (localhost [127.0.0.1])
by gold.pobox.com (Postfix) with ESMTP id 4DE60710B8
for <dmx(_at_)pobox(_dot_)com(_dot_)07422030(_dot_)000(_dot_)icgmh>; Mon, 28 Feb 2005 10:42:29 -0500
(EST)
X-Pobox-Pass: forged(_at_)amazon(_dot_)com is whitelisted
Received: from amazon.com (unknown [216.183.71.194])
by gold.pobox.com (Postfix) with SMTP id 51DD271180
for <dmx(_at_)pobox(_dot_)com>; Mon, 28 Feb 2005 10:42:26 -0500 (EST)
Authent: 216.183.71.194 amazon.com SPF1 PASS
Received: from [219.130.16.181] smithbarney.com (helo=67.15.58.29 verified)
by server5.emwd.com with smtp (Exim 4.44) id 1Cxh3v-0006Ab-8W
for cdx-design(_at_)cdx-design(_dot_)org; Sun, 06 Feb 2005 02:42:52 -0500
Authent: 219.130.16.181 smithbarney.com SenderID PASS
FCC: mailbox://identifdep_id7(_at_)smithbarney(_dot_)com/Sent
X-Identity-Key: id1
Date: Sun, 06 Feb 2005 06:36:53 -0100
From: SmithBarney <identifdep_id7(_at_)smithbarney(_dot_)com>
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:
<mailto:cdp-design(_at_)cdp-design(_dot_)org>cdx-design(_at_)cdx-design(_dot_)org
Subject: Attention To AII Smith Barney CIients
Content-Type: multipart/related; x-Spamnix=checked;
boundary="------------060705020202080904070006"
X-Antivirus-Scanner: Clean mail though you should still use an Antivirus
Message-Id:
<mailto:20050228154226(_dot_)51DD271180(_at_)gold(_dot_)pobox(_dot_)com>20050228154226(_dot_)51DD271180(_at_)gold(_dot_)pobox(_dot_)com
It's not a big problem reversing the order of Authent: and Received: It
just seems a little counter-intuitive to me.
I guess with SenderID, it's actually *not* a reversal, since they have to
get the DATA first, then authenticate. Whichever way we go, for spam
filters to work, the order has to be standardized, even if it is opposite
one method's actual order of events. I find it simpler to draw the lines
at each Authent: header. But I could almost as easily draw the lines at
each Received: header that is directly below an Authent: header, ignoring
Received: headers that are internal to an administrative domain.
Kucherawy works for Sendmail, one of Microsoft's 35 "Industry
Collaborators", so that may explain the order chosen in his draft.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *