--On Saturday, 16 February, 2008 12:36 +0100 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> wrote:
Hi,
Tony Hansen wrote:
This message finishes the list of other issues with
draft-klensin-2821bis or bugs that were found during the last
call, and their disposition if consensus was gained.
I've posted a few messages about section 3.9. I understand I
should have posted that 4 or 5 years ago, but I only joined
this list last Jan 16th. Thus, if at all possible, I'd ask if
some cleanup can be considered before the text is standardized.
Section 3.9.2 "List" is different in rfc2821bis-0N (0N>= 03)
w.r.t the current rfc2821. The added final note,
distinguishing alias expansion and forwarding, would be
correct if that subsection were named "Forwarding".
Because the surrounding text specifically describes mailing
lists, it may instead convey the wrong impression that the
envelope sender address should be changed in that case _only_.
(Of course, the envelope sender MAY be changed when privacy or
policy concerns require it, according to section 4.4.)
I apologize for my scarce knowledge of standardization
processes; that notwithstanding, I hope the IETF will release
a coherent standard.
Alessandro,
Speaking strictly as an individual contributor, we have a bit of
a problem here. The forwarding model is tricky, and various
theories about when one should, and should not, change envelope
addresses --and how to respond when others do it-- to counter
spam and other bad behavior make it worse. At least one or two
major email providers offer forwarding services (mail comes in
on one address and goes out to another) from their systems but
reject mail forwarded from others.
I believe that a major piece of work is required in this area,
probably of the variety that requires a working group rather
than a discussion of a draft that is supposed to reflect tuning
improvements to work done many years ago that reflected current
and preferred practice at the time. Trying to "patch" 2821bis,
especially under the constraints of advancing to Draft Standard
and post-last-call, is just not going to do it, either
procedurally or technically.
I would suggest --again, speaking only as an individual
contributor-- what has been suggested to others who expressed a
desire for substantive changes in 2821bis. That is to generate
a separate draft, discuss how it should be progressed with the
Area Directors, and move that work forward with the intent of
moving it into the _next_ generation of descendents of 821.
john