Realisticness of header rearrangement

On Tue, 2004-03-30 at 19:24, Philip Miller wrote:
>  However, ordering is not guaranteed in the transport system, 
> which is relevant in at least one not-uncommon case:
> Bob has an address, [email protected]. The MX for ieee.org scans and tags 
> messages and then forwards them on to [email protected]. In transit between 
> ieee.org and other-isp.net, the headers get rearranged.


Rearranged by what?

By a router? no. Routers operate at the IP layer and are oblivious
to the nature of the traffic passing through them.

By a relay? relaying went out of style a decade ago.

ieee, doing the tagging, will have a non-rearranging outbound MTA that
connects directly (no intervening SMTP relay) to other-isp.net's
inbound. I will allow that other-isp.net's inbound MTA might rearrange
headers between receipt and delivery, but the concept of a
interconnected web of SMTP relays is completely obsolete in my opinion.

I am not opposed to including an optional checksumming and signing
protocol but I do not believe it to be a core requirement, especially
since it assumes distribution of public keys of filtering agents.

I think a key included in both Received and Tagged is superior
to reusing the timestamp.  Tagged would have two timestamps, if
there was a delay, and that would be confusing.  Received usually names
the receiving agent and domain, so Tagged could use the same identifying
information.

About PK-signing individual e-mail header lines? Cold we just punt that
concept to a working group on PK-signing individual e-mail header lines
instead of tackling it here? Reccomend that if a standard emerges, the
filtered/tagged line should follow it?

Here are a couple header lines for reference:

Received:  from fda.zemos.net ([127.0.0.1]) by localhost (fda
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20168-03; Tue, 30
Mar 2004 20:24:38 -0500 (EST)

Received:  from zemos.net (phil [10.0.0.2]) (using TLSv1 with cipher
DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by
fda.zemos.net (Postfix) with ESMTP id 5BDD41867F; Tue, 30 Mar 2004
20:24:38 -0500 (EST)


Received lines generally identify themselves with hostname and
software used.  Tagged lines could do the same.  Received lines are
not currently signed, even when reporting that a connection was secure.


Yes, I trust that Philip Miller uses a secure connection to upload
e-mail to zemos.net; that zemos.net uses amavis anti-virus software;
that zemos.net then passes its e-mail to comcast.net, which forwarded
the message to the asrg mailing list on iecc.com, where qmail copied it
a couple times before sending me a copy from a VERP return address.

Received:  from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by
tipjar.com id i2V1Onnt012224; Tue, 30 Mar 2004 18:24:50 -0700 (MST)
X-Received-From:
[email protected]
X-Received-For:  <[email protected]>
Received:  (qmail 729 invoked by uid 85); 31 Mar 2004 01:24:47 -0000
Received:  (qmail 719 invoked from network); 31 Mar 2004 01:24:44 -0000
Received:  from rwcrmhc13.comcast.net (204.127.198.39) by mail2.iecc.com
with SMTP; 31 Mar 2004 01:24:43 -0000
Received:  from fda.zemos.net ([68.38.12.170]) by comcast.net
(rwcrmhc13) with ESMTP id <20040331012440015007pgdte>; Wed, 31 Mar 2004
01:24:40 +0000
Received:  from localhost (fda [127.0.0.1]) by fda.zemos.net (Postfix)
with ESMTP id EE91518683; Tue, 30 Mar 2004 20:24:38 -0500 (EST)
Received:  from fda.zemos.net ([127.0.0.1]) by localhost (fda
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20168-03; Tue, 30
Mar 2004 20:24:38 -0500 (EST)
Received:  from zemos.net (phil [10.0.0.2]) (using TLSv1 with cipher
DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by
fda.zemos.net (Postfix) with ESMTP id 5BDD41867F; Tue, 30 Mar 2004
20:24:38 -0500 (EST)
Message-ID:  <[email protected]>


The fact of the comcast step between zemos and iecc leads to the
conclusion that zemos is on comcast's network, sonce in general
postfix is perfectly capable of delivering without using a smarthost.


Were a Tagged: header to be a standard, amavisd, which is a virus and
spam filter, is the sort of program that would add one. On what I guess
is Phil's firewall, the Received: header currently added by amavisd
when postfix hands incoming to amavisd and then gets it back for
upstream delivery might be a Filtered: header _instead_of_ a Received:
header

Tagged:  Host=(fda[127.0.0.1]); Tagger=amavisd-new; Tue, 30 Mar 2004
20:24:38 -0500 (EST); Result=CLEAN