From: Brad Templeton (brad@templetons.com)
Date: Fri Jan 12 2001 - 20:37:43 CST
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.
>
> that information in a header rather than in the path tail. I don't think
> it's accurate to say that Injector-Info is a redundant header; it's
> correct to say that either the path tail should be used *or* Injector-Info
> should be used and specifying both is redundant.
I see no reason to support two.
And I see no need to standardize anything about the poster identification
information. As far as I am concerned this is not a string. The standard
has no need to define how to parse it -- indeed the standard
should recommend that the string be meaningful only to authorized
sysadmins of the injector, so there had better be no way to parse it!
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.
So I assert that the only token you need is a string with no meaning
defined outside the injector (and a recommendation to injector authors that
there be no way to map it back if not authorized.)
The other parameters are either all associated with putting in real
information like posting hosts, mailbox addresses etc.
The posting-logging parameter seems an odd one, why doesn't the message-id
serve? Surely any log would include the message-id?
The date parameter does provide some real data but of pretty limited
use. Generally these postings arrive at spam filters within minutes of
their being posted.
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 only rule I can see is that the injector SHOULD assure that actions
by the same user result in the same token, at least over a moderate period
of time, such as a week.