Re: Realisticness of header rearrangement

On Sat, 2004-04-03 at 21:47, Philip Miller wrote:
> [ ... potential] problems if some
> provider not directly controlled by the final recipient uses MTA software
> that rearranges headers.
> 
> > ieee, doing the tagging, will have a non-rearranging outbound MTA that
>                                         ^^^^^^^^^^^^^^^
> That's the statement I don't agree with. Because the standards don't require
> non-rearrangement, we should not depend on that behavior.

Wea re proposing a standard, therefore we can include "these do not
rearrange" as part of the standard.


> I am not opposed to signing or checksumming mechanisms as an optional
> extension. However, as the sole method of authenticating a tag header, I am
> opposed to them. I am opposed to them as the sole authentication method
> because they are much more expensive to compute than copying the date stamp, 
> and that could needlessly hinder adoption by large service providers.
> 
> > 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.
> 
> As far as I can tell, we are trying to design this header so that the vast
> majority of its use will be in a parsed form by a GUI MUA that presents the
> contained information to the user in a useful format or processes the mail
> as a result of the tags attached. MUA programmers are quite capable of using
> two separate variables independently.
> Anyone reading headers, who we can assume is a fairly advanced user, will
> learn pretty quickly that this one has 2 time stamps, and they are used for
> different things.

And the second use isn't a time stamp any more, therefore its confusing.
An explicit event-ID would be clearer (not confusing as a timestamp
being
used for something other than marking the time something happened))
A filter-event-id, re-use the messageID or make up a new code, could be
protected by vendor-specific checksumming, could be listed in an
independently verifiable database accessible via another channel,
etcetera,  Yes you can do all this with a timestamp but if processing
more than one message per second a timestamp/messageID tuple would be
required anyway.

> I don't think we need any particular way to sign headers. It's an expensive,
> silly proposition with limited use.

I want to add an "out of scope" section on the wiki, unless someone
beats me to it

> And I think they should, but for debugging and trust reasons. The tuple
> (hostname, received-timestamp) in a tagged header authenticates that said 
> tag was added with or after the Received header it matches. The user can 
> choose to trust or not trust the judgement made at that point in the system.
> Note: when I say 'user' here, I mean 'the user or the software under the
> user's direct control'. That would be the MUA, and in my case, my private
> email server, fda.zemos.net.
> 
> > 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.
> 
> The first half of that trust is misplaced. For all you know, I connected
> directly to the iecc.com MX and forged all the prior headers. 

> As long as I had the right IP address,

But you didn't, and the mail2.iecc.com server looked up your IP
address.  There are a lot of subtle interactons that can make
foged headers look fishy.  Other working groups are trying to
formalize an expert system about fishiness of received headers,
unless I have gist of the the charter of the path verification working
group wrong.


> Basically, it's impossible to trust headers that were added on 'my side' of
> the mailing list server.

If relays on the receiving side  don't rearrange headers, and I am
expecting to see a tag, I can rely on the relays closer to me to not
rearrange the headers and the last tag added will be first, so I won't
even see your tag, or a forged tag, because it will be hidden by the
earlier tag.

Just an off-topic note, I have received the first piece of junk mail
in my pay2send.com address ever, today, it seems that a junk mailer
has amavis-perl tag all outgoing messages with a X-Virus-Scanned:
header, which matched my far-too-trivial magic phrase "perl."

So the issue of tags added at sending of junk is very much real.  Were
I looking for an X-Virus-Scanned header with software that escaped other
X-Virus-Scanned headers that might be there already, perhaps turning
them into X-Mycompany-Hidden-Virus-Scanned, the one added on sending
would be ignored due to being rewritten; if my software that read for
that header only took the first matching header (which would require
altering current MUAs, that do not differentiate between different
instances of the same header AFAIK), a matching header placed by my
software would hide a matching header placed by the sender.


>  Making sure that tag headers are uniquely
> associated with specific Received headers means that you can choose exactly
> which step to start trusting.

no argument with this, except that a relay or processing step
administration is what we want to associate with.  Associating with a 
Received: header seems to me to be a classic case of confusing the name
of a thing for the thing.


> > Tagged:  Host=(fda[127.0.0.1]); Tagger=amavisd-new; Tue, 30 Mar 2004
> > 20:24:38 -0500 (EST); Result=CLEAN
> 
> I would write it more as follows:
> 
> Tagged: Received-from=zemos.net (phil [10.0.0.2]); Received-time=Tue, 30 Mar
>     2004 20:24:38 -0500 (EST); Host=fda.zemos.net; Tagger-name=amavisd-new;
>     Tagger-version=xxxxxx; Virus=no; Tagger-time=Tue, 30 Mar 2004 20:25:42
>     -0500;
> 
> Note the following:
> 1. Everything is a key-value pair, timestamps and all.

Received lines tend not to follow this format.  They tend to
use barewords (by, from, with) separated with whitespace to
identify the parts of the header.  I would like to issue
a reccomendation to update SMTP to make received line syntax
conform to something too.  Too much coffee?

> 2. This tag was provably added after a particular receipt in the mail
> transport system. It's ambiguous

I'd like an explicit Received-ID or Action-ID or tagging-ID to use
instead of timestamp.  Using timestamp for ID seems to me to be an
ugly kluge instead of an elegant reuse of existing information.  This
may be a purely aesthetic opinion.

> The timestamp in yours matches the timestamp in the Received lines, but I
> think it would be useful, for debugging, if nothing else, for tags to
> include the time they were added, as it may differ by quite a while from the
> time of receipt.

I agree

>  In the case of resource-intensive scans, such as virus and
> statistical or DNS-lookup-based scanners, being able to attribute a delay to
> a specific scan is a good thing.

I agree

> Philip Miller



-- 
david nicol
this message was sent from a filtering e-mail address.
"cat and buttered toast"