Ok, the consensus seems to be for the text below, as long as it is
accompanied by additional changes to section 2.1 on the transfer of
responsibility and proper reporting. See my recap on Issue 32 and
subsequent discussion there for additional information on section 2.1.
For those advocating lots of changes dealing with "proper reporting",
please review sections 6.1, 6.2 and 7.8. As mentioned by Frank, these
sections already deal with the issues of "proper reporting" and when
it's appropriate and not appropriate. However, adding pointers to these
sections to the "proper reporting" text seems called for.
John has some text in hand, based on all of the fine suggestions here,
that will be included in 2821bis-04. Once that comes out, please review
sections 2.1 and 3.6.
Tony Hansen
tony(_at_)att(_dot_)com
Tony Hansen wrote:
I've been rereading all of the discussions around issues 0b/21/25. Some
of the discussion wants to require verification of the sender before
ever sending an non-delivery notification.
While this does reflect what some implementations are doing and is the
effort of some recent standards and non-standards efforts, it is not
common deployment. So I'm going to make a ruling that requiring such
validation goes too far in the direction of a "new behavior" requirement.
However, I'd like to follow the lead of the 3463 reference found in
section 2.3.11, and suggest that some wording be added, probably to
section 3.6, along these lines:
This specification does not deal with the verification of return
paths for use in delivery notifications. Recent work, such as
[add REFERENCES here], has been done in providing ways to
ascertain that an address is valid or belongs to the person who
actually sent the message. A server MAY attempt to verify the return
path before using its address for delivery notifications, but
methods of doing so are not defined here nor is any particular
method recommended at this time.
Thoughts on an addition like this? I know it doesn't go far enough for
some people, and probably goes too far for some other people. So I'm
offering it as a possible way forward.
Tony Hansen
tony(_at_)att(_dot_)com