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

From: John Stanley <[email-masked]>
Date: Wed, 8 Dec 2004 10:01:01 -0800 (PST)

Seth Breidbart <sethb@xxxxxxxxx>:

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

Were that as far as it goes, fine. It isn't. The next step is the 
pretense. "You may not use this address".

>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.

This statement demonstrates the farce. It might not be verified because
it is impossible to verify. The ISP through which I post has no idea what
other domains I own, much less have access to email through, and in the 
domains I own, I can create addresses at whim. They have no way of 
verifying any of them. But we'll tell them they can pretend to know which 
ones are invalid. 

> There is no requirement for a general solution.

This is a draft convering the standard for news, not just your private 
implimentation.

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

Thus the pretense. If it cannot make the determination, it should do 
nothing different. 

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

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

MAY is a permissive word meaning they are permitted to do something. If 
they are not permitted to do something, then we are wrong.

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

The draft makes no such fine distinction in tenses. "Likely to be 
crossposted to" is open-ended. Even so, given the instructions we provide 
for followup agents, and observed conditions on the net, a group that HAS
BEEN crossposted to is very likely to be crossposted to again. Not just 
"likely", VERY likely.

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

"Understand the risks" is not sufficient to violate a SHOULD, as defined 
by some members here. According to RFC2119, it is.

>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.

Read USENET for awhile and see if actual practice doesn't contradict you.

>Only if _he thinks_ it's likely to happen.

The fact that it has happened makes the likelyhood of it happening unity.

>Are you likely to graduate from high school?

Since I have already, the answer is yes, I am very likely to graduate. It 
is a certainty.

>> 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.

>No, we tell sites they MAY accept them.

We ought to tell them MUST, since we also tell users they MAY use them.

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

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

What is the global harm saying they must accept the standard way of 
denoting an invalid address?

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

"Here's the standard way of doing things, but it might not be standard
where you are because we didn't actually make it part of the requirements 
for the standard." Foof.

Bruce Lilly <blilly@xxxxxxxxx>:

>But you still mixed up posting with authoring --

No, I am not. Please read what I wrote.

>an author might
>use a posting agent to prepare an article specifically for news,
>or a message prepared by one or more authors might be submitted
>by a poster to an injection agent, but one does not submit articles
>to a posting agent, at least not as that term is defined in the draft.
 
I wish I could find some significance in what you wrote there. The main 
job of the posting agent is to help post articles. They can be authored 
anywhere. See -- "posting agent", post. So "poster" ought to mean "one who 
posts", not "one who composes".

>Separate from the issue of the "poster" keyword in the
>Followup-To header field (as mentioned by Sebastian Brocks),
>which does not necessarily refer to the poster or the author(s).

If one is going to bring up the issue of "authors who write without 
intention of their material being posted to USENET", then one ought to 
recognize that those "authors" are not going to be interested in getting 
followups to those unintended articles, thus "poster" is the correct 
destination for them.

>           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.

Nobody has suggested using that terminology. Magic isn't involved. I don't
think anybody writing a new server is going to see "the submission is sent
to the moderator" and assume that he can do anything he pleases and have
it work with the existing infrastructure. On the other hand, if someone
comes up with a new way of doing things tomorrow, we ought not to be
shutting him out because his system doesn't use email.

Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx>:

>> 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".

>Yes, that was the idea, and as a consequence TLD .invalid did
>not work on this server.  And what you've written in the draft
>addresses it perfectly.

Let's see. My ISP goes anal and tells me "you must use a valid and working
email address in your postings." (Forget for the moment that THEY are
inserting a non-working address in my articles for me at the present time.
Forget for the moment that they are also outsourcing news to another
company.) Ok. We'll even assume that they have some magic method of
determining whether or not an "@peak.org" address is valid and working.  
(Forgetting for the moment that they allow the use of procmail and +
addresses, which means an address that works today might not work
tomorrow.)

So, I use an address from one of my other domains. They say "no". And yet
I'm using a valid and working address. I'm following the stated rule, and 
yet, I am not permitted to post. Why is that? Because WE told them they 
can PRETEND to know something that is patently unknowable. We told them 
THEY can determine what is a valid address (for use in news), when the 
truth is they cannot.

---

From: Seth Breidbart <[email-masked]>
Date: Sat, 25 Dec 2004 15:23:28 -0500 (EST)

> pretense. "You may not use this address".

It's not a pretense, and it's saying "I won't let you use this address
_now_."

> This statement demonstrates the farce. It might not be verified
> because it is impossible to verify.

It's certainly a reasonable policy to say "If you can't verify it to
me, then I won't let you use it."  Consider a bank; I walk in and ask
for some money from Seth Breidbart's account.  If I can verify to
their satisfaction that I am the Seth Breidbart who owns the account,
they let me have the money, else they don't.

Isn't that the policy google groups uses?

> The ISP through which I post has no idea what other domains I own,
> much less have access to email through, and in the domains I own, I
> can create addresses at whim. They have no way of verifying any of
> them.

They could send you a token and ask you to prove you received it.

> But we'll tell them they can pretend to know which 
> ones are invalid.

No, what they know is which ones they know to be valid, and which ones
they don't know to be valid.  Not knowing that something is valid is
not the same as knowing that it isn't valid.

Do you know that I am wearing shoes right now?  Do you know that I'm
not?  Would you stake your reputation on either one being true?

> Thus the pretense. If it cannot make the determination, it should do 

Nothing different from what?

It _can_ make the determination "You have not demonstrated to me that
you own the account you wish to post as."

> they are not permitted to do something, then we are wrong.

MAY means the _site_ is permitted to do something.  It implies that
the site is permitted not to do it.  The users are subject to the
policy of the site.

> BEEN crossposted to is very likely to be crossposted to again. Not just 

So you claim; but I can show examples otherwise.

> Read USENET for awhile and see if actual practice doesn't contradict you.

Cats walking across keyboards is the best explanation for a lot of
Usenet that I've seen.

(It's too hard to train monkeys to type.)

> Since I have already, the answer is yes, I am very likely to graduate. It 

Not in the language I speak.

> We ought to tell them MUST, since we also tell users they MAY use them.

Sites don't MUST accept _anything_.  Are you saying that spammers
using .invalid should get a free pass?

> denoting an invalid address?

Preventing them from doing what they want which doesn't harm anyone
else.

> where you are because we didn't actually make it part of the requirements 

"Here's the standard way of doing things.  Some sites don't allow you
to do that despite it being the standard way of doing it at sites that
do allow it."

Or would you claim that sites are required to allow crossposts to 9
newsgroups because that's the "standard way" to have a posting show up
in those 9 newsgroups?

> determining whether or not an "@peak.org" address is valid and working.  
. . .
> yet, I am not permitted to post. Why is that?

Because your interpretation of the rule they stated isn't the same as
their interpretation of it.

Seth