Subj : The mystery of mark's empty lines
To   : Wilfred van Velzen
From : mark lewis
Date : Fri Apr 19 2019 06:07 pm


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

 BF>> @MSGID: 2:203/2 5cba33a6
 BF>> @REPLY: 2:280/464 5cba29ca
 BF>> @PID: JamNNTPd/Win32 1
 BF>> @CHRS: CP437 2
 BF>> @TZUTC: 0200
 BF>> @TID: CrashMail II/Win32 0.71
 BF>> Wilfred van Velzen -> mark lewis skrev 2019-04-19 22:04:
 WvV>>> Inconclusive. We need more data... ;)

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

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

same as i saw...

 WV> But this wasn't an intransit mail when it was changed, because it
 WV> 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...

 WV> So you might still not like it, but this is a different case than what
 WV> 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...

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

 WV> I don't know if there is a ftsc document that states this specifically. 
But
 WV> it seems common sense to me, that the text part of a message shouldn't be
 WV> changed while it is intransit, because that is not how the author of the
 WV> message intended it to be and it could in a worse case scenario change the
 WV> 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 ;)

 WV> What if a mailman opened letters and fixed spelling errors? He would
 WV> argue he was providing a service, but I don't think the sender and
 WV> 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)

.