From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Mon Jan 15 2001 - 04:29:00 CST
In <20010112183743.E2220@main.templetons.com> Brad Templeton <brad@templetons.com> writes:
>On Fri, Jan 12, 2001 at 03:21:31PM -0800, Russ Allbery wrote:
>> Brad Templeton <brad@templetons.com> writes:
>>
>> > >> NOTE: The use of ".invalid" is to provide an aid to mail systems so
>> > >> that addresses deliberately intended to be malformed can be
>> > >> identified and delivery aborted. User agents MUST identify such
>> > >> addresses and require the user to alter the address when attempting a
>> > >> personal email reply. Injecting agents that have authentication
>> > >> information MAY choose to enforce the From-content based on the
>> > >> poster's authenticated identity.
>>
>> > There is an interoperability problem if a user puts an email into a
>> > message which is unreplyable and does not indicate it.
>>
>> That's not the situation we're currently discussing (see above). This
>> portion of the text has nothing to do with that case; it's dealing with
>> the behavior of a news reading client that also can send mail when
>> confronted with an e-mail address that ends in .invalid.
>Understood. I thought I saw suggestion that it not be a SHOULD or better
>on the generating end.
I think there are some cross purposes here. A user agent is capable of
doing all sorts of stupid things, and we say in various places that they
Ought Not to. The question is what happens when they ignore that advice
(you can't stop users being stupid).
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?
>I am going from the draft on landfield.com which says it is dated recently.
>It says simply that an admin "MAY" use interpretations interpretable
>only by himself. This should be "recommended" and the use of directly
>identifiable information deprecated.
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.
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).
>Can you tell me which header in the injector-info is important to
>standardize given the assumption that it should not be possible for
>outsiders to trace back to the real user based on the header?
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.
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Email: chl@clw.cs.man.ac.uk Web: http://www.cs.man.ac.uk/~chl Voice/Fax: +44 161 436 6131 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5