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).
Misreading the draft as to the significance of Submitter is a reason for
not introducing this field. A Should must be a Must check. The general
goal was to protect the RFC 2822 headers. To neglect checking RFC 2822
headers would remove this protection without any record of this lapse.
How should a MUA be able to display an information as long as there
is no defined way how the MTA should pass the information to the
MUA?
See above. For instance, I quote draft-ietf-marid-submitter-02, 4.3 :
This should involve no information loss, since the SUBMITTER parameter
is required to contain information derived from the message headers.
The claimed optimization depends upon a spammer being behind the curve.
The receiving MTA must check both the Submitter and RFC 2822 headers, but
Submitter may allow this header check to be skipped. Do not expect
Submitter parameters to fail acceptance to any degree, once its use
becomes prevalent. Submitter acceptance can be accomplished any number of
ways, many without requiring an administrative relationship to various DNS
records.
I would not expect any optimization likely, but rather an added security
flaw is created. There is also the opportunity for differences in the PRA
checks between two systems to then force rejection of messages. The
errors may provide clues, but could become a mysterious problem, as what
is being asserted is not recorded.
Going down this path seems to be based upon an assumption spammers will be
thwarted by this check. It is more likely this check will benefit
spammers and make support more difficult.
-Doug