From: Brad Templeton (brad@templetons.com)
Date: Mon Jan 15 2001 - 12:29:48 CST
On Mon, Jan 15, 2001 at 10:29:00AM +0000, Charles Lindsey wrote:
> In <20010112183743.E2220@main.templetons.com> Brad Templeton <brad@templetons.com> writes:
>
>
> So in this case the question should be "what happens when a user attempts
> to mail to a non-existent address, particularly one ending in .invalid".
> That should really be a matter for the mail transport agent (sendmail and
> friends), and indeed such agents SHOULD/MUST refuse such messages. That is
> not really a matter for our standard, though we could reasonably point out
> that the MTA would likely take such action. Do you want me to propose some
> wording along that line?
We may be talking at cross purposes. You are correct that what the mailer
does is up to the mailer.
The only "should/must" required is the requirement that people not put
in deliberately unmailable addresses and not mark them as such, since
this breaks the replying function. The replying function is part of
the USENET system, even if the medium it calls upon is the independent
e-mail system.
There are no requirements that the user's client warn him, but it is a
good recommendation.
>
>
> I don't see why. By and large Usenet users much prefer to be able to tell
> exactly where an article has come from, for all sorts of killfiling and
> spam-fighting reasons. The NNTP-Posting-Host is much used for this
> purpose, and people seem to like it.
The reason why is that one can attain the same result -- in fact a better
result -- through the use of a token that doesn't track the user except
to the authorized admins.
My identity, as a poster, if I wish to use a pseudonym, is none of your
business, as long as you can track spammers.
At least USENET-wide. I have no problem with particular newsgroups
developing policies about the use of pseudonyms, but you are proposing
actions that affect it net wide.
Or rather than proposing, you want to ratify a badly chosen header which
did indeed destroy
>
> There IS a case for a few users to seek anonymity, and for that purpose
> there exist a few specialist sites (anonymising servers) that cater for
> them. Such sites should go to a lot of trouble to use secret tokens and
> the like, but they also need to take precautions to ensure they do not get
> used by spammers (otherwise they will be blacklisted themselves). But this
> is just part of the normal principle that injectors have to take
> responsibility for their users (which we clearly set out in chapter 8).
>
> >The posting-logging parameter seems an odd one, why doesn't the message-id
> >serve? Surely any log would include the message-id?
>
> It might, but message-ids are usually generated by the posting agent. An
> injecting site might find it easier to use a token it had generated itself
> (it would be easier to index from).
Sorry, I don't get this. You're suggesting it's some sort of difficult
problem to index from an arbitrary string? That might have been true in
Fortran in the 1960s, but it's not today. The number of messages posted
from a single injector is very small. Grep would find you the record
for a given message-id faster than you would notice on the typical
posting log of any injector outside of AOLs.
>
>
> The injector-info provides a selection of tools, with a parseable syntax
> that can be used for various purposes. The injector site chooses which are
> convenient for its purposes. It is suggested that it SHOULD use the
> header in a sensible way (we would need to look at the wording carefully).
> But I absolutely deny the "assumption" that you take to be given.
It is my view, and the EFF's view, that this assumption should be given.
Systems should be designed to protect the privacy of their users from the
start, and that privacy should only be removed when there is a very
compelling reason to do so, and no less invading means to attain the goal.
In this case, the value of spam tracking is real, but it can be done using
a token that doesn't let the public track a posting to a real person, only
the local admins.
In fact, one might argue that there is a more compelling argument to stop
the spam at its source, and not only have the token, but simply say
that injectors SHOULD throttle the posting volume of any given user or
network of users.
While that is not trivial, it is not hard, and would do a lot to
elminate spam, much more than mere cancelbots do. Why not go to the
real problem? Why remove the privacy from USENET when there are better
ways?