Re: Realisticness of header rearrangement

On Apr 05 2004, david nicol wrote:

> 
> 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))

The received time stamp is only a hack, but it's the only one that has
a hope of working. 

AFAIK, all the other elements of a Received: line stay the same for
all messages passing through that MTA. So in practice, a spammer
simply has to get a hold of a single message which passed through the
MTA, and he can harvest all the unchanging elements of the Received:
line (name of server, its ip address, whatever).

So for example if your filter-event-id is based on the MTA name, then
a spammer can spoof this easily. If your filter-event-id is based on
the timestamp, then because the timestamp changes from message to
message, the spammer can't learn such a timestamp to spoof 
such a filter-event-id.

Ideally, in the future, the Received: line should contain a randomly
generated token, then we could use that token instead of the timestamp.

> 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,

What if the spammer inserts his own messageID right at the beginning
of the transaction? He could program his client to pretend it is a
relay.

> 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.

Not so. You can process as many messages simultaneously as you like,
the trust issue is only confined to a single message at a time. 

E.g.: When a filter is trying to detect a spoofed tag in message M, then 
the fact that another message M' exists somewhere else in memory has
no relevance.  

> 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.

That's possible and easy to do. For example, instead of using the
timestamp string as-is, it could be hashed, or it could be transformed
into a number of seconds since january 1, 1970. In that case, you
would have the received-id given by some large integer.

Just to reiterate, even though I've said it a few times: the timestamp
is only used as a piece of information that is supposedly unspoofable by the
spammers, except by chance. The actual date represented by the
Received: timestamp is unimportant, any function of it would work just
as well.

-- 
Laird Breyer.