Text 11141, 203 rader
Skriven 2019-04-21 06:41:26 av mark lewis (1:3634/12.73)
Kommentar till text 11135 av Björn Felten (2:203/2)
Ärende: The mystery of mark's empty lines
=========================================
On 2019 Apr 21 08:26:58, you wrote to me:
BF>>> Further more, mark is one of the people in Z1, that for decades have
BF>>> insisted that P4 does *not* cover echomail.
ml>> no, i did not... i even posted the proof to you several years ago...
BF> Of that I have no recollection.
of course you don't...
==== Begin "bjorn_can't_read_policy.txt" ====
Area : [ADM] FidoNet Sysops
Date : Fri 2015 May 29, 12:40
From : mark lewis 1:3634/12.73
To : Björn Felten
Subj : The NAB twisted take on P4
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
29 May 15 11:38, you wrote to me:
ml>> echomail does not apply to that rule...
BF> You can repeat that lie as many times as you like, it will still
BF> not
become
BF> true -- or even make any sense.
you can continue to be stupid all you like... it still won't change anything...
BF> AFAIK P4 9.9 has not been revoked yet, except by a select few.
mostly those in Z2 from what i've seen and understood for the last two
decades... especially those that pull only one or two specific parts out to try
to make their case instead of taking everything all together as intended...
BF> "Echomail is an important and powerful force in FidoNet. For
BF> the purposes of Policy Disputes, echomail is simply a different
BF> flavor of netmail, and is therefore covered by Policy."
you forgot the rest... *ALL* the rest... it must /all/ be taken together... not
piecemeal as you so dearly love to do...
===== snip =====
2.1.5 No Alteration of Routed Mail
You may not modify, other than as required for routing or other technical
purposes, any message, netmail or echomail, passing through the system from one
FidoNet node to another. If you are offended by the content of a message, the
procedure described in section 2.1.7 must be used.
[...]
2.1.7 Not Routing Mail
You are not required to route traffic if you have not agreed to do so. You are
not obligated to route traffic for all if you route it for any, unless you hold
a Network Coordinator or Hub Coordinator position. Routing traffic through a
node not obligated to perform routing without the permission of that node may
be
annoying behavior. This includes unsolicited echomail.
If you do not forward a message when you previously agreed to perform such
routing, the message must be returned to the sysop of the node at which it
entered FidoNet with an explanation of why it was not forwarded. (It is not
necessary to return messages which are addressed to a node which is not in the
current nodelist.) Intentionally stopping an in-transit message without
following this procedure constitutes annoying behavior. In the case of a
failure to forward traffic due to a technical problem, it does not become
annoying unless it persists after being pointed out to the sysop.
[...]
4.2 Routing Inbound Mail
It is your responsibility as Network Coordinator to coordinate the receipt and
forwarding of host-routed inbound netmail for nodes in your network. The best
way to accomplish this is left to your discretion.
If a node in your network is receiving large volumes of mail you can request
that the sysop contact the systems which are sending this mail and request that
they not host-route it. If the problem persists, you can request your Regional
Coordinator to assign the node a number as an independent and drop the system
from your network.
Occasionally a node will make a "bombing run" (sending one message to a great
many nodes). If a node in another network is making bombing runs on your nodes
and routing them through your inbound host, then you can complain to the
network
coordinator of the offending node. (If the node is an indepen- dent, complain
to the regional coordinator.) Bombing runs are considered to be annoying.
Another source of routing overload is echomail. Echomail cannot be allowed to
degrade the ability of FidoNet to handle normal message traffic. If a node in
your network is routing large volumes of echomail, you can ask the sysop to
either limit the amount of echomail or to stop routing echomail.
You are not required to forward encrypted, commercial, or illegal mail.
However,
you must follow the procedures described in section 2.1.7 if you do not forward
the mail.
[...]
9 Resolution of Disputes
9.1 General
The FidoNet judicial philosophy can be summed up in two rules:
1) Thou shalt not excessively annoy others.
2) Thou shalt not be too easily annoyed.
In other words, there are no hard and fast rules of conduct, but reasonably
polite behavior is expected. Also, in any dispute both sides are examined, and
action could be taken against either or both parties. ("Judge not, lest ye be
judged!")
The coordinator structure has the responsibility for defining "excessively
annoying". Like a common definition of pornography ("I can't define it, but I
know it when I see it."), a hard and fast definition of acceptable FidoNet
behavior is not possible. The guidelines in this policy are deliberately vague
to provide the freedom that the coordinator structure requires to respond to
the
needs of a growing and changing community.
The first step in any dispute between sysops is for the sysops to attempt to
communicate directly, at least by netmail, preferably by voice. Any complaint
made that has skipped this most basic communication step will be rejected.
Filing a formal complaint is not an action which should be taken lightly.
Investigation and response to complaints requires time which coordinators would
prefer to spend doing more constructive activities. Persons who persist in
filing trivial policy complaints may find themselves on the wrong side of an
excessively-annoying complaint. Complaints must be accompanied with verifiable
evidence, generally copies of messages; a simple word-of-mouth complaint will
be
dismissed out of hand.
Failure to follow the procedures herein described (in particular, by skipping a
coordinator, or involving a coordinator not in the appeal chain) is in and of
itself annoying behavior.
[...]
9.9 Echomail
Echomail is an important and powerful force in FidoNet. For the purposes of
Policy Disputes, echomail is simply a different flavor of netmail, and is
therefore covered by Policy. By its nature, echomail places unique technical
and social demands on the net over and above those covered by this version of
Policy. In recognition of this, an echomail policy which extends (and does not
contradict) general Policy, maintained by the Echomail Coordinators, and
ratified by a process similar to that of this document, is recognized by the
FidoNet Coordinators as a valid structure for dispute resolution on matters
pertaining to echomail. At some future date the echomail policy document may
be
merged with this one.
===== snip =====
so now, with /all/ of that said, are you saying that a PC can be filed based on
netmail content? if so, then you might have a leg to stand on with regard to
the
content of echomail...
echomail being covered by policy is mainly about transmission... like netmail
being routed to a lot of systems, if you continually send echomail areas to
systems that do not want them or care to distribute them, that falls into the
same boat as netmail... the /contents/ of the messages are *not* covered and
never have been... anyone finding the content of someone's posts as annoying
can
easily follow section 2.1.7, twit the sender or simply hit their [NEXT] key...
you, yourself, have told folks to use the next key numerous times... especially
when it concerned postings by you or your cadre...
one should also fall back to the two basic tenets of fidonet... see section 9.1
above above and remember "Judge not, lest ye be judged!" as noted in the second
paragraph of 9.1...
perhaps those being annoyed by the postings are being too easliy annoyed... as
noted above, "i know it when i see it" doesn't count...
)\/(ark
... rio_dprintk (RIO_DEBUG_ROUTE, "LIES! DAMN LIES! %d LIES!\n",Lies);
-!-
! Origin: (1:3634/12.73)
==== End "bjorn_can't_read_policy.txt" ====
)\/(ark
Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it
wrong...
... Plan to be spontaneous tomorrow.
---
* Origin: (1:3634/12.73)
|