[Top] [All Lists]

Re: rfc2821bis-03 Issue 22: Return-path required removal

2007-04-26 20:46:20

John C Klensin wrote:

I have now reviewed these issues with Keith Moore, the author
of 3834.

Good, I like this RFC so much that I wrote a script yesterday
to get a good explanation into the clipbrd for manual spamcop

| erroneous bounce to the From-address of a list member
| instead of the envelope sender address, for details see
| RFC 3834

the only question is whether delivery servers, which need to
add a Return-path of their own should be required (presumably
with a SHOULD, possibly a MUST) to verify that there are no
Return-path header lines present, and removing them if needed

2822upd-01 still says: 

  trace           =       [return]

That's at most one <return>, not more.

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> ?  And do you think that 2822upd can stay as is with
a single <return> in this case ?

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