Text 29342, 198 rader
Skriven 2015-12-23 08:11:58 av David Drummond (3:640/305)
  Kommentar till text 29328 av mark lewis (1:3634/12.73)
Ärende: Rules of Echomail
=========================
On 23/12/2015 3:20 AM, mark lewis -> David Drummond wrote:

 ml> 21 Dec 15 10:34, you wrote to Joe Delahaye:

 DD>> How much of the content of netmail doe P4 cover?

 DD>> Chapter and verse please...

 ml> ==== Begin "mark_lewis_can't_read_policy.txt"  ====

 ml> 2.1.5  No Alteration of Routed Mail

 ml> You may not modify, other than as required for routing or other technical
 ml> purposes, any message, netmail or echomail, passing through the system
from one
 ml> FidoNet node to another.  If you are offended by the content of a message,
the
 ml> procedure described in section 2.1.7 must be used.

Does that include echomail? It doesn't state "netmail"...

 ml> [...]

 ml> 2.1.7  Not Routing Mail

 ml> You are not required to route traffic if you have not agreed to do so. 
You are
 ml> not obligated to route traffic for all if you route it for any, unless you
hold
 ml> a Network Coordinator or Hub Coordinator position.  Routing traffic
through a
 ml> node not obligated to perform routing without the permission of that node
may be
 ml> annoying behavior.  This includes unsolicited echomail.

Nothing about content. But DOES include echomail.

Rather interesting too that I am a network coordinator but do not route mail.

 ml> If you do not forward a message when you previously agreed to perform such
 ml> routing, the message must be returned to the sysop of the node at which it
 ml> entered FidoNet with an explanation of why it was not forwarded.  (It is
not
 ml> necessary to return messages which are addressed to a node which is not in
the
 ml> current nodelist.)  Intentionally stopping an in-transit message without
 ml> following this procedure constitutes annoying behavior.  In the case of a
 ml> failure to forward traffic due to a technical problem, it does not become
 ml> annoying unless it persists after being pointed out to the sysop.

Still no reference to content

 ml> [...]

 ml> 4.2  Routing Inbound Mail

 ml> It is your responsibility as Network Coordinator to coordinate the receipt
and
 ml> forwarding of host-routed inbound netmail for nodes in your network.  The
best
 ml> way to accomplish this is left to your discretion.

 ml> If a node in your network is receiving large volumes of mail you can
request
 ml> that the sysop contact the systems which are sending this mail and request
that
 ml> they not host-route it.  If the problem persists, you can request your
Regional
 ml> Coordinator to assign the node a number as an independent and drop the
system
 ml> from your network.

Nothing about the content...


 ml> Occasionally a node will make a "bombing run" (sending one message to a
great
 ml> many nodes).  If a node in another network is making bombing runs on your
nodes
 ml> and routing them through your inbound host, then you can complain to the
network
 ml> coordinator of the offending node.  (If the node is an independent,
complain
 ml> to the regional coordinator.)  Bombing runs are considered to be annoying.

 ml> Another source of routing overload is echomail.  Echomail cannot be
allowed to
 ml> degrade the ability of FidoNet to handle normal message traffic.  If a
node in
 ml> your network is routing large volumes of echomail, you can ask the sysop
to
 ml> either limit the amount of echomail or to stop routing echomail.

Nothing about content.

 ml> You are not required to forward encrypted, commercial, or illegal mail.

Without reading said in-transit messages how does one determine they they are
encrypted, commercial or illegal - and what constitutes illegal?

 ml> However, you must follow the procedures described in section 2.1.7 if you
do not
 ml> forward the mail.

I don't bother, no-one sends mail to my node to be routed.


 ml> [...]

 ml> 9  Resolution of Disputes

 ml> 9.1  General

 ml> The FidoNet judicial philosophy can be summed up in two rules:

 ml>       1) Thou shalt not excessively annoy others.

 ml>       2) Thou shalt not be too easily annoyed.

 ml> In other words, there are no hard and fast rules of conduct, but
reasonably
 ml> polite behavior is expected.  Also, in any dispute both sides are
examined, and
 ml> action could be taken against either or both parties. ("Judge not, lest ye
be judged!")

 ml> The coordinator structure has the responsibility for defining "excessively
 ml> annoying".  Like a common definition of pornography ("I can't define it,
but I
 ml> know it when I see it."), a hard and fast definition of acceptable FidoNet
 ml> behavior is not possible.  The guidelines in this policy are deliberately
vague
 ml> to provide the freedom that the coordinator structure requires to respond
to the
 ml> needs of a growing and changing community.

 ml> The first step in any dispute between sysops is for the sysops to attempt
to
 ml> communicate directly, at least by netmail, preferably by voice.  Any
complaint
 ml> made that has skipped this most basic communication step will be rejected.

 ml> Filing a formal complaint is not an action which should be taken lightly.
 ml> Investigation and response to complaints requires time which coordinators
would
 ml> prefer to spend doing more constructive activities.  Persons who persist
in
 ml> filing trivial policy complaints may find themselves on the wrong side of
an
 ml> excessively-annoying complaint.  Complaints must be accompanied with
verifiable
 ml> evidence, generally copies of messages; a simple word-of-mouth complaint
will be
 ml> dismissed out of hand.

 ml> Failure to follow the procedures herein described (in particular, by
skipping a
 ml> coordinator, or involving a coordinator not in the appeal chain) is in and
of
 ml> itself annoying behavior.

All that and nothing about content.

 ml> [...]

 ml> 9.9  Echomail

 ml> Echomail is an important and powerful force in FidoNet.  For the
 ml> purposes of Policy Disputes, echomail is simply a different flavor of
netmail, and is
 ml> therefore covered by Policy.

WOW! What does that paragraph suggest to you?

 ml> By its nature, echomail places unique technical and social demands on the
net over and above those covered by this
 ml> version of Policy.  In recognition of this, an echomail policy which
extends (and does not
 ml> contradict) general Policy, maintained by the Echomail Coordinators, and
 ml> ratified by a process similar to that of this document, is recognized by 
the
 ml> FidoNet Coordinators as a valid structure for dispute resolution on
matters pertaining to echomail.  At some future date the echomail policy
 ml> document may be merged with this one.

 ml> ==== End ====

A lot of guff but only 2 references to mail content.

Interesting that it DOES include echomail in a few places.

-- 

regards
David

--- Mozilla/5.0 (Windows NT 6.3; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
 * Origin:  (3:640/305)