[Top] [All Lists]

Re: making mail traceable

2004-01-16 14:30:54

On Fri, 16 Jan 2004, Keith Moore wrote:

    >  The "Received" header is woefully inadequate for spam tracing

    True.  Then again, so is the rest of the message format and mail

I don't agree it's "woefully inadequate."  I agree that many do not put
all the information they could in a Received header (because it is
optional), but that does not make the Received header itself inadequate.

The syntax could be stricter to make automatic processing easier, but
that does not make it inadequate, either.

What makes spam tracing hard is the fact that spammers lie in the
Received headers, or at least cheat so the wrong information is there.
How would a new syntax fix that?

Or did you have something else in mind?

    If we really want to make mail traceable, we need to do a bit more than
    fix Received.  As I see it, we need:

    - A message hash function that is invariant across the various kinds of
    munging that happens in mail transport, but still good enough for
    non-repudiation (though it probably won't be good enough to serve as a
    general-purpose signature)

    - A new header field which associates the message hash, originator-id,
    timestamp, and originating ISP or organization, which is signed by that
    originating ISP or organization, and which is easily verifiable by
    recipients or MTAs

Doesn't RFC1847 (security multiparts) already provide both of these, or
at least the framework sans the actual algorithm?

    - An originator-id separate from From, MAIL FROM/Return-Path, Reply-To
    or Sender that uniquely distinguishes the originator of the message
    from other message originators.  it doesn't have to actually expose the
    originator's name, email address, account name, etc. - it could be a
    nonce as long as the originating ISP or organization could trace it to
    the actual originator within a reasonable time.

So you want something functionally like the ident protocol built into
the Received header?

    - A way to ensure that messages get tagged with originator-id when they
    are injected into the mail systems (e.g. ISPs blocking port 25 and/or
    MTAs refusing to accept incoming mail without originator-ids or with
    unverifiable originator-ids)

I agree in principle, I think.  But couldn't a Received already provide
this information if everyone would just do it, i.e., it's optional now?

    - If you really wanted to, you could augment Received or add a new
    trace field that recomputed the hash at each hop (to show if and where
    the message was corrupted in transport)

Why would you forward a message that was discovered to be corrupted?

    This would give you a way to associate each message with an identifier
    for the originator, issued by the originator's ISP or organization.
    Then you'd need some way to ask that ISP or organization "is the guy
    who sent this message trustworthy?"  And they could say "as far as we
    know, he doesn't have many abuse reports and he's been with us for
    years" or "he just signed up yesterday" or "this is a trial account, we
    have no billing information for him" or "we've had several hundred
    abuse reports in the last 3 hours".

So you're looking for an extension to the ident protocol based on the
presence of a "string" inserted in a message by its original point of

    But do we really want traceability?  Or to put it another way, do we
    really want to put hooks in the mail system that make mass
    surveillance (by governments, or perhaps even by large companies or
    unscrupulous ISPs) that much easier?

I'm sorry but I just don't see what you have in mind that is worse than
it is today, nor do I see us needing anything that we don't already have
(except perhaps to operationally require it).

Can you please elaborate on the "mass surveillance" you fear?