--On Friday, 27 April, 2007 05:33 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
...
2822upd-01 still says:
trace = [return]
1*received
That's at most one <return>, not more.
See Pete's note. But, to try to explain this differently than I
did before, 821 and 2821 view the syntax rules as explanatory
adjuncts to definitive and normative text. You are trying very
hard to make them specific and normative. I think that is a
fine idea in principle but, coming back to Dave's original
comments on the problem, I think trying to make that change is
incompatible with the goal of getting 2821bis done quickly and
accurately.
At least as important, since 2821 is written on the theory that
MTAs should not be examining any header lines other than those
that they put in, the only header-related syntax needed by a
given instance of an MTA is the syntax needed to _supply_ at
most one Return-path header line and one or more Received header
lines. All of the rest of the header section is, as far as that
model is concerned, an undifferentiated blob and, absent
extensions (BDAT in particular) is even undifferentiated from
the message body.
Requiring it would not match current practice in several
cases, but, if people are convinced that it was necessary to
ensure good interoperability, it could be done.
RFC 2822 and 3834 don't mention that there could be more than
one, and that's what authors of "vacation" and "out of office"
scripts hopefully read after their users got enough spamcop
reports.
We are not convinced that it is necessary.
You trust that "vacation" implementors get it right, and take
the top <return> ?
"Vacation" implementations are the problem of 3834. If one were
to take a very narrow view of 3834, it is improperly, or at
least insufficiently, written because it is well-known that a
message may be received (e.g., by the agent for the MUA that
generates a vacation message) with more than one such header
line. Both 821 and 2821 specify the conditions under which a
Return-path is to be inserted, but neither requires finding or
removing any that might exist.
And do you think that 2822upd can stay as
is with a single <return> in this case ?
Yes. See above and Pete's note.
Given the above, we don't see much value in a reference from
2821bis to 3834, although we don't see it as harmful either.
I think it would help. The case of no Return-Path is harmful
for authors of auto-responders, compare
RFC.ietf-sieve-vacation-07.txt
The case of no Return-path is clearly problematic. But there is
a MUST on inserting the Return-path. Certainly 2821bis does not
reference specifications that would exhibit damage if other
"MUST"s were ignored.
john