On 2019 Apr 21 08:26:58, you wrote to me:
Further more, mark is one of the people in Z1, that for decades have
insisted that P4 does *not* cover echomail.
no, i did not... i even posted the proof to you several years ago...
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:
echomail does not apply to that rule...
You can repeat that lie as many times as you like, it will still
not
become
true -- or even make any sense.
you can continue to be stupid all you like... it still won't change anything...
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...
"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."
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)