Re: draft-ietf-usefor-usepro-02

[Seth Breidbart <sethb@xxxxxxxxx>]

John Stanley <stanley@xxxxxxxx> wrote:
> Seth Breidbart <sethb@xxxxxxxxx>:

>>No, I'm not.  I'm stating that in some cases it is possible to verify
>>some addresses. 
>
> Nobody is debating that. The problem comes in the next step, when 
> "possible to verify" gets turned upside down and becomes "not permitted
> to use".

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.

> The same philosophy ought to hold: if you don't know, don't 
> pretend you do, and don't act based on the lack of info.

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

> "I can't verify this address, so I will act based on that lack of
> info..." is WRONG.

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

>>Or, perhaps, "now + 30 seconds" is when the posting will be made,
> Or perhaps "now + eternity" when the verification cannot be
>accomplished.

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

> You keep assuming that verification is possible, and yet you just said 
> that you were talking about a few cases where it is.

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.

>>> And since they DO NOT KNOW, they should DO NOTHING SPECIAL.
>>That is, they shouldn't post the article?
>
> You think posting an article is the "special" case?

Yes, I think a lot more strings are not posted than are posted.

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

> That's the result of "not posting unless verified" being the normal
> case.

I'm saying there is _no_ "normal case" but rather that each server can
have the policy its owner desires.

>>In most cases where the account actually belongs to the poster, it can.
>
> Wrong. Perhaps at Panix, where they pretend they can, they've convinced
> you they can. Not in the real world. The server I use cannot even verify
> the address the agents put in for me, much less anything else I might want
> to use. (If the server tried to verify the address it wouldn't accept
> anything I post, since the agents put in a bogus address BY ISP
> CONFIGURATION.) There are an infinite number of addresses it cannot
> verify.  I think that counts as a majority over the relatively few that
> Panix can.

Actually Panix can verify infinitely many addresses, too.  So now
let's consider reality, instead.

>>>>MAY means the _site_ is permitted to do something. 
>>> Not when we say the _poster_ MAY do something.
>>The poster MAY do something.  
>
> 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?

>>The site is not required to accept it.
>
> Yes, and that is the contradiction.  If the server doesn't accept
> it, then the poster MAY NOT do it. MAY isn't the same as MAY NOT.

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

>>The site will tell him what it wants, no matter what we say.
>
> 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.

>>Or do you want to say that a site which says "I won't let you post
>>that article because you didn't pay your bill" is non-compliant?
>
> 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.

> Why do you keep making this shit up?

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

>>> And I think anyone who has seen crossposting wars knows that the
>>> likelyhood of a group appearing a second time is extremely high,
>>Even to
>>alt.mycatcreatedthisnewsgroup.asdjkl32587iodjklgu8904756o2i5hgoi9834ht?
>
> Yes. Followup agents are instructed to copy (oops, I mean "take") the
> content of the previous newsgroups header as the "default" destination
> for their new article. Unless the user notices the group and removes it
> (which in practice does not happen very much, at least until the 
> crossposting is pointed out) it will be in the next article.

Or there's a Followup-To header.

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

> The From header is just one part of the message. The discussion is
> about accepting or rejecting the message based on the content of the
> From header and nothing else. If the message has some other problem,
> then it is not being rejected because the poster used .invalid in
> the From header, now is it?

Where do you think you get the right to decide on policies that sites
must follow?  "Articles must be syntactically valid according to these
rules" is fine, because that affects interoperability.

>>Telling the user that he must follow the terms of service that he
>>agreed to when he signed up for the account is not harming him, 
>
> 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.

>>I'm not saying that it isn't a good thing.  I'm saying that you (or
>>we) can't control sites' policies, and we shouldn't pretend we can.
>
> 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.

> Otherwise, the ENTIRE standard is "site policy" and we have no
> business pretending we can control anything.

We "control" whether or not something is considered well-formed and
standards-compliant.

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

>>The fact that they CAN validate some email addresses does not imply
>>that they know whenever an email address in invalid.
>
> Now you understand. So if they don't know it is invalid, they ought not
> to act as if they know it is. 

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.  So
why does it act as if it knows I'm not?

>>As I've said consistently, what they know is that the person
>>attempting to post has not validated that email address to them.
>
> And that is not the same as using an invalid address, and without
> knowing that, there are no grounds for rejecting the article.

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

> So, by rejecting the article, they are pretending to be able to know
> "invalid" when all they know is "unverified". "Unverified" is the
> normal case.

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

> they should not reject an article for having
> an invalid From header when they do not know it is invalid.

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

Seth