the one that says

blah blah blah. FTS number please, after all this is where we are.

who is this "we" you speak of? are both of you that lazy? ;)

We here, that are interested in the topic of the FTSC_PUBLIC echo. And it seems like we are far more than two. DUH

So, you don't have an FTS number available to support your "spec" claim? Maybe you are not FTSC material after all?



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

Wilfred van Velzen -> mark lewis skrev 2019-04-19 22:04:

Inconclusive. We need more data... ;)

Indeed.

And I must thank you Wilfred, for keeping an eager eye out for us. Most of us oldtimers are running our systems more or less on autopilot with settings that's been working for decades.

Your constant lookout is really appreciated. There are no longer that many of your calibre active in Fidonet anymore. Kudos!

FWIW, I've been adding lots of empty lines in my recent messages here lately. This one for instance had five empty lines before the "Wilfred.." line.
Did SquishMail remove all of them? And if so, what "spec" does it violate?



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

Hi Bj”rn,

On 2019-04-19 22:46:33, you wrote to me:

@MSGID: 2:203/2 5cba33a6
@REPLY: 2:280/464 5cba29ca
@PID: JamNNTPd/Win32 1
@CHRS: CP437 2
@TZUTC: 0200
@TID: CrashMail II/Win32 0.71
Wilfred van Velzen -> mark lewis skrev 2019-04-19 22:04:

Inconclusive. We need more data... ;)

FWIW, I've been adding lots of empty lines in my recent messages here lately. This one for instance had five empty lines before the
"Wilfred.." line. Did SquishMail remove all of them?

It seems so. Above is how it arrived here. No empty line(s) between the last kludge line, and the first line with text.

But this wasn't an intransit mail when it was changed, because it hadn't left the system of the author yet when it was changed... So you might still not like
it, but this is a different case than what we are discussing here. ;)

And if so, what "spec" does it violate?

I don't know if there is a ftsc document that states this specifically. But it seems common sense to me, that the text part of a message shouldn't be changed while it is intransit, because that is not how the author of the message intended it to be and it could in a worse case scenario change the meaning of the text. What if a mailman opened letters and fixed spelling errors? He would argue he was providing a service, but I don't think the sender and recipient would agree. ;)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

On 2019 Apr 19 22:46:32, you wrote to Wilfred van Velzen:

@MSGID: 2:203/2 5cba33a6
@REPLY: 2:280/464 5cba29ca
@PID: JamNNTPd/Win32 1
@CHRS: CP437 2
@TZUTC: 0200
@TID: CrashMail II/Win32 0.71
Wilfred van Velzen -> mark lewis skrev 2019-04-19 22:04:

Inconclusive. We need more data... ;)

Indeed.

And I must thank you Wilfred, for keeping an eager eye out for us. Most of us oldtimers are running our systems more or less on autopilot with settings that's been working for decades.

Your constant lookout is really appreciated. There are no longer that many of your calibre active in Fidonet anymore. Kudos!

FWIW, I've been adding lots of empty lines in my recent messages here lately. This one for instance had five empty lines before the "Wilfred.." line. Did SquishMail remove all of them?

there are no empty lines above after the last control line...

And if so, what "spec" does it violate?

you still haven't found where "not modifying messages in transit" is discussed?

..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)
SEEN-BY: 1/19 16/0 18/200 120/544 123/130 131 132/174 153/7715 154/10

201/0

SEEN-BY: 203/0 2 124 412 211/37 221/0 1 230/0 240/5832 261/1 38 275/100 SEEN-BY: 280/464 5003 5555 310/31 320/119 219 423/81 3634/12 5020/545 848 SEEN-BY: 123/25 50 150 755 135/300 3634/15 24 27 50 119 123/115 3634/0

18/0

SEEN-BY: 123/0 1/120
@PATH: 203/2 0 320/219 3634/12

your message arrived here via this path... we already know that 320/219 and 3634/12 are not removing blank lines from the beginning of the message body... that leaves 203/2 and/or 203/0 performing this defect... kinda like the ones that inject hard-CRs and force wrap in-transit messages to <80 chars per line... neither of those actions is correct for a tosser that tosses directly from the inbound PKT into the outbound PKTs... with your knowledge and experiance, you shouldn't have to ask me where this is discussed :/

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... What do you mean my Birth Certificate expired?
---
* Origin: (1:3634/12.73)

On 2019 Apr 19 23:36:28, you wrote to Bj”rn Felten:

@MSGID: 2:203/2 5cba33a6
@REPLY: 2:280/464 5cba29ca
@PID: JamNNTPd/Win32 1
@CHRS: CP437 2
@TZUTC: 0200
@TID: CrashMail II/Win32 0.71
Wilfred van Velzen -> mark lewis skrev 2019-04-19 22:04:

Inconclusive. We need more data... ;)

FWIW, I've been adding lots of empty lines in my recent messages here
lately. This one for instance had five empty lines before the
"Wilfred.." line. Did SquishMail remove all of them?

It seems so. Above is how it arrived here. No empty line(s) between the last kludge line, and the first line with text.

same as i saw...

But this wasn't an intransit mail when it was changed, because it
hadn't left the system of the author yet when it was changed...

umm... are you talking about BF's above or ??? the above was written on his 230/2 system... he seems to be saying that squishmail on his 230/0 is the system stripping the leading blank lines from the message bodies in all traffic
it handles...

So you might still not like it, but this is a different case than what
we are discussing here. ;)

i'm not sure about that ;) i can easily see there being possibly two options for stripping leading blank lines...

1. when tossing messages into the local message bases
2. when scanning out messages posted locally

but any kind of *in-transit* changes to _echomail_ are frowned on... other than
adding/sorting the seenbys and adding to the path and changing the few necessary header fields, of course...

And if so, what "spec" does it violate?

I don't know if there is a ftsc document that states this specifically.

But

it seems common sense to me, that the text part of a message shouldn't be changed while it is intransit, because that is not how the author of the message intended it to be and it could in a worse case scenario change the meaning of the text.

not to mention throwing off duplicate detection... there's a lot of systems that use multiple methods of dupe detection... one of those methods is to run a
few checksums on selected fields and the message body... they do this in addition to using the MSGID and other methods they may employ... systems that sorted the control lines into some order they use for locally generated posts were caught in ""recent"" years and ""corrected"" or are no longer on the network any more...

i know of a number of systems that will dupe-out a message if the message body is exactly the same even though the MSGID and header fields are different... they do not count control lines, seenbys, or path lines as being part of the message body... i don't recall if they stop at the tear and/or origin lines or if they are even included in the checksum formula... they could be since tear and origin lines should not be modified at all... negating them is different and changes the message body anyway since the negated ones become message body at that time... negating them would be done when gating from one FTN to another, of course ;)

What if a mailman opened letters and fixed spelling errors? He would
argue he was providing a service, but I don't think the sender and recipient would agree. ;)

you're right about that! -=B-)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Whattaya mean I can't logon to an active Node?
---
* Origin: (1:3634/12.73)

you still haven't found where "not modifying messages in transit" is discussed?

No. And neither have you, obviously.



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

But this wasn't an intransit mail

But it was. The message was processed by CrashMail on 203/2 and then went via 203/0 to you.



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

Hello Bj”rn,

Saturday April 20 2019, Bj”rn Felten wrote to mark lewis:

you still haven't found where "not modifying messages in transit"
is discussed?

No. And neither have you, obviously.

Fidonet Policy v.4.07

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.

Michael

... node (at) f1042 (dot) ru
--- GoldED+/LNX 1.1.5-b20170303
* Origin: Moscow, Russia (2:5020/1042)

Hi mark,

On 2019-04-19 18:07:26, you wrote to me:

But this wasn't an intransit mail when it was changed, because it
hadn't left the system of the author yet when it was changed...

umm... are you talking about BF's above or ??? the above was written on

his

230/2 system... he seems to be saying that squishmail on his 230/0 is the system stripping the leading blank lines from the message bodies in all traffic it handles...

230=203, But ok I wasn't paying attention. ;)


Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

Hi Björn,

On 2019-04-20 08:54:02, you wrote to me:

But this wasn't an intransit mail

But it was. The message was processed by CrashMail on 203/2 and then went via 203/0 to you.

Aha, ok, I wasn't paying attention about that detail. ;)

Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
* Origin: FMail development HQ (2:280/464)

On 2019 Apr 20 08:51:12, you wrote to me:

you still haven't found where "not modifying messages in transit" is
discussed?

No. And neither have you, obviously.

what makes you think i'm looking for it? you're the one asking when you really shouldn't have to...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Beware of natives bearing large green fruits.
---
* Origin: (1:3634/12.73)

No. And neither have you, obviously.

Fidonet Policy v.4.07

Well, you see Michael, that's not a "spec", that's a policy.

Further more, mark is one of the people in Z1, that for decades have insisted that P4 does *not* cover echomail.




..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

what makes you think i'm looking for it? you're the one asking when you really shouldn't have to...

I'm asking because I know there's no such "spec". And you should too, if you're a real FTSC member.

It's interesting trivia, not some "spec" violation. Live with it.


..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

On 2019 Apr 20 13:48:20, you wrote to Michael Dukelsky:

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

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Before you turn on the treadmill, always tie your shoes.
---
* Origin: (1:3634/12.73)

On 2019 Apr 20 13:50:46, you wrote to me:

what makes you think i'm looking for it? you're the one asking when
you really shouldn't have to...

I'm asking because I know there's no such "spec".

then why ask in the first place?

And you should too,

of course i do...

if you're a real FTSC member.

even if i weren't a FTSC member...

It's interesting trivia, not some "spec" violation. Live with it.

i'm not complaining about it ;)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Every absurdity has a champion to defend it.
---
* Origin: (1:3634/12.73)

And you should too,

of course i do...

Why then, did you claim so?

WV> Is this annoying? Don't think so. Just found it remarkable...

no, not annoying but it is against spec...




..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

Hello Björn,

20 Apr 19 13:48 at you wrote to Michael Dukelsky:

Further more, mark is one of the people in Z1, that for decades
have insisted that P4 does *not* cover echomail.

According to Policy 4, section 9.9, echomail -is- covered by P4 at least for policy disputes:

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

I was always told that P4 didn't cover echomail in general since echomail is an "add-on" to Fidonet since Fidonet was originally founded for netmail only.

I think though that traditionally (now, at least) it's inferred that P4 covers echomail.

Later,
Sean

... Living is like licking honey off a thorn.
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Outpost BBS * Limestone, TN, USA (1:18/200)

I think though that traditionally (now, at least) it's inferred that P4 covers echomail.

Most of us has always thought so too. It's good news that we all seem to agree now. A new Fidonet era, with less confrontation and more cooperation, might lie ahead of us? <3



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

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. What I *do* remember is, that policy complaints on a regular basis were dismissed in Z1 based on the "P4 does not cover echomail" mantra.

Any attempts (from mostly Z2, that always has been adamant about it) to claim otherwise were waved off with "it's a language thing" implying that we in
Z2 that (all except R25) does not have English as our native tongue did not understand what P4 *actually* says.

Is my written English -- my third language after Swedish and German -- so bad, that anyone think that reading and understanding English
would pose a problem for me? Some people did...



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

I think though that traditionally (now, at least) it's inferred that BF>SD> P4 covers echomail.

Most of us has always thought so too. It's good news that we all seem
to agree now. A new Fidonet era, with less confrontation and more cooperation, might lie ahead of us? <3

Nevertheless the ZCs have always interpreted that formal complaints on echomail-content are 'not' a P4 thing because there are moderators to handle issues. And accepting the presence of moderators, which are not mentioned in P4, opens up a totally different can of worms ... you know what I mean ...

\%/@rd

--- D'Bridge 3.99 SR41
* Origin: Ceci n'est pas un courriel (2:292/854)

Any attempts (from mostly Z2, that always has been adamant about it)
to claim otherwise were waved off with "it's a language thing" implying that we in Z2 that (all except R25) does not have English as our native tongue did not understand what P4 *actually* says.

To me it was explained as being a first ammendment thing, freedom of speech, even the Roy Witt Nazi-statements. Because it was getting so bad at times I talked with a US-based attorney about that and he concurred.

That was about the USA, Canadians always have been more docile and less troublesome.

\%/@rd

--- D'Bridge 3.99 SR41
* Origin: Ceci n'est pas un courriel (2:292/854)

And accepting the presence of moderators, which are not mentioned in P4, opens up a totally different can of worms ... you know what I mean ...

BOC! It can be summed up with just three characters: EP1. 8-)



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

Hello Wilfred,

I don't know if there is a ftsc document that states this specifically.

I have seen such a clause somewhere too.

But it seems common sense to me, that the text part of a message
shouldn't be changed while it is intransit, because that is not how the author of the message intended it to be and it could in a worse case scenario change the meaning of the text.

Exactly.

What if a mailman opened letters and fixed spelling errors?
He would argue he was providing a service,
but I don't think the sender and recipient would agree. ;)

I have heard one occasion where that realy took place.
It was the pressman who had to press a manual, and the errors were placed in the paragraph discussing the working of the spelling checker.
So that errors were mandatory necessarry for the user to show how to handle.
It indeed totally changed the function of this explicitly made errors,
and the correction of the pressman was absolutely not appreciated ;-(.
So he had to do the press of that software manual again with the orignal errorfull text, and of course without extra charge.

The other phenomenon I know of was to make explicitly an error in sending morse
codes after 14 letters transmitted, so the receiver could detect the sender was
arrested by the other militair party, i.e. during WO II.

So sometimes the right place of errors can be very important.
It shows unexpected information too ;-).

Henri.

---
* Origin: Connectivity is the Future; UniCorn BBS 31 26 4425506 (2:280/1208)

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)

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

Was the rest here proof of you saying that echomail *is* covered by P4? If so, you have hidden it well in a lot of talk.


..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

On 2019 Apr 21 13:39:40, you wrote to me:

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

Was the rest here proof of you saying that echomail *is* covered by
P4?

did you even read what i wrote?

If so, you have hidden it well in a lot of talk.

understanding what is written would be a first good step... maybe try that? ;)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... I wondered why the handball was getting bigger. Then it hit me!
---
* Origin: (1:3634/12.73)

Hello Bj”rn,

21 Apr 19 07:57 at you wrote to me:

Most of us has always thought so too. It's good news that we all
seem to agree now. A new Fidonet era, with less confrontation and more cooperation, might lie ahead of us? <3

I'm not trying to start a war here, promise. I realized that I hadn't read P4 in a very, very long time and decided to give it a read.

I've always figured that since echomail has become a big part of Fidonet that "certain rules would apply".

From what I've seen, in othernets including my own, netmail and echomail are both covered by the same policies.

Later,
Sean

... Ask not what you can do for your country; ask how your country will screw you.
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Outpost BBS * Limestone, TN, USA (1:18/200)

Hello Ward,

21 Apr 19 08:34 at you wrote to Bj”rn Felten:

Nevertheless the ZCs have always interpreted that formal complaints on echomail-content are 'not' a P4 thing because there are moderators to handle issues. And accepting the presence of moderators, which are not mentioned in P4, opens up a totally different can of worms ... you
know what I mean ...

That is a very good point that I overlooked. I see where you're coming from on that.

I'd dare to venture that from P4's point of view, a policy dispute would have been that someone pulling too much bandwidth from an uplink to carry what was then an excessive amount of echomail. I don't think that would apply for a majority of users in Z1. I could see issues in other zones that don't have "unlimited" telecommunications access for cheap.

Later,
Sean

... If at first you don't succeed, you're doing about average.
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Outpost BBS * Limestone, TN, USA (1:18/200)

Hello Ward,

21 Apr 19 08:43 at you wrote to Bj”rn Felten:

To me it was explained as being a first ammendment thing, freedom of speech, even the Roy Witt Nazi-statements. Because it was getting so
bad at times I talked with a US-based attorney about that and he concurred.

There's no such thing as free speech in Fidonet. Even in the US. Though if someone tried to sue someone in the US over it, the case would more than likely be tossed out on First Amendment grounds.

That was about the USA, Canadians always have been more docile and
less troublesome.

'Murica!

A little humor here:
https://theoatmeal.com/pl/minor_differences4/accents

Later,
Sean

... WinErr 001: Windows loaded - System in danger
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Outpost BBS * Limestone, TN, USA (1:18/200)

On 2019 Apr 21 11:16:56, you wrote to Ward Dossche:

Nevertheless the ZCs have always interpreted that formal complaints
on echomail-content are 'not' a P4 thing because there are moderators
to handle issues. And accepting the presence of moderators, which are
not mentioned in P4, opens up a totally different can of worms ...
you know what I mean ...

That is a very good point that I overlooked. I see where you're
coming from on that.

have you seen my post to bjorn on this topic? not sure if i just posted it in here... he accused me, again, of supporting the view that echomail is not covered... he says he has forgotten about my 2015 post to him on the subject so
i posted it to him again ;)

I'd dare to venture that from P4's point of view, a policy dispute
would have been that someone pulling too much bandwidth from an uplink
to carry what was then an excessive amount of echomail. I don't think that would apply for a majority of users in Z1.

exactly... transport, not content...

I could see issues in other zones that don't have "unlimited" telecommunications access for cheap.

that's why an operator can pick and choose what echos they carry and what they allow their users to do ;)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Tonight's Forecast: Dark, with scattered light by sunrise.
---
* Origin: (1:3634/12.73)

mark,

have you seen my post to bjorn on this topic?

I think most everybody here just right-clicked that exchange.

\%/@rd

--- D'Bridge 3.99 SR41
* Origin: Ceci n'est pas un courriel (2:292/854)

Sean,

I'd dare to venture that from P4's point of view, a policy dispute would have been that someone pulling too much bandwidth from an uplink to
carry what was then an excessive amount of echomail. I don't think that would apply for a majority of users in Z1. I could see issues in other zones that don't have "unlimited" telecommunications access for cheap.

Your reasoning is as good as mine, but neither has been tested really.

My take on it is that policy complaints on echomail matters can be invoked by a
moderator if nicely asking, and after that not so nicely asking (followed by the 'Italian Victory Salute' aka 'the george bush sign' probably) doesn't work when moderating where-after said moderator could become annoyed enough to seek help and file a formal complaint, not on content, but on the technical ground of being prevented from performing his/her moderator job.

At that point a minor technicality comes into play ... "what determines who the
moderator is?" ... and there's no uniform way of defining it between the zones...

\%/@rd

--- D'Bridge 3.99 SR41
* Origin: Ceci n'est pas un courriel (2:292/854)

Hello Ward,

21 Apr 19 20:14 at you wrote to me:

Your reasoning is as good as mine, but neither has been tested really.

I'd like to think that it wouldn't be tested.

At that point a minor technicality comes into play ... "what
determines who the moderator is?" ... and there's no uniform way of defining it between the zones...

Indeed. I would have to say that a "gentlemans' agreement" would have to be the probable solution as in all parties involved that there is one caretaker of the echo. Not to start a war with this but that's why the echolist (amongst various reasons) is in existance in Z1. I know that other zones don't agree with it but that's not my point here. The echolist can establish who the moderator is publically without arguing the point to death. I don't know how that's handled in other zones so I can only speak from my experience.

However, in today's Fidonet, I'd say that it would be common knowledge of who a moderator is in a particular echo. There's not many of us left in Z1 who moderate echoes. I moderate 15 echoes myself now and there's rarely a reason to actually moderate though when it's needed, it's needed, if that makes sense.

I'm mainly there as a caretaker now.

(I didn't select the tagline on this message, really.)

Later,
Sean

... Open mouth, insert foot, echo internationally.
--- GoldED+/LNX 1.1.5-b20180707
* Origin: Outpost BBS * Limestone, TN, USA (1:18/200)

Ward Dossche wrote to mark lewis <=-

have you seen my post to bjorn on this topic?

I think most everybody here just right-clicked that exchange.

"Right-clicked" it? Whatever does that mean? I wouldn't have
thought that such an experienced old-skooler like yourself would
be using a clicky-touchy-feely interface to read echomail!

I actually read it with interest.



... To err is human, to forgive is against SysOp policy.
=== MultiMail/Linux v0.51
--- SBBSecho 3.20-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)

mark lewis wrote to Bj”rn Felten <=-

Was the rest here proof of you saying that echomail *is* covered by
P4?

did you even read what i wrote?

I would guess that he hasn't.

If so, you have hidden it well in a lot of talk.

understanding what is written would be a first good step... maybe
try that? ;)

I don't think that's gonna happen...



... Would you like to wake up from this dream?
=== MultiMail/Linux v0.51
--- SBBSecho 3.20-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:135/115)

On 2019 Apr 21 18:48:00, you wrote to me:

have you seen my post to bjorn on this topic?

I think most everybody here just right-clicked that exchange.

you saw it four years ago... i'm not sure if sean saw it then or just now in here...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... He who can analyze his delusions is called a philosopher.
---
* Origin: (1:3634/12.73)

Hello Andrew,

203/0 is Squish 1.11 IIRC. I'm not sure what tosser Torsten is
using at 240/5832.

=== Begin Clipboard ===
Tossing CBAF77EC.PKT from 2:240/5832 to 2:221/360
+-(Squish 1.11, Type 2+) (2 kB, 20-Apr-19 12:42:06)
=== End Clipboard ===

That makes sense, then. Both 203/0 and 240/5832 are using Squish.
This could be a previously unrecognized bug in Squish.

Is there a chance this bug would be repaired?
You know the author?

If not, all users of this software for exchanging EchoMail could get a warning of modifying in transit (echo-)Mail, ducking.

Indeed the postman shall never alter the contents of mail.

If not repairable (abandonware?),
the users should think about replacing this software for something else.
To become in Spec again ;-).

Last week I got a letter in my box adressed to someone else in the naborhood, with the same number but different street.
Of course I could bring it to that adress,
but I exlicitely placed a sticker on it adressed to the postman,
that it was not intended for me, so redeliver it again to the right adres.
If I would correct his fault, i.e. bring that letter to the correct adres,
he never know what he did wrong.
It's a pity this way takes more time, but that's not my fault.

Henri.

---
* Origin: Connectivity is the Future; UniCorn BBS 31 26 4425506 (2:280/1208)

Hello Henri!

21 Apr 19 13:49, you wrote to me:

That makes sense, then. Both 203/0 and 240/5832 are using Squish.
This could be a previously unrecognized bug in Squish.

Is there a chance this bug would be repaired?
You know the author?

Scott Dudley wrote Squish (along with Maximus-CBCS.) He's been out of FidoNet for a while, but I believe the source code for Squish was included in the release of the Maximus source code. If so, it's probably possible that someone might fix it.

If not, all users of this software for exchanging EchoMail could get a warning of modifying in transit (echo-)Mail, ducking.

I don't consider that likely to happen.

Indeed the postman shall never alter the contents of mail.

If not repairable (abandonware?),
the users should think about replacing this software for something
else. To become in Spec again ;-).

In theory, nodes currently using Squish could switch to something else, such as HPT or FastEcho. I find it unlikely, however, that too many will.

Andrew

--- GoldED+/LNX 1.1.5-b20180707
* Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219)

I think most everybody here just right-clicked that exchange.

"Right-clicked" it? Whatever does that mean? I wouldn't have
thought that such an experienced old-skooler like yourself would
be using a clicky-touchy-feely interface to read echomail!

Well, the "Next" key ... but the young=uns maybe don't understand that.

I actually read it with interest.

Good for you, prevented you from writing trash in the meantime. 8-)

\%/@rd

--- D'Bridge 3.99 SR41
* Origin: Ceci n'est pas un courriel (2:292/854)

mark,

I think most everybody here just right-clicked that exchange.

you saw it four years ago... i'm not sure if sean saw it then or just now in here...

Most likely not ... My reading preferences are ...

* Messages addressed to myself
* " " " All
* " to/from Nick Andre and Scott Little
* And then maybe an interesting sounding thread

However after 2 exchange cycles I always move away.

\%/@rd

--- D'Bridge 3.99 SR41
* Origin: Ceci n'est pas un courriel (2:292/854)

Most likely not ... My reading preferences are ...

You didn't miss anything. All he did was quoting half of P4.



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

Is there a chance this bug would be repaired?

It's not a bug.

Even mark had to admit that there is no FTS that is being violated, so his now infamous "not annoying but it is against spec... " was too hastily written.



..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

On 2019 Apr 22 10:36:58, you wrote to me:

I think most everybody here just right-clicked that exchange.

you saw it four years ago... i'm not sure if sean saw it then or just
now in here...

Most likely not ...

IIRC, you were one of those that responded to it...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Roasted garlic is one of the great accomplishments of civilization.
---
* Origin: (1:3634/12.73)

On 2019 Apr 22 11:57:30, you wrote to Ward Dossche:

Most likely not ... My reading preferences are ...

You didn't miss anything. All he did was quoting half of P4.

no it wasn't... it was the related parts needed to understand how echomail is covered by policy... nothing more...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... I'm out of bed and dressed. What more do you want?
---
* Origin: (1:3634/12.73)

On 2019 Apr 22 12:07:22, you wrote to Henri Derksen:

Is there a chance this bug would be repaired?

It's not a bug.

says who? you? what qualifies you to say that?

Even mark had to admit

mark has done no such thing... i'll thank you to stop saying that i've said or done things that i have not done or said...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... I always do what the little voices tell me to do.
---
* Origin: (1:3634/12.73)

Even mark had to admit

mark has done no such thing... i'll thank you to stop saying that i've said or done things that i have not done or said...

It's probably something language related then. This is what you said:

I'm asking because I know there's no such "spec".

then why ask in the first place?

And you should too,

of course i do...

..

--- Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.1.16) Gecko/20101125
* Origin: news://eljaco.se (2:203/2)

you saw it four years ago... i'm not sure if sean saw it then or ml>ml>> just now in here...

Most likely not ...

IIRC, you were one of those that responded to it...

Et alors ? ......

\%/@rd

--- D'Bridge 3.99 SR41
* Origin: Ceci n'est pas un courriel (2:292/854)

On 2019 Apr 22 15:31:32, you wrote to me:

you saw it four years ago... i'm not sure if sean saw it then or
just now in here...

Most likely not ...

IIRC, you were one of those that responded to it...

Et alors ? ......

you had to have seen it to respond to it...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... She tasted like chili peppers.
---
* Origin: (1:3634/12.73)

IIRC, you were one of those that responded to it...

Et alors ? ......

you had to have seen it to respond to it...

Know your classics, mark, know your classics!

\%/@rd

--- D'Bridge 3.99 SR41
* Origin: Ceci n'est pas un courriel (2:292/854)

On 04-21-19 13:49, Henri Derksen <=-
spoke to Andrew Leary about Desired Living Document ( <=-

Last week I got a letter in my box adressed to someone else
in the naborhood, with the same number but different street.
Of course I could bring it to that adress,

Ditto happens here also. In our case, we have a cluster mailbox and
both myself and the other party with same number, different street, use
that same cluster of boxes. I'd say it happens once a month or so. If
it looks important (e.g. a check), I will walk it up to her house.
Otherwise -- I stick it back in for the next mail person to correct.

Dale Shipp
fido_261_1466 (at) verizon (dot) net
(1:261/1466)


... Shipwrecked on Hesperus in Columbia, Maryland. 01:55:33, 23 Apr 2019
___ Blue Wave/DOS v2.30

--- Maximus/NT 3.01
* Origin: Owl's Anchor (1:261/1466)

On 04-22-19 10:36, Ward Dossche <=-
spoke to Mark Lewis about Re: P4 covers echomail <=-

* And then maybe an interesting sounding thread

And how often do folks here change the subject line for you to tell
whether or not it is an interesting new thread, or just more of the same
stuff?

Dale Shipp
fido_261_1466 (at) verizon (dot) net
(1:261/1466)


... Shipwrecked on Hesperus in Columbia, Maryland. 01:57:37, 23 Apr 2019
___ Blue Wave/DOS v2.30

--- Maximus/NT 3.01
* Origin: Owl's Anchor (1:261/1466)

* And then maybe an interesting sounding thread

And how often do folks here change the subject line for you to tell
whether or not it is an interesting new thread, or just more of the same stuff?

Good question.

\%/@rd

[I changed the subject line ... 8-) }

--- D'Bridge 3.99 SR41
* Origin: Ceci n'est pas un courriel (2:292/854)