Re: [Exim] -t and Resent- header lines

Top Page
Delete this message
Reply to this message
Author: Tony Finch
Date:  
To: Philip Hazel
CC: exim-users
New-Topics: [Exim] Re: traceability of e-mail vs. stupid DNS tricks.... (was: -t and Resent- header lines)
Subject: Re: [Exim] -t and Resent- header lines
On Thu, May 08, 2003 at 03:43:54PM +0100, Philip Hazel wrote:
> On Thu, 8 May 2003, Tony Finch wrote:
>
> > 2822 allows only one To: header field, so it makes sense that each
> > Resent-To: header field corresponds to a different resending.
>
> That's a guess. The RFC does not actually say that there should only be
> one Resent-To: for each resending.


It does actually -- the table in section 3.6 says:

Field           Min number      Max number      Notes


resent-to       0               unlimited*      One per block - see
                                                3.6.6
etc.


> > Exim should get the destination address from the first set of Resent-
> > headers in the message,
>
> Where does the first set end in this sequence?
>
> Resent-From: xxx
> Resent-To: xxx
> Resent-Date: xxx
> Resent-Cc: xxx
> Resent-To: xxx
> Resent-From: xxx
>
> Which set does Resent-Date: belong to? Which set does the Resent-cc:
> belong to?


I've had another look and noticed that the syntax says that each
Resent- block must be separated by at least one Received: line.
Section 3.6 again:

fields          =       *(trace
                          *(resent-date /
                           resent-from /
                           ...))
                        *(orig-date /
                        from /
            ...)


which implies that your problematic example is a syntax error.

When Exim is assisting the MUA perhaps it should expect any Resent- lines
to appear at the start of the header before the first Received: line
(later Resent- lines being from previous resendings). This is a slight
deviation from the strict 2822 syntax because it omits the Received:
line before the Resent- block (though the syntax allows a Resent- block
after all Received- lines which doesn't make much sense).

Trying to accommodate the obsolete syntax is a lost cause.

Digression: The anti-spam research group has been arguing a lot about
improving the traceability of email. One of their suggestions is to
add an RR type to the DNS similar to MX records but for email emitters
rather than receivers. Email from a machine that isn't listed as one of
the return path's domain's email emitters is therefore obviously forged.
However this idea interacts badly with .forward files since they send
email on without changing the return path. The general opinion seems to
be that the mailing list BCP of changing the return path when forwarding
the email should be applied to all forwardings. However this changes
the way you must deal with bounces that result from .forwardings...
Anyway, my point is that perhaps Exim might optionally do the Resent-
thing for redirects when changing the return path.

Tony.
--
f.a.n.finch <dot@???> http://dotat.at/
SOLE: NORTHWESTERLY BACKING SOUTHWESTERLY 3 OR 4. OCCASIONAL RAIN. GOOD
BECOMING MODERATE.