On Fri, Aug 06, 2004 at 03:03:14PM +0200, Stephane Bortzmeyer wrote:
| On Thu, Aug 05, 2004 at 10:49:09AM -0700,
| Hadmut Danisch <hadmut(_at_)danisch(_dot_)de> wrote
| a message of 35 lines which said:
|
| > How does the information find it's way to the MUA? The SUBMITTER is
| > not an RFC2822 information. Were does it find it's place in a
| > standard Unix mbox file without changing the mbox file format?
|
| They way I understand draft-ietf-marid-submitter-02, it is the
| opposite. The SMTP client must derive the submitter from the
| 2822-headers (see 4.2 "Processing the SUBMITTER Parameter" and
| 4.3). So, there is no need to send SUBMITTER back into 2822-headers
| (just a check, described in 4.3).
I want to comment on how the phrasing above frames the
relatioship between PRA and SUBMITTER.
Alan Kay said: The best way to predict the future is to
invent it.
In the same way, sometimes the best way to "derive the
submitter from the 2822-headers" is to assign it.
If you have a given block of headers, you can derive the PRA
by examining the headers according to the algorithm
described in core (now moving to a separate document).
But you can also cheat. You can simply prepend a
Resent-Sender or Resent-From header to the existing block.
Because you know what you prepended, you can assign that
value directly to the PRA variable. That way you don't need
to look at the existing block of headers at all. SUBMITTER
and PRA are synonyms.
In the above paragraph, who is "you"? The current thinking
represented by the current drafts says "you" is the SMTP
client.
Niels Bohr said: The opposite of every great idea is another
great idea.
Suppose we turn things around and set "you" to be the SMTP
server.
It is possible to construct an equivalent operation in which
the SMTP sender system *does not* prepend a PRA to the
headers, but instead only assigns SUBMITTER. In that world,
the SMTP *receiver* system is responsible for taking the
given SUBMITTER value and prepending it to the headers as a
Resent-* field. SMTP receivers already do this --- "MAIL
FROM" turns into the Return-Path, so why shouldn't
"SUBMITTER" turn into Resent-From? It is not a technical
challenge.
If the algorithm by which PRA is derived from the headers
turns out to be encumbered, the above workaround offers all
the functionality of the PRA/SUBMITTER system but without
the heartache. It is, as it were, an independent
implementation, written without reading the original source
code, that offers the same feature set.