Subj : The mystery of mark's empty lines
To : Wilfred van Velzen
From : mark lewis
Date : Fri Apr 19 2019 06:07 pm
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)
