From: John Stanley (stanley@peak.org)
Date: Thu Feb 21 2002 - 13:28:16 CST
Charles Lindsey (chl@clw.cs.man.ac.uk):
> 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.
A pair of unrelated statements. That you signed up with an ISP for network
service does not imply in any way that they told you about every
redefinition of the RFCs they have chosen to implement; not even that they
will put your spammable address in what you post. I've NEVER seen any ISP
I've dealt with tell me in advance how they've configured their news
servers. They assume you don't know what they are doing, that you don't
care to know, and you will take what they give you. Their whole business
model is built on "networking for dummies". And they assume that they can
change whatever they want without telling you, so even if you know today
that they don't do something, tomorrow they can start and you won't know
about it until too late.
The fact remains that the poster may make every effort to hide a spammable
address and the injector can and will insert one for him without him
knowing in advance and without bothering to tell him that it was being
done. That is UNACCEPTABLE behaviour and merits a MUST NOT. Period. If the
user agrees that he must use a spammable address at an ISP, then the ISP
should REJECT the article if it does not contain one, not be allowed to
modify the identification headers so it does contain one.
>But the situation we are faced with is that much current practice uses
>the Sender header for accountability purposes. Do we outlaw that?
Since the Sender header is not defined for accountability purposes, yes,
we can outlaw its use for that, since there are other headers defined for
this use.
>OK, that is one clear position we could take. But I also hear Russ arguing
>for the current practice
No, I hear Russ arguing as if the poster is made aware in advance of
current practice, which there is no reason to believe. Maybe Russ tells
every user of his news servers in advance when he makes any modification
to the system, but I've never seen a news admin at any of the places I
read news do that. In fact, they've gone as far as to make changes that
completely break the news reader I was using without saying anything,
until I send email saying "hey, this doesn't work anymore, why not?" And
that's been at more than one site.
And I don't hear Russ arguing that the injector has to accept the article
with headers it doesn't like just so it can fix them up for posting. I
don't hear him saying that an injector cannot reject an article if it does
not like the identification header.
>>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, ...
That's patently not true. The From header "warning" says nothing about
historical actions, it clearly states that injectors MAY insert a sender
header which discloses some valid address of the poster. It is a warning
of future action. And it is an explicit statement that injectors have full
permission to do this. To claim that is only a warning about what has been
done in the past, as Bill wrote, is disengenuous at best.
Thorfinn (thorfinn@tertius.net.au):
> Yeps. And not so tough... the ISP market isn't a total monopoly ...
So it is fine by you if someone who has had to abandon one service because
his mailbox has become a useless spam-filled cesspool changes ISPs, takes
great pains NOT to post using his new address, which he is giving ONLY to
people he trusts, and then the ISP makes his new mailbox a useless
spam-filled cesspool by putting his new, spammable address into an article
he posts without his knowledge?
So the advice that people are given to post using "throw away" accounts if
they want to avoid spam is what, just a lot of bullshit? Well, post with
those accounts as your email address, but the injector can insert a
spammable address that will cost you money and time for you if it wants
to... how nice.
Yep, I see this group is spammer friendly. Gotta help the spammers all we
can, don't we? Screw the user.
>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 do not prohibit it, it will be done, and it is not correct
behaviour. If an injector does not like the headers on an article, it
should reject it, not fix it up based on guesses it makes.
>Definitely. Also, there is a difference between modifying Sender: and
>*adding Sender: when there is none*.
Of course there is a difference, but both are incorrect behaviour. Both
require the injector to guess at the identity of the poster. "My crystal
ball tells me that the From header does not contain the email address for
the poster, so I'll put something he didn't want exposed in for him and
not bother telling him I'm doing it ..."
>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.
Statement of the obvious. But both should still be prohibited.
>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.
Then we'll count you firmly in the spammer-friendly camp, shall we?
The summary is this. The Injector cannot determine that the From header
does not contain what the standard defines it to contain, thus it cannot
know when it should insert a Sender header. Only by changing the
definition of the From content to be "what the injector thinks is right"
instead of "the electronic address of the poster" can the injector claim
that it should insert a Sender header. Injectors should use the standard
definition or should be shut down as broken. They should be prohibited
from making these redefinitions and guesses. I have yet to see any cogent
argument for why they should not be.