From: Stephen Satchell (listfluent2.pyramid.net)
Date: Thu May 01 2003 - 11:14:08 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

To all:

I have been following the progress of the various anti-spam measures
through legislatures across the United States, and one thing keeps hitting
me over and over: in order for some of these laws to be enforceable we
need to add another piece of envelope information to the Received: header,
the MAIL FROM: command parameter.

BACKGROUND

Here is a Received: header from a test message I sent myself:

>Received: from chi.satchell.net (chi.fa-local.com [10.1.1.20])
> by fluent2.pyramid.net (Postfix) with ESMTP id 52FB242703
> for <satchsatchell.net>; Thu, 1 May 2003 07:19:38 -0700 (PDT)

Now, reading this header, I see:
      1) source system
      2) receiving MTA, with internal message ID
      3) envelope's RCPT TO:
      4) timestamp of transaction.

Now, in theory, you take the timestamp and ESMTP ID of the transaction and
go back to the logs to get further information. I don't know about you,
but I only keep logs 45 days right now, so if someone comes back at me
later the added information is GONE.

(N.B.: Now, I can see a change to the Best Practices RFC requiring logs to
be held for a longer period based on the statute of limitations that is
assigned to actions brought based on the new laws (I would guess a year;
the bill drafts vary quite a bit and are sometimes silent on the subject),
which means that each of us would need to change our logging systems to
increase the hold time. Then there is the administrative burden of going
through the logs and extracting information about a specific transaction, a
transaction that could span several days' worth of logs if any of the MXes
were down or unresponsive.)

PROPOSAL

I propose that PostFix, as a standard mode of operation, add the
X-Mail-From: line containing the MAIL FROM: parameter information as part
of the Received: header generation

    Received: from chi.satchell.net (chi.fa-local.com [10.1.1.20])
            by fluent2.pyramid.net (Postfix) with ESMTP id 52FB242703
            for <satchsatchell.net>; Thu, 1 May 2003 07:19:38 -0700 (PDT)
    X-Mail-From:
<randy.dandy.spammerall-hail-canter-seigal.spamhause.example.com>

(Not that a real spammer would advertise quite this way, of course...)

This suggestion is supported by the statements in RFC 2505 section
2.2.1: "These recommendations are deliberately stronger than RFC1123, [3],
and are there to assure that mail sent directly from a spammer's host to a
recipient can be traced with enough accuracy; a typical example is when a
spammer uses a dialup account and the ISP needs to have his IP address at
the 'date-time' to be able to take action against him." I believe that my
suggestion amplified on the intent of RFC 1123, and is justified in the
current UCE/Spam climate.

The major benefit is that all necessary information to prosecute against a
person for committing fraud is now in the content of the mail message as
received by the victim. Spam filters would have something else to test
for, that the envelope MAIL FROM: and the From: line identify the same
entity, and can shunt those messages with differing sources to a
lower-priority queue.

Indeed, seeing as virtually all human-run client software builds the MAIL
FROM: command using the data in the From: content header line, any
difference in the machine address is due to malice, incompetence, or a
program bug. It also provides visibility for programmers writing automatic
mail generators, to ensure they get the envelope right. Currently, there
is little incentive for those programmers to CARE what the MAIL FROM: field
looks like.

I believe the impact on bandwidth will be very small, and well worth the
delta for the benefit. As most mail is now transmitted in one or two hops,
instead of being relayed multiple times as was true in the past, the actual
effect on bandwidth to add the MAIL FROM: information is lost in the noise
of HTML mail with embedded pictures. Most mail programs suppress the
display of the Received: headers and X-* headers unless commanded not to,
so the effect on the end user of mail is zero.

The preferred way is to lobby for a change to the Received: header, to add
the following syntax to the existing list as shown in RFC 2821 section 4.4:

  - Opt-info = [Via] [With] [ID] [For]
  + Opt-info = [Via] [With] [ID] [For] [From]
  + From = "FROM" FWS 1*( Path ) CFWS

but that might take a while to get through the committees and to a
standard. I don't even know the process for starting such a
campaign. It's a logical extension, but logic has not been the strong suit
of some of the movers and shakers in the Internet world...

Some people on this list would argue that this behavior should be an
optional one, enabled by an appropriate configuration command. I'd listen
to such arguments with interest.

Anyway, that's my pair-o'-pennies(tm) on the subject. I await your
reactions with flame-proof underwear firmly in place.

Satch

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]