Subject: Re: draft-ietf-usefor-usepro-02

From: John Stanley <[email-masked]>
Date: Tue, 7 Dec 2004 16:13:14 -0800 (PST)

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>>If it is "undocumented", how does one know it is a tracing header?

>With difficulty. But people have always managed to discover that
>NNTP-Posting-Host was a tracing header.

Were we talking only about NNTP-Posting-Host, you might have a point. We 
are not. In fact, NNTP-Posting-Host is mentioned explicitely, so it is not
included in the "other undocumented tracing header", and thus we aren't 
talking about NNTP-Posting-Host at all. The question stands, if it is 
undocumented, how does one know it is a "tracing header" versus any
other kind? (Do we define 'tracing header' anywhere?)

> It says they "MAY" allow certain articles.

No, it says "it MAY allow articles in which headers contain unverified
email addresses, that is, addresses which are not known to be valid for
the trusted source,...". The implication is that the agent can tell which
are valid (and thus which are not.)

>But if they can
>detect the bad ones (they might even check with the DNS that the domain
>does not exist) 

You are defending a very general statement by using one specific case. 
Defend the general case. Yes, SOME addresses are easily determined to be
"not valid for the user", but that specificity does not imply a general 
solution.

>Essentially, it is encouraging you
>to take advantage of that "MAY" in this circumstance.

Then we ought to say that. But the "MUST" is important for a latter 
section of the draft to be meaningfull, so it ought to say that.

>But there is no
>MUST about it, since a site may very well say "we require all our users 
>to use valid and working email addresses".

A. Here we are again with the agent pretending it can know what addresses
are not valid for a poster. If the agent says "you are required to use
a valid address" and rejects the one being presented to it, it is saying
"this is not valid." 

B. Not if we are going to tell users that they may use .invalid.

>>So, either an injection agent doesn't deal just with "proto-articles", or
>>there needs to be a "reinjection agent".

>The first sentence of 7.2 indicates the normal situation in which an
>injecting agent is given a proto-article.

The first sentence mentions nothing about "normal". It tells us what kind
of articles the agent deals with: proto-articles.

Reinjected articles are NOT proto-articles; thus injecting agents do not 
deal with them. Thus spake paragraph one of the section dealing with 
injecting agents. 

>A couple of paragraphs further
>on it states that, "in exceptional circumstances" 

What is "exceptional" about a service that makes routine use of 
reinjection?

>Do you really want me to change the first sentence to read
>   "An Injecting Agent is responsible for taking a (proto-)article from a
>   posting (or other) agent ..."   ?

I'm sorry, but yes, I want the standard to accurate and correct. If that
means changing a paragraph that says what kind of articles an agent deals 
with, yes.

>>Here's this artificial limitation again. Why must it be via EMAIL?

>Because, for the worldwide Usenet, that is the way the protocol has been
>defined, 

We must define it this way because it is defined this way. No, we can 
change this. We do NOT have to define it that way. It is simply a fact 
that other transports can work, even if they are not currently widely 
used.

> and there is no other machinery that is guaranteed to work.

Excuse me? Nothing else can exist that can do the same thing? Sorry, but
you are patently wrong.

>>Knowing as I do the interesting interpretation of SHOULD that most folks 
>>here have, I have to ask whether this sentence is saying nothing less than 
>>that a serving agent must list all groups that it has ever heard of. I 
>>mean, a "strong recommendation that can be avoided only after careful 
>>study and consideration of all possible negative outcomes" combined with 
>>the guessing game of "group likely to be crossposted to" results in "all 
>>groups ever heard mentioned at least once".

> Not, it doesn't result in that. 

Of course it does. If an unknown newsgroup name appears in a newsgroups
header (where another, known name appears), then we already know that
there is a GOOD likelyhood (probability is ONE) that that group is likely
to be crossposted to. I.e., it WAS crossposted to at least once, so the
probability that it will be crossposted to is unity. Combined with the 
strength of that SHOULD, that means that it is as good as a MUST.

>A group that is seen to have been
>crossposted to "once" is not thereby a group that is "likely to be
>crossposted to" again.

The standard does not say 'again', it simply says "all groups likely to be 
crossposted to". And yes, Charles, crossposting done once makes it very 
likely to be done again, even if it had not been done already. But once is
enough. 

>The use of the word "likely" indicates that the
>admin of the serving agent has to exercise some judgement here,

Get real. The admin is not going to look at every report of every unknown 
group to determine if it ought to be listed in the active list. In fact, 
we tell him that he SHOULD include it in the list -- and that SHOULD is 
one of your SHOULDs. There is no judgement necessary -- it happened once,
that means it is likely to happen. Whether there is some VALUE when it 
happens is a different issue.

>So if the Injection-Date is earlier than the expiry date
>(however computed) that it implements (probably of a per group basis), 
>then it MUST drop it.

I asked once, and I expected an answer. Why is this a MUST? Expiration 
policy is the site's responsibility, not ours. 

>>However, we've just told it that it SHOULD include that group in the list 
>>of groups that it keeps. After all, if it appears in a Newsgroups header, 
>>it is quite likely that it will be crossposted to.

>No, we have not told it that. 

Quote from the draft:

   A serving agent MUST maintain a list of the newsgroups it stores in
   its news database showing the moderation status of each one (see
   6.2.1), and SHOULD include in that list all groups likely to be
   crossposted to from those groups (e.g. all other groups in the same
   hierarchy(ies)).

I see "SHOULD include" clearly stated there. Oh, wait, I remember, you 
think that a group that has ALREADY been crossposted to isn't likely to
be crossposted to. I remember as well that the Captain of the Titanic 
thought the Titanic wasn't likely to sink, until it did.

>>This paragraph is meaningless without an accompanying MUST for the 
>>injection agent. 

>Yes, you may have a point there. Would you suggest that I weaken the
>wording here, or strengthen the wording under injecting agent ("SHOULD"
>would probably suffice)? 

SHOULD does not suffice. Regular people will see the RECOMMENDATION 
synonym for SHOULD and configure their servers to reject .invalid 
addresses, even though we explicitely tell people they MAY use them.
In order for them to be able to use them, they have to work. That's
a MUST.

>AIUI, we don't want to prevent people doing that kind of munge, but we
>don't want to force injecting agents to accept it either.

We cannot have our cake and eat it, too. If we want people to use a 
standard way of munging, then we have to make it a standard way of doing 
it. It's patently silly to say "here's the authorized way of doing this, 
but it might not be authorized...".

>Now that I have removed the text regarding MIME-style parameters that used
>to be in there, I considered using "copied" instead of "taken". But since
>it is the header content rather than the whole header that gets copied, I
>concluded on balance that defining the special term "taken" would shorten
>the wording, on balance. 

There is no reason to redefine a standard english word when there is 
already a standard english word that conveys the correct meaning. This 
"taken" from nonsense is how SBC got such ridiculous penalties for the 
people who had copies of some of its documents. We ought not to further
that line of propoganda.

>>And once again, when we specify ONE ACTION for an agent, that is THE 
>>DEFAULT. We don't need to keep saying "by default", we already know
>>that the one action we specify IS THE DEFAULT.

>There are TWO actions for this agent. Either it uses the user's override
>(if any) or else it uses the "default".

Nonsense. We tell it what it must use. We do NOT tell the user what he 
uses. Since there is only ONE thing that the followup agent is allowed to 
do ("copy the content") that is the default. There is no other default.

>>1. The content of the Newsgroups-header SHOULD be copied from the content 
>>of the precursor's Followup-To-header, if present. Otherwise, it is copied
>>from the content of the precursor's Newsgroups-header.

>That is precisely the longer wording I have avoided by defining the term
>"taken".

It's two sentences of simple english. It could be one more complex
sentence.

>And "by default" is necessary because sometimes the outgoing
>Newsgroups-header is not the Followup-To (etc) one.

The "outgoing" header is what the user wants it to be. What WE tell the 
FOLLOWUP agent it SHOULD do is copy the content from one of two places. 
That's the DEFAULT and ONLY action for the followup agent. You are 
confusing the actions of the agent with the actions of the user.

>      If the References header of the precursor has grown to excessive
>      length, it MAY first be trimmed, but its first and last message
>      identifiers MUST NOT be removed.

No. It serves no purpose to trim the References header of the precursor. 
You want to trim the one in the followup. "If the resulting 
References-header is excessively long, it may be trimmed by removing 
message identifiers other than the first and the last."

>>A reading agent is free to show articles to the user in any manner the 
>>user so desires. This is not limited to character sets.

>It does not say it is limited to character sets. It says "such as
>availability of charsets". 

The point remains, the reading agent is under NO limitations on how it may 
display articles. The "such as" implies there are limits.  We have no 
business saying what it must or should do -- there are "reading 
agents" we discuss later which display NOTHING to the user, they are 
called "outgoing gateways".

>>Of course it may. It may also display icons or green flashing dots.

>Very pretty, especially at Christmas time. But not a reason for mentioning
>them :-) .

There is just as much reason for mentioning them as for mentioning 
anything else.

>>s/by email//

>No, see above.

Yes, see above.

>>Irrelevant and meaningless. Elide.

>The next sentence would be meaningless without it.

And the next paragraph I wrote already showed the next sentence is
meaningless and ought to be removed. "Keep this meaningless sentence
because otherwise the next meaningless sentence would still be
meaningless" doesn't convince me we ought to keep either one.

>How about:

>   .... The operation of the outgoing gateway
>   is subject to additional constraints due to the possibility of one or
>   more corresponding incoming gateways back from that medium to
>   Netnews, since this opens the possibility of loops.

We already cover the possibility of loops, so there is no need for this 
paragraph at all. Start the section titled "Duties of an Outgoing Gateway" 
with "In general, the following practices are recommended for all outgoing 
gateways," which is actually relevant to the section in which it appears.

>>I fail to see how a comment in the body of a message helps to prevent 
>>loops.

>There might be no other place to put it in the other medium. 

Oh, ok. Wait. I still don't see how a comment in the body of a message 
helps prevent loops.

>But the
>gateway that put it there should be able to find and recognize it if it
>ever comes back to the same gateway,

It is unlikely that an outgoing gateway is going to see an incoming 
message. However, if you meant that the same outgoing gateway is going to 
see the same message outgoing more than once, then it already has the 
mandatory message id (not in the body) to work with. A comment in the body 
of a messsage is not likely to prevent loops. Saying it does is silly.

>>>   The incoming gateway has the serious responsibility of ensuring that
>>>   all of the requirements of this standard are met by the articles that
>>>   it forms.

>>ALL? Or do you mean that it must meet the standards expected by the 
>>injecting agent that it will be using?

>It is responsible for ensuring that proper checks are done. If it can
>trust a local injecting agent to do the checks properly, then that is
>fine.

That's not what our draft says. It says that IT has the responsibility, 
not the injecting agent. And it talks about articles IT forms, not the 
final form as it would appear on the wire.

>>I guess you did mean "all". I disagree. An incoming gateway does NOT need 
>>to be an injecting and relaying agent too. It can function quite well 
>>below the injection agent. 

>How it organizes itself internally is none of our business, just so long
>as its duties and responsibilities are taken care of.

Then why are we saying that IT has the responsibility for ALL of the 
standard, and not just the parts for the function it is performing? 

>>What is the reason for this RFC2119 mandate? The injecting agent will stop 
>>a duplicate.

> Not necessarily.

7.2.2.  Procedure to be followed by Injecting Agents

   4. It MUST reject any article that does not have the proper mandatory
      headers for a proto-article (or, when reinjecting, all the
      mandatory headers other than Injection-Date), or which contains
      any header that does not have legal contents.  

It takes a bit of thought there to realize that a duplicated message id is 
an illegal content for the message id header. And most injecting agents 
do, indeed, reject duplicates.

>Even if it uses the services of an injecting agent, it
>cannot expect that agent to be aware of all the sneaky ways in which an
>already gatewayed article may come back to it from the other medium.

It does not need to care what "sneaky" ways an article gets to it. 

>>Cool. My gateway's method of determining a "valid equivalent" is by seeing
>>a Control header. But I must remove it, even though I am permitted to 
>>put it in. Which is it?

>I would suggest checking for and noting the presence of the cancel message
>_before_ removing it.

There is no cancel message before removing it. I am told I must remove it 
before I can inject it.

>Bruce Lilly <blilly@xxxxxxxxx> writes:
>>or automatic process).  The "poster" corresponds to
>>"sender", not to "author".

>Yes, that is more or less what we decided. And as a consequence you will
>now find the words "author or sender" in 7.6.

Yes, but the problem appears in the definitions, where it clearly says 
that the POSTER is the one COMPOSING the message. That's not true.

---

From: Seth Breidbart <[email-masked]>
Date: Tue, 7 Dec 2004 19:56:34 -0500 (EST)

> are valid (and thus which are not.)

No, the implication is that the agent can _sometimes_ tell that an
email address is (known to be) valid, and sometimes cannot tell.

An unverified email address is one that has not been verified.  It
might not be verified because it's bogus, or it might not be verified
because nobody got around to verifying it.

> You are defending a very general statement by using one specific
> case.  Defend the general case. Yes, SOME addresses are easily
> determined to be "not valid for the user", but that specificity does
> not imply a general solution.

There is no requirement for a general solution.  "MUST post if the
email address is valid, MUST NOT post if the email address is not
valid" requires a general solution.

> a valid address" and rejects the one being presented to it, it is saying

No, it is saying "I do not know this to be valid so _I_ won't let you
use it."

> B. Not if we are going to tell users that they may use .invalid.

"MAY" means it's a matter of local policy.

> that other transports can work, even if they are not currently widely 

That's correct.

> Excuse me? Nothing else can exist that can do the same thing? Sorry, but

Besides, email isn't guaranteed to work, either.  What is important is
that the article be provided to the moderator for a decision.  The
means of providing it is irrelevant.

> Of course it does. If an unknown newsgroup name appears in a
> newsgroups header (where another, known name appears), then we
> already know that there is a GOOD likelyhood (probability is ONE)
> that that group is likely to be crossposted to. I.e., it WAS
> crossposted to at least once, so the probability that it will be
> crossposted to is unity.

The probability that it _will have been_ crossposted to is unity.  The
probability that it _will be_ crossposted to is less than unity.

> Combined with the strength of that SHOULD, that means that it is as
> good as a MUST.

I disagree.  A site might well understand the risks behind violating
that SHOULD and choose to do so.

>>A group that is seen to have been crossposted to "once" is not
>>thereby a group that is "likely to be crossposted to" again.
>
> The standard does not say 'again', it simply says "all groups likely
> to be crossposted to".

Which implies in the future, not the past.  (Ask someone divorced "Are
you likely to be married to <your ex-spouse>?" and see if the
likelihood is closer to 0 or 1.)

> And yes, Charles, crossposting done once makes it very 
> likely to be done again, even if it had not been done already.

No, it doesn't.  Crossposting to a group whose name was clearly
generated by a cat walking on the keyboard is not likely to be
repeated.

> group to determine if it ought to be listed in the active list.

So he'll have code to do that.

> In fact, we tell him that he SHOULD include it in the list -- and
> that SHOULD is one of your SHOULDs.

Only if _he thinks_ it's likely to happen.

> There is no judgement necessary -- it happened once,
> that means it is likely to happen.

Are you likely to graduate from high school?

>>(however computed) that it implements (probably of a per group basis), 

That seems backwards; I keep posts for a week, so expiration is
today+7.  Injection had better be earlier than that.

Or do you mean that if the expiry date based on Injection-Date is
before now, I MUST drop it?  Expiry is often not based on
Injection-Date.

> policy is the site's responsibility, not ours. 

That, too.  There's no global harm if a post expires too soon, or
never.

> addresses, even though we explicitely tell people they MAY use them.

No, we tell sites they MAY accept them.

> In order for them to be able to use them, they have to work. That's

What is the global harm if a site requires posts to have verifiable
local addresses?

> but it might not be authorized...".

"Here's the authorized way of doing this.  Sites will adopt their own
policies, which may be weaker or stronger."

Seth

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 7 Dec 2004 21:21:58 -0500

On Tue December 7 2004 19:56, Seth Breidbart wrote:
> > No, it says "it MAY allow articles in which [...]

> No, the implication is that the agent can _sometimes_ tell [...]

> "MAY" means it's a matter of local policy.

The entire mess being discussed is policy.  The draft is supposed
to be about protocol. Policy doesn't belong in it.

> means of providing it is irrelevant.

Perhaps.  There are many issues involved with moderation that
are inadequately specified.  One approach would be to simply
defer dealing with moderation in a separate document.  But if
we are going to deal with it in this document, then we ought
to do so adequately -- and simply waving hands and (effectively)
saying "the message gets to the moderator via magic" isn't
adequate.

The following text in the previous message pertained to
some silliness which, when tracked back a half-dozen earlier
messages turned out to have been related to just one such
moderation issue; the assumption implicit in the text that
there is exactly one "moderation status" for every newsgroup,
uniform across all sites.  We had that discussion a long
time ago, and I recall that the conclusion was that
moderation status was site policy, not something that
could be characterized as *the* moderation status.  If it's
a policy issue it doesn't belong in a protocol document.
If we can agree on a clear and complete description of how
moderation and moderation-related issues work, we should
probably defer the matter to a separate document.  A lot
of pointless bickering about cats walking on keyboards, the
probability of this and that, etc. will only delay getting our
Standards Track documents finished.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 9 Dec 2004 15:07:02 GMT

>other kind? (Do we define 'tracing header' anywhere?)

The concept of "tracing header" is well known (it is described in RFC 2822
amongst other places). If an implementor of an injecting agent is aware of
some tracing header not explicitly mentioned in our draft, then it is
entirely reasonable for him to remove it, as stated.

>are valid (and thus which are not.)

No, it implies no such thing. Agents may or may not be able to detect
validity/invalidity of various classes of address, as Seth has pointed
out. The "MAY" permits them to make use of such information as they may
have available. Consequently, people who use invalid addresses may well
find their articles rejected. Or not.

>What is "exceptional" about a service that makes routine use of 

The fact that very few services do that, and then only on a very limited
class of articles.

>means changing a paragraph that says what kind of articles an agent deals 

OK, I have made that change, even though I don't think it was necessary.

>Excuse me? Nothing else can exist that can do the same thing? Sorry, but

No, there is nothing else that will nearly always work on Usenet as it
presently exists. A site that is smart enough to know that this group in
the Mozambiquean hierarchy is moderated, but has no other knowledge of
that hierarchy, will just email the article to moderators.isc.org, with a
very good chance that it will work. There is absolutely no other mechanism
that it can even try to use.

Other mechanisms may be used in small cooperating subnets, but until they
become commonplace we have no way of standardizing them. Cooperating
subnets, by definition, use mechanisms that are outside of our standard.

>group to determine if it ought to be listed in the active list.

If he is getting 6 crossposts a day to the Mozambiquean hierarchy, then he
probably ought to be doing something about it. If he is getting one every
6 months, then there is little point in bothering.

In the event that he does inject it without an Approved header, no great
harm arises because it will get discarded as soon as it hits a relaying or
serving agent anywhere near Mozambique (where they are likely to care
about such things). And if it continues to propagate around some sites in
China, then who cares?

The fact is that it is impossible to prevent this sort of thing from
happening, hence there is no point pretending in our draft that we can.

>policy is the site's responsibility, not ours. 

This is nothing to do with controlling the expiration dates of sites. It
is a matter of preventing loops, for which purpose that MUST is essential.

Say the Injection-Date was 4 days ago. Suppose we expire everything (i.e.
remove all trace from our history file) after 3 days. Then it would be
folly to accept this article now. No problem it it had arrived yesterday,
at which point we would likely have seen that we had already got it.

>but it might not be authorized...".

Whilst this is a legitimate topic for discussion (and indeed we are
discussing it), both Frank and Seth seem to he saying that it is about
right as I currently have it. I.e. we encourage people to use ".invalid",
but we make no guarantee that even that will always work.

I think we first need to decide whether that is the attitude we want to
take, and then adjust the wording to fit what we decide. I agree that the
way it is currently worded seems to be pulling two ways at once and will
probably need to be changed. But I need guidance as to which direction to
change it in.

>already a standard english word that conveys the correct meaning.

"Take" is also a standard english word, and conveys the intended meaning
in this case. I do not see your problem with it. Does anyone else?

>do ("copy the content") that is the default. There is no other default.

There are TWO things the followup agent can do. One is to accept (without
demur) what the user types in. The other (if the user takes no action) is
to use the specified default (which is precisely why we call it the
"default"). But note that there is another ONE thing that it cannot (or
SHOULD NOT) do, and that is to use anything else as the default (such as
"Re[2]:").

>No. It serves no purpose to trim the References header of the precursor.

I don't think anybody is going to take it that literally. However ...
 
>message identifiers other than the first and the last."

But OK, I will buy that, except that it has to be the "last two" (i.e. you
MUST keep the last one from the precursor).

>display articles. The "such as" implies there are limits.

The only limitations are those imposed by the lack of appropriate
facilities in the reading agent. The whole point of the wording is to
indicate that the poster cannot assume that every reading agent will be
able to make sense of everything, however bizarre, that he might choose to
put in the article.

>  We have no 

Indeed, and that is covered by the wording "displays them (or processes
them in some other manner)". That covers gatewaying, printing, converting
into Braille, and whatever else.

>meaningless" doesn't convince me we ought to keep either one.

Neither sentence is meaningless. Does either of them say anything that is
untrue?					

>paragraph at all.

There are various ways in which loops can arise. It is necessary to draw
attention to them.

>message.

On the contrary, that is just the kind of loop we are trying to catch. If
the article is gatewayed to the "other medium" and there exists some other
gateway elsewhere that puts it back into Netnews, then the flooding
algorithm is very likely indeed to bring it back to the first gateway.

> However, if you meant that the same outgoing gateway is going to 
>mandatory message id (not in the body) to work with.

There might not be such a thing as a message id in the other medium. There
might not even be a distinction between headers and body in the other
medium.

> A comment in the body 

No. If the gateway to the "other medium" (which presumably understands the
rules for contructing messages in the other medium) can manage to insert
some distinct identifier into whatever passes for a body in the other
medium, then it is quite capable (and indeed it is the only agent in the
whole world with that capability) of recognizing the identifier that it
itself placed there, should it ever come back again. Of course, it would
have been much better to put the identifier into the "headers" of the
other medium if that were possible, but if it were not then it has to go
in the "body".

>final form as it would appear on the wire.

It is nowhere stated that a separate injecting agent is involved in an
incoming gateway. If there is, then it can be relied on to do the checks.
If there is not, then the gateway has to shoulder the responsibilities of
an injecting agent. That is exactly what it says, so what is your problem?

>standard, and not just the parts for the function it is performing? 

Because we do not state which parts for the function it is performing. It
can do the whole thing itself, or it can subcontract parts of it to other
agents available to it. The internal details are none of our business,
just so long as it gets done.

>>>What is the reason for this RFC2119 mandate? The injecting agent will stop 

Injecting agents are not normally responsible for stopping duplicates;
that is usually the function of a serving agent. But in gatewaying
situations the article may have got so mangled that no other agent would
be able to stop them.

>do, indeed, reject duplicates.

How?

And if it is the same message come round again, then it is not even
illegal to have the same message id.

>There is no cancel message before removing it. I am told I must remove it 

Eh? If an article with a Supersedes header arrives at an outgoing gateway,
then it had better notice the presence of Supersedes (so that it can
generate whatever passes for a cancel message in the other medium) BEFORE
it removes that header (for the purpose of passing the rest of the headers
and the body to the other medium). If it tries to do things in the wrong
order, then it will certainly fail to do a proper job.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      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

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 9 Dec 2004 15:19:58 GMT

>to be about protocol. Policy doesn't belong in it.

The word "MAY", as defined in RFC 2119, is nearly always used to deal with
matters of policy. Protocols can and do contain optional features.

---

From: Thorfinn <[email-masked]>
Date: Fri, 10 Dec 2004 09:23:24 +1100

On Thu 09 Dec 2004 at 03:07:02PM +0000, in <[email-masked]>,
> In <[email-masked]> John Stanley <[email-masked]> writes:
[snippage]
> find their articles rejected. Or not.

I *think* that John's point is that users with otherwise valid email
addresses may will find their articles rejected also by some sites
(those that choose to allow only addresses *they* know to be valid).

I also think that nobody else cares that this is the case, and in fact,
that everyone expects this to be the case on some sites, and that is
fine by them.

There is plenty of choice available of injecting points for users, even
if they only have one ISP they can connect to, all with different
policies.

Later,

  Thorf

-- 
<a href="http://tertius.net.au/~thorfinn/">[email-masked]</a>
"Sorry I'm late, I was held up by that fuckwit Harradine."
    -- unnamed Liberal MP, to morgan(vurt.net

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 10 Dec 2004 00:49:24 +0100

Charles Lindsey wrote:

> The word "MAY", as defined in RFC 2119, is nearly always used
> to deal with matters of policy. Protocols can and do contain
> optional features.

RfC 2476 taught me to read "maybe not" whenever I see a MAY in
an RfC, the effects are sometimes devastating. :-(  Bye, Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 10 Dec 2004 14:03:09 GMT

>that everyone expects this to be the case on some sites, and that is

If that is the general view here, then my present text can more or less
stand. But John has a slight point that, if we are encouraging people to
use ".invalid" then we should not write things in such a way as to suggest
that their good efforts might nevertheless lead to rejection. It's a
matter of giving the right "feel", without trying to tie things down with
too many MUSTs.

So how about, for injecting agents:

   2. It SHOULD verify that the article is from a trusted source, and
      MAY reject articles in which headers contain unverified email
      addresses, that is, addresses which are not known to be valid for
      the trusted source, though it would be perverse to reject
      intentionally unverifiable addresses such as those ending in
      ".invalid" (7.5).

Where the relevant wording in 7.5 is:

   Contrary to [RFC 2822], which states that the mailbox(es) in the From
   header is that of the poster(s), a poster who does not, for whatever
   reason, wish to use his own mailbox MAY use any mailbox ending in the
   top level domain ".invalid" [RFC 2606].