In <42E23A6E(_dot_)3FAD(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:
wayne wrote:
It's pretty simple, scan the header for Resent-Sender, then
Resent-From, then Sender, then From (each step top down),
and take the first match. [...]
[...]
I don't think the PRA is really that simple and I think that
Frank's description is wrong.
How about looking into the spec. ? Six steps in only 25 lines.
The PRA is found is taken from the From: header.
| 1. Select the first non-empty Resent-Sender header in the
| message.
You got it backwards. But step (1) has in fact a special rule
if the Resent-Sender is separated by trace header fields from
a _preceding_ Resent-From (in that case they use Resent-From).
Do I have it backwards? I believe that is exactly what I said. Your
description, on the other hand, left out that "special rule"
But, what the heck. You claim the PRA is simple, only 6 steps in 25
lines and you suggest looking at the spec. Ok, here is the spec's
description of the PRA. I'll leave it up to the reader to decide if
this is "simple" or "25 lines". (Note that details needed to
determine the PRA are included in the text following the 6 steps.)
2. Determining the Purported Responsible Address
The purported responsible address (PRA) of a message is determined by
the following algorithm:
1. Select the first non-empty Resent-Sender header in the message. If
no such header is found, continue with step 2. If it is preceded
by a non-empty Resent-From header and one or more Received or
Return-Path headers occur after said Resent-From header and before
the Resent-Sender header, continue with step 2. Otherwise,
proceed to step 5.
2. Select the first non-empty Resent-From header in the message. If
a Resent-From header is found, proceed to step 5. Otherwise,
continue with step 3.
3. Select all the non-empty Sender headers in the message. If there
are no such headers, continue with step 4. If there is exactly
one such header, proceed to step 5. If there is more than one
such header, proceed to step 6.
4. Select all the non-empty From headers in the message. If there is
exactly one such header, continue with step 5. Otherwise, proceed
to step 6.
5. A previous step has selected a single header from the message. If
that header is malformed (e.g. it appears to contain multiple
mailboxes, or the single mailbox is hopelessly malformed, or the
single mailbox does not contain a domain name), continue with step
6. Otherwise, return that single mailbox as the Purported
Responsible Address.
6. The message is ill-formed, and it is impossible to determine a
Purported Responsible Address.
For the purposes of this algorithm, a header field is "non-empty" if
and only if it contains any non-whitespace characters. Header fields
that are otherwise relevant but contain only whitespace are ignored
and treated as if they were not present.
Note that steps 1 and 2 above extract the Resent-Sender or Resent-
From header from the first resent block (as defined by section 3.6.6
of [RFC2822]) if any. Steps 3 and 4 above extract the Sender or From
header if there are no resent blocks.
Note that what constitutes a hopelessly malformed header or a
hopelessly malformed mailbox in step 5 above is a matter for local
policy. Such local policy will never cause two implementations to
return different PRAs. However it may cause one implementation to
return a PRA where another implementation does not. This will only
occur when dealing with a message containing headers of questionable
legality.
Although the algorithm specifies how messages that are not in strict
conformance with the provisions of RFC2822 should be treated for the
purposes of determining the PRA, this should not be taken as
requiring or recommending that any systems accept such messages when
they otherwise would not have done so. However, if a liberal
implementation accepts such messages and desires to know their PRA,
it MUST use the algorithm specified here.
Where messages conform to RFC822 rather than RFC2822, it is possible
for the algorithm to give unexpected results. An RFC822 message
should not normally contain more than one set of resent headers;
however the placement of those headers is not specified, nor are they
required to be contiguous. It is hence possible that the Resent-From
header will be selected even though a Resent-Sender header is
present. Such cases are expected to be rare or non-existent in
practice.
-wayne