On Fri, 2004-09-17 at 07:22 -0700, Hallam-Baker, Phillip wrote:
Given the cacophony of verbiage you guys are throwing up I am not
replying to individual emails point be point, instead I am following
the repeated directions of the chair and I am collecting my points
into one post.
I did send a lot of email and for that I have already apologised to the
co-chairs after the three message guideline was mentioned to me.
Now that I am posting anyway, I offer my apology to the other
participants too. I shall limit my posting in future.
I made three main technical points which I then argued in support of;
none of which you appear to have addressed directly. They were:
1. The use of '-all' on domains which do actually send mail should be
forbidden in both mailfrom and pra scopes, until a later date when it is
decided that enough of the world has upgraded to cope with this.
Others said that this should be a site-specific policy, but we as a
group are here to co-ordinate _interoperability_ rather than preside
over a system which degenerates into chaos. By publishing RFCs we set up
rules which are to be followed to ensure compatibility -- an RFC 'MUST
NOT' is a rule which should be followed to ensure interoperability, not
a law which we would jail you for disobeying.
As a compromise I suppose I would accept Rik van Riel's suggestion of a
SHOULD NOT. Others who vehemently opposed my suggestion of 'MUST NOT'
were also amenable to that.
2. The reuse of the Resent-From: header is not in accordance with
current practice, and not in accordance with many interpretations of
RFC2822.
Although the latter point has been disputed, the former has not -- and
no reason has been put forward for the choice of 'Resent-From:' instead
of the introduction of a new and unambiguous header. Therefore I assume
that consensus has been reached, and this will be changed in the next
draft which describes the pra scope. As a straw man, I propose the use
of 'Forwarded-For:' in replacement.
3. The ability of forwarders to use SRS or the Forwarded-For: header to
change the 'responsible' domain renders the 'trust question' into simply
a matter of how much we trust the (owner of) the individual mail server
which is offering the mail. We are _not_ offering true end-to-end
authentication of messages, and it would be counterproductive for us to
give the illusion of doing so; there are other working groups looking at
real answers to that problem.
Thus, the odious requirements which are made of forwarders by the
mailfrom and pra scopes are unnecessary. We should look for alternative
'trust keys', rather than the domain in the RFC2821 MAIL FROM or RFC2822
headers respectively, which serve merely to identify the entity which is
responsible for the server in question.
Rand Wacker stated that he is concerned about the current direction,
because there hasn't been a lot of technical discussion about the
implications of changing the return-paths. With the note that this
applies just as much to the pra scope as the mailfrom scope, I agree
wholeheartedly with his opinion. The use of SRS and Forwarded-For: to
'take responsibility' for forwarded email seems to have been bolted on
as an afterthought, without much thought given to the implications.
I find it very difficult to see at this point any area in which the
work in the group has improved the specifications over the input
documents. We seem to have even less consensus and industry support
than we started with.
That in itself is useful information and should be considered deeply.
--
dwmw2