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)