TIP: Click on subject to list as thread! ANSI
echo: locsysop
to: Paul Edwards
from: Rod Speed
date: 1996-05-12 07:05:56
subject: echomail

RS> The problem is that you barely even test changes, just release and pray.
RS> It aint exactly a terrific idea to just use stuff released like that.

PE> It gets live-tested by the first person to use it.

RS> Soorree, that aint anything remotely like rigorous testing.

PE> Yes it is, a week of testing by Frank was plenty of testing.

Soorree, that aint anything like rigorous testing. He doesnt post much,
he may well not have posted even a single netmail in that time, most of
the time something that say causes a message to get flushed on a particular
system wouldnt even be noticed that it had got flushed. He doesnt post
much in international echoes either. Thats NOTHING like rigorous testing.

PE> And if you don't like PQWK's testing level, USE A DIFFERENT PRODUCT.

Or choose to not immediately upgrade to a new release
because it hasnt been rigorously tested. Novel concept what ?

PE> I said months ago that PQWK had a problem, which caused me problems,

You specified that particular problem, with embedded origin lines. I dont
produce messages with embedded origin lines. It makes considerable sense to
wait and see if you have managed to produce a wart with the new release or not.

The same applys with Binkley right now too. Some may well prefer
to continue to use say 2.59 if they dont have any particular need
for what is in 2.60, waiting to see if there are subtle blemishes
in 2.60. It doesnt make the slightest sense for everyone to immediately
start using 2.60 as soon as its available and hope for the best.
Soorree, that aint anything remotely like rigorous testing.

And it aint as if you are gods gift to programming either, you lack of
rigorous testing produced a situation where Tobruk was producing messages
which were less than absolutely immaculate as far as FTSs are concerned,
and it doesnt make the slightest sense for systems upstream of you to be
silently binning entire PKT which have a message like that in them.

PE> and if you have so little regard for that that you couldn't give a
PE> shit if you cause me problems, well I consider that to be malicious.

You can consider it to be whatever you fucking like boy.

If you dont have the mental horsepower to grasp that not
everyone chooses to code and pray, thats your problem entirely.

PE> I am recompiling Tobruk now, with that bit of code commented
PE> out, to allow what appears to be "routed echomail".  Then I will
PE> recompile it back to normal.  And then THAT IS IT.  NO MORE.

RS> That doesnt sound like a terribly practical approach, because its quite
RS> feasible for other than PKTs generated by PQWK to have that problem.
RS> In other words, even if the latest PQWK is used, you havent allowed for
RS> some other point which doesnt even use PQWK at all doing that blemish.

PE> No, it's only a problem with people who send me packets directly.

RS> And they dont all happen to use PQWK do they ?

PE> No, they don't.  I wish no-one used PQWK.

Pity that you will still have a problem if someone who uses
other than PQWK produces a message which does not match your
bizarre ideas on what its appropriate to bin the entire PKT for.

Luckily for you, those upstream of you dont operate like that
with blemishes in YOUR code, coz that makes no sense whatever.

RS> And presumably you dont expect Tobruk to only ever get used by you either.

PE> No, I don't.

So it would make a lot more sense if Tobruk did something
rather more intelligent than just bin entire PKTs which contain
what you claim is a less than absolutely pristine message.

PE> The problem is that the address of the sender is not
PE> 711/934 but whatever crap was in an inserted origin line.

RS> Yes, no argument that there is a problem with embedded origin lines.

PE> Not really.  Using PQWK260, you can send me
PE> embedded origin lines, and I won't complain.

Pity that the are other ways of generating PKTs which
can be directly sent to a system which is running Tobruk.
Particularly in the future when more than you run Tobruk.

PE> Or using MSGED, you can send me embedded origin lines.  There
PE> may be other software that doesn't like embedded origin lines,

There aint no maybe about it Paul, you do see those at times, something
must be doing that. You can proclaim that it makes sense to just bin
entire PKTs when they aint absolutely pristine in your eye, pity that that
would have see ALL of the messages leaving your system binned by systems
upstream of you if others had such silly ideas about what makes sense.

PE> but it's basically in-spec as far as I'm concerned,
PE> they have to fix their software if they don't like it.

Arent you lucky that the systems upstream of you didnt
operate like that with the PKTs YOUR code produced, just
silently binning the entire PKT and not saying a word ?

RS> How best to DEAL with them tho is another matter entirely tho.

RS> You can for example make a case for nuking the * on one of those
RS> embedded origin lines IN TOBRUK, when its tossing a packet from
RS> people who send you packets directly. And THEN it catches those warts
RS> even when something else is used to prepare the packets than PWQK too.

PE> No, the problem is not the embedded origin line in the MSG in
PE> the PKT I receive from you, the problem is in the address in the
PE> fixed header portion of the MSG in the PKT I receive from you.

Yes, you fucked up when you originally claimed that it was an embedded
origin line. The same problem still arises with messages that contain
a superfluous MSGID too tho, it doesnt make the slightest sense to
just change PQWK and have Tobruk silently bin entire PKTs when it sees
a blemish in a particular message. Because if everyone operated like
that, YOUR entire message flow from YOUR system would have got binned
when YOUR code was producing less than absolutely pristine messages TOO.

PE> You are not using your own address in there.

Soorree, we are talking about an embedded MSGID. Its mad
for Tobruk to be using one thats between an SOT/EOT as the
source of 'my address' So it doesnt make the slightest sense
to be binning entire PKTs which contain a blemish like that.

PE> That is because of a bug in PQWK250.

Pity that other than PQWK250 can produce messages which are not
absolutely pristine by YOUR silly ideas on what constitutes 'the specs'

RS> THATS what robust software is all about. Recognising that in the real
RS> world not all packets can be guaranteed to be absolutely pristine.

PE> No, that's why it was caught and rejected.

Pity that that would be hard to do if all systems upstream of you
silently binned entire PKTs that left your system with a blemish
in a message Paul. THATS nothing like what robust software is about.

PE> I don't check that area very often, that's why Keith's was weeks
PE> old before I found it.  You were lucky, I was looking for problems
PE> from Keith when I found yours, so there was only a few days delay.

And you also have to question the sense in being so lax about checking
too. And not for example having some notification of a problem rather
than just silent binning and hoping for the best. Coz if those upstream
of you did that with anything less than absolutely pristine, YOU would
have had a considerable problem yourself.

RS> In fact for a time Tobruk was producing some which werent itself.

PE> *I* fixed problems in Tobruk as soon as they
PE> were pointed out to me, or I saw them myself.

Pity that your completely crackpot approach of silently binning any
PKT which contained a less than absolutely immaculate message would
have seen the ENTIRE output from your system silently binned Paul.
Luckily for you, everyone else has rather more sense than that.

PE> YOU have to do the same, either by stopping using PQWK250, or upgrading.

Soorree, using software which hasnt been rigorously tested aint
my idea of anything remotely like reliable mail, particularly when
you really have no way of seeing what gets out into fido and the
recipient chooses not to reply and when it never got them at all.

I repeat, it doesnt make the slightest sense to be silently
binning entire PKTs which contain a less than absolutely
pristine message using your nutty ideas about 'the specs'

What DOES make sense is to notify the person who has produced a message
which is a problem, and if that problem has been addressed in a later
version of the software that he is using THEN use that or that person can
choose to use other methods of avoiding producing that blemish in a message.

PE> I did the work to fix the problem, it's up to YOU to
PE> choose one of the fixes available.  It's not up to
PE> you to choose to not care, and send me corrupt mail.

Christ you really are a complete fuckwit Paul Edwards. No one
is deliberately sending you messages they know cause problems.

And then there is the completely separate question of whether it makes
sense for Tobruk to behave more sensibly with less than absolutely
pristine messages too. In the case of embedded MSGID which are between
the SOT/EOT pair, it may well make more sense to take no specific action
with that message at all. Which just happens to be what all the other
mail tossers do with a message with that particular blemish in it.

RS> It would have made no sense for system up stream of you
RS> to be silently binning entire PKTs when a wart was seen.

PE> It would be nice if the system upstream told me.

Funny that.

PE> The thing is, I already told you.

No you didnt. You didnt say that the version of PQWK I was using
would allow a MSGID between a SET/EOT pair and that that was wrong.
In fact you had raved on for many messages about the value of the
SOT/EOT being that it ALLOWED various stuff which would otherwise
be considered to be information a tosser used to be recognised as
being part of the body of the message, so the werent a problem.

PE> It's your lack of doing something about it that pissed me off.

Pity you had such a massive series of brain farts on that then.

And you STILL are on the utterly LUDICROUS proposition that it makes the
slightest sense to be silently binning entire PKT which contain a message
which isnt absolutely pristine in your eyes judged by your completely loony
ideas about what constitutes 'the specs'. Luckily for you, the systems
upstream of you have a HELL of a lot more sense than to do that.
@EOT:

---
* Origin: afswlw rjfilepwq (3:711/934.2)
SEEN-BY: 711/934
@PATH: 711/934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.