Subject: Re: #1310 Approved

From: [email-masked]
Date: Fri, 4 Aug 2006 13:10:09 -0700 (PDT)

"Charles Lindsey" <chl@xxxxxxxxxxxxxxxx>:

>Yes, I mentioned the *.answers as a special case, but that is no reason to
>throw out the whole requirement.

The fact that it cannot be neither enforced nor detected is sufficient.

>.. one of those mailboxes MUST be that of the person or other entity
>claiming authority to issue this header, and moreover one of them SHOULD
>be that of the actual sender.

What stops working if "one of those mailboxes" is not that of the person
or other entity? Justify thy MUST.

>But at least require a genuine address, because ISPs will often be
>convinced by a LART relating to forged or bogus headers, even when they
>are otherwise netnews-ignorant, which sadly many are.

We've had a similar discussion involving the From header: how does the
injection agent enforce this requirement when it has no idea whether the
address belongs to the poster or not? In this case, we aren't even allowed
to limit ourselves to information we know (if anything) about the poster,
since the "person responsible for the approval" might not be the one
doing the posting.

And then just how do we tell all the injecting agents around the world
when we have a moderated newsgroup that has no "moderator" and thus
can accept ANY mailbox in an Approved header? If we say "MUST", then
we MUST have some means of telling agents when that MUST applies and
when it does not.

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 7 Aug 2006 10:17:07 GMT

>The fact that it cannot be neither enforced nor detected is sufficient.

It can be enforced mechanically by including that header in some digital
signature. Agreed this practice is not as widespread as it should be
(except for control messages) because the standards for doing it need some
tidying up (and this group looked at that years back and decided it was
future work).

But in the meantime, it can be and regularly is detected by observant
Newscops who then try to send LARTs to the perpetrator's ISP.

>or other entity? Justify thy MUST.

Nothing stops working. But that is not a requirement for using "MUST". You
are also allowed to use "MUST" for security issues, and that is the
justification here.

-- 
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: Harald Alvestrand <[email-masked]>
Date: Tue, 08 Aug 2006 05:37:15 +0200

> are also allowed to use "MUST" for security issues, and that is the
Are you referring to this (RFC 2119)?

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions).

I think you have to identify the actual harm in order to base yourself 
on that....

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 08 Aug 2006 15:50:11 +0200

>    potential for causing harm (e.g., limiting retransmisssions).

That's also a nice example for a MUST.

> I think you have to identify the actual harm in order to base yourself

Software trying to match Approved: header fields with moderated
newsgroups can't work with forged addresses (= addresses used
_without_ the permission of the mailbox owner).  That should
suffice for legal action + termination of the posting account
or similar consequences, maybe enough to justify a MUST in this
direction:  never forge addresses in an Approved header field.

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 9 Aug 2006 12:59:01 GMT

>That's also a nice example for a MUST.

No, it's a "MUST only", and we just got rid of one of those :-) .

>direction:  never forge addresses in an Approved header field.

Yes, I agree. The Internet is plagued with scams and spams of every sort.
Do these not count as "harm" and should not standards set things up so as
to make life as hard as possible for the s[cp]ammers?

What is in the Current draft regarding Approved will not of itself cure
all the ills of the Internet, but it is a step in that direction.

---

From: "Forrest J. Cavalier III" <[email-masked]>
Date: Wed, 09 Aug 2006 13:28:13 -0400

> all the ills of the Internet, but it is a step in that direction.

I wish you were joking, Charles.

We've been through debunking your attitude about this dozens of times.  An IETF 
standard is not a contract. It is not a LART.  It is merely an invitation to 
implementors to do things a certain way.

Do you really think that someone knowingly flaunting civil laws regarding
fraud is going to care about the piddling result(s) of this WG?

I see much text in the current draft that will tie the hands of the good guys 
who care in the face of the behavior of the bad guys who care not at all.  If
that is true, we will make the situation worse.

Disband.

Everytime we do an Internal Last Call, people come up with about the same
number of remaining issues.  Those familiar with software engineering will
notice that defect discovery rates that are constant indicate there are many, 
many issues remaining, and that the process that produced the product was
most likely broken.

Once again I call on the chair to justify continuing this WG when we are several 
years and several chairs passed the original charter. The current charter was to 
complete ALL documents by April 2005 or disband.  Instead there is no current 
date estimate for even completing the first document of three.