From: Thorfinn (thorfinn@tertius.net.au)
Date: Wed Feb 20 2002 - 16:54:44 CST
On Wed 20 Feb 2002 at 02:41:18PM +0000, in <Gru64u.M4H@clw.cs.man.ac.uk>,
Charles Lindsey <chl@clw.cs.man.ac.uk> wrote:
> In <Pine.LNX.3.91.1020218153549.16780A-100000@darkstar.prodigy.com> Bill Davidsen <davidsen@prodigy.com> writes:
> >I think the core of this scholarly discussion is that some of us
> >believe that an injector should insert a spamable address when, and only
> >when, hell freezes over. Any other action is going to compromise the
> >user's privacy, and since we have other headers for accountability in
> >case of abuse, the sender header should be more clearly defined:
> I agree that the Injector-Info header is the proper header to use for
> accountability issues. There are various ways of using it, and if the user
> does not like the way his injector uses it, he can vote with his feet. I
> do not accept John Stanley's argument that the user does not know in
> advance what the injector will do. If you sign up with an ISP to provide
> you with a posting service, then you get the service that ISP chooses to
> provide. Tough!
Yeps. And not so tough... the ISP market isn't a total monopoly
anywhere that I'm particularly aware of (except maybe .sg and .cn -
presumably via government fiat - but surely they have much more invasive
problems to worry about before they get to caring about Sender:). It's
not even close.
> But the situation we are faced with is that much current practice uses
> the Sender header for accountability purposes. Do we outlaw that?
I don't think we should outlaw it.
> >The Sender header is used to indicate the person or software which has
> >provided the article on behalf of the originator. It is set by the
> >submitter and MUST NOT by provided or modified by the injector. An
> >injector which determines that the From and/or Sender header is incorrect
> >SHOULD reject the article.
> OK, that is one clear position we could take. But I also hear Russ arguing
> for the current practice (though would Injector-Info with a suitable
> option not do as well for his INN problem?). So my inclination, in the
> face of conflicting views, is to leave it as in the recently posted
> snapshot. But if I hear further cogent views ...
I agree with pretty much everything Russ has said on the subject.
The only thing I have to add is that if we go the *other* route (ie,
disallow addition of Sender), then the existing practice should only be
"deprecated" or perhaps SHOULD NOT, and I definitely don't agree with it
being MUST NOT.
> >If you want to put in a warning that some injectors historically have
> >modified Sender, that would be a valuable warning to the user.
> Well yes, that warning is there under the From header, and I think it has
> to remain.
Definitely. Also, there is a difference between modifying Sender: and
*adding Sender: when there is none*.
Disallowing modification of Sender: (ie, if there is one, you reject the
article, or you accept it, don't mess with it either way) is not the
same as disallowing adding of Sender: if there isn't one.
I personally don't think either should be disallowed, but there is
definitely a middle ground to be had, and I'm entirely willing to accept
anything up to Modification and Adding is SHOULD NOT, but don't like the
idea of them being MUST NOTs.
Later,
Thorf
--
<a href="http://tertius.net.au/~thorfinn">thorfinn@tertius.net.au</a>
Blue fish, Red fish,
Goth fish, Dead fish.
-- Madi <madi@vurt.net> in aus.culture.gothic