Re: draft-ietf-usefor-usepro-02

[John Stanley <stanley@xxxxxxxx>]

Seth Breidbart <sethb@xxxxxxxxx>:

>If I can't verify you as the owner of that email address, then you
>can't use my server to post with that email address.

Heh heh. You must run a very quiet server. Nobody can post through it.

>I'm not acting, I'm declining to act.

Wrong. Excluding the decision on the From header, your action would be to 
accept the article. By not accepting it, you are ACTING, and you are 
basing your action on information you do not have. 

In other words, if your decision to not accept the article is based solely 
on the lack of verification of the From address, then you are ACTING 
(rejecting the article is an action) on information that you do not have 
(the address is inavlid.)

>I'm acting based on the KNOWN FACT that you have failed to verify the
>address you're attempting to use.

In a sentence earlier above, you claimed you were not acting. And this 
"known fact" is a "bug" in the world that you cannot get around. 

>If you can't verify the address to me, then you can never use it on my
>server.

Which server would that be?

>I'm not assuming that it's possible, I'm stating that my policy
>(that's my policy, I'm not requiring that anyone else adopt it)
>requires that verification.

A verification that is impossible. By claiming that you require that 
verification, you imply that it is possible -- the same error that appears 
in the draft.

>> Wow. And Wow, you think that MOST of the articles that are posted to
>> USENET shouldn't be posted because the address cannot be verified?

>No, I never claimed that.

Yessir, you did. I'll quote from just a few lines earlier:

>>> And since they DO NOT KNOW, they should DO NOTHING SPECIAL.
>>That is, they shouldn't post the article?

Or was your "shouldn't" a typo?

>I claimed that it's an acceptable policy
>for a server to refuse to post articles if the From header can't be
>verified to the satisfaction of that server.

>It's equally acceptable for a server to allow any From address ending
>in ".invalid" to be used.

Since verifying is impossible in many if not most cases, then what you are 
actually saying is that some admins ought not to be running servers. 

And if WE tell posters they MAY use .invalid, then of course it is an
acceptable "policy" to accept it. It is not an acceptable "policy" to not
accept it, because that "policy" is really "don't conform to the
standards".

>> I think that counts as a majority over the relatively few that
>> Panix can.

>Actually Panix can verify infinitely many addresses, too.  

Hardly. But then, aleph1 is larger than aleph0 (if I am using the terms 
correctly.) There may be an infinity of Panix account they can verify, but 
there are an infinity of infinities of accounts they cannot. Still a 
majority.

>So now let's consider reality, instead.

Ok. Let's. It appears your use of Panix as an example is incorrect, since 
they have no published policy regarding what addresses may be used in the 
>From header of email.

>> That's what I said. Where did you get "the _site_ is permitted"?

>Are you claiming that the owner of a machine is required to run the
>machine the way _you_ want instead of the way _he_ wants?

It has nothing to do with what I want. It has everything to do with what 
the standards say. They say that the poster MAY use .invalid. That implies
that the server has to accept it, otherwise there would be a contradiction.

And you didn't answer the question: I was talking about a section of the 
draft that says "the poster MAY", and you told me that this means the the 
server MAY. Where did you get that nonsense?

>You may ask me to post something.  I may decline to accede to your
>request.  Those are both "MAY".

That is not what we are discussing. "MAY ASK" is very different from "MAY
USE". MAY ASK implies there is a question that you get to answer. MAY USE
means there is no question, the poster MAY USE that address.

>> A clearer statement of abdication is rarely seen here. The site will
>> do what it wants no matter what we say, so why bother saying
>> anything?

>To tell it what it ought to do so that interaction with other sites
>works properly.

A site will do what it wants no matter what we say. Why bother saying 
anything?

>> Where the fuck do we say that posters don't have to pay their bills?

>When you said that a poster MAY use ".invalid" and that the server is
>therefore REQUIRED to post the message.

Answer the question. Where does this draft say ANYTHING about paying 
bills? It doesn't. You made it up. Just like you made up the part about my 
saying that a server is REQUIRED to post a message. It would save both of 
us a lot of time if you would stop making things up and stick with what
was actually said.

>> Why do you keep making this shit up?

>It's a logical consequence of the rule that you're arguing for.

And now you've fabricated some rule that I am supposedly arguing for. Why 
do you keep doing this?

>>>If sites *have to* accept it, then they have to accept the articles
>>>where it is used, right? 
>
>> No, of course not. Don't be stupid.

>So now you agree that a site need not accept an article that has a
> From header ending in .invalid?

Stop being stupid. We are talking about a criterion for acceptance based 
on the use of .invalid here, and nothing else. I've said that a site 
cannot reject an article because the poster has used a .invalid address
because WE told the user he MAY use it. That says NOTHING AT ALL about any 
other part of the article, and you know it. You know it because I've 
already told you this. It was in the next paragraph that you even quoted.

If you really are so obtuse as to be honestly arguing about some fictional
world where I said that it MUST accept an article no matter what else the
article contained, then say so now and then be quiet. Nobody said that. I 
certainly did not. 

>Where do you think you get the right to decide on policies that sites
>must follow? 

This isn't site policy anymore. This draft tells posters they MAY do
something. I didn't write that part of the draft, so it isn't me you want
to argue with about this.

>"Articles must be syntactically valid according to these
>rules" is fine, because that affects interoperability.

Well, apparently, so does the use of .invalid. I'm not the one promoting
it. Go ask those who are why it is being pushed on users.

>> IF there were such terms presented to him for his acceptance, you might
>> have an argument. (There were no such terms in anything I've seen anyplace 
>> I've posted, so I expect such public presentation of such specific terms 
>> is rare.)

>They don't get that specific, but they all say that the ISP can do as
>it wishes.

You claimed that he agreed to specific terms that told him he must use a 
certain address when posting, and now you admit that none of them actually 
say that, they just say that the ISP can "do as it wishes". Well, that 
statement is wrong, too. The ISP is not free to do as it wishes; the ECPA 
is just one example that proves you wrong.

>> By telling the poster that he MAY do something, we've taken it out of
>> the realm of "site policy".

>I don't agree; but if you insist that's the case, we have to put it
>back.

No, we don't. We can leave that part as is, and correct the other parts 
which contradict it.

>> I'm not the one misinterpreting it. Their rule is "must use valid
>> email address in From header".

>Maybe their rule is "must use address you have verified to be valid in
>the From header."

Still trying to put words in my mouth, huh? Maybe their rule is what I 
wrote.

>If I try to login to your system without giving a password, your
>system doesn't know whether or not I'm the owner of the account.

Another nonsequitor.

>Without knowing that I'm not you, your system has no grounds for
>rejecting my login request.

Continued ad-nauseum.

>Except for people who want to post, where "verified" is the required
>case.

When verified is impossible, it cannot be the "required case". By saying 
it can be the "required case", you imply it IS always possible, and that 
is the error that needs to be rectified in the draft.

>But they may, if they so choose, reject an article for not having a
>From header that they do not know to be valid.

It is easy to check for a syntactically valid from header; thus is it
correct to imply that they can. It is impossible to verify, in most cases,
a contextually valid From header, thus it is incorrect to imply they can.
Our draft makes this implication; it needs to be fixed. To leave this 
stuff in will just result in the spread of kludges and hacks that try to 
accomplish the impossible, and users suffer for it in the long run, as 
well as developers. How much of this draft reads the way it does because
someone came up with some kludge that is now protected as "existing 
practice"? Too much. Why create more?