(Continued from previous message)


PE> Squish is the thing that is taking an inbound packet, and routing
PE> any netmail not to 3:711/934 to 3:711/809.  It doesn't know about
PE> Areafix, nor Squalid, nor thousands of other aliases for Areafix.

But mappings which happen first can cant they. They can add
the missing addressing to 3:711/934 and THEN it can carry on
as if it had always been there in the first place.

PE> Seal is another alias. Everyone who writes an Areafix-compatible
PE> program adds a name for themselves.  David Begley reports that
PE> I should be using Areamgr, not Areafix, but that's not right
PE> according to the documentation I have read.

Dunno.

PE> because certainly in PQWK221 if you don't specify an address
PE> to Areafix or any other person, it doesn't have a default
PE> (unless you call uninitialized variables a default), and
PE> the message could go anywhere.

RS> Well thats obviously an extremely undesirable way to code it. And
RS> quite trivial to fix by initialising those to the node number in use,
RS> maybe even with the point bit retained. Atleast then it comes back.

PE> What do you think PQWK222 does, Rod?

RS> We were discussing why it worked before that Paul.

PE> It didn't work before that Rod, at least not in PQWK221.

But it did with 2.02 Paul.

PE> I don't know about pre-221, I only ever work on the latest version.

Welp, it works anyway.

PE> And yep, it's even got the point, so it comes back to you so you
PE> know something is wrong.

RS> Dunno, I have reservations about that approach too. In some ways
RS> its better to notify the user in the QWK->PKT step so it can be
RS> fixed before the PKT goes out. It would be very easy to say send
RS> a dud netmail in a rush as you tear out the door on holiday and
RS> only find when you get back that its been bounced. Maybe the answer
RS> is to do both, so if the user isnt around to get notified it will
RS> bounce, and if he fixes it it wont even get sent coz the PKT will
RS> presumably be dumped and a new one created.

PE> I think it flies by too fast to notice.

It can always bell or pause or something. Or even write an error
log and report at the end that an error was found.

PE> There's too much crap getting printed out already.

I dont happen to think that a message with no To: field is crap.
Even in normal circumstances I would rather fix it before it goes
out rather than wait a day to find out.

PE> Maybe MKQWK or MAX will do what you want.

2.02 does what I want actually |-)
And I have said already that more robust netmail I may even do
something about myself too.

PE> You can get setup instructions for both of these programs
PE> from QWKPOINT and MINP_DOS.  I have installed twice from
PE> MINP_DOS, and Bill once.

I've already told you the problems with those two. 2.02 makes far more
sense until I get around to testing whatever is the latest better.

RS> ONLY if PQWK is used, if Bob fucks up with his version of it
RS> for example, you still have a problem. Ditto any other system
RS> used to produce PKTs which get uploaded to your system.

PE> Virtually all systems that produce PKT are from people using
PE> proper point software,

And safety nets are about more than 'virtually all'

PE> where it all fails safe, or more to the point, won't let you
PE> enter netmail without an address.

SOME certainly works like that. Not all tho. It not even that clear
what MKQWK and Max do with that either.

PE> As far as the people using QWK is concerned, MKQWK102 and
PE> Maximus probably do have defaults of the BBS node number.

I have tried both and have forgotten.

PE> As far as Bob's own program is concerned, that's his responsibility,

And safety nets are about what happens when 'his responsibility'
doesnt actually get done right. Nothing ever does ALL the time.

PE> in exactly the same way that all PKTs I send to Dave Hatch are
PE> my responsibility.

And there should be a safety net at that level TOO. And if there was,
presumably we wouldnt be seeing the notorious black hole syndrome.

RS> You are missing the point here completely. YES its desirable to
RS> detect messages which do not have a destination address. BUT its
RS> also desirable to default them to something sensible if they are
RS> missing if you arent doing something more fancy like bouncing them.

PE> All messages that come from another node to me will ALWAYS have
PE> a destination address, as they are two binary words, they ALWAYS
PE> have something in them that can be used as a destination address.

RS> Oh yeah ?  They may well have that field, whether its got valid
RS> data in it is another matter entirely tho.

PE> So long as the net/node is two signed integers, it is valid
PE> as far as I am concerned (ie according to the specs).

And safety nets are about a tad more than that.

PE> It ALWAYS has two signed integers, which ALWAYS comprise an address.

And it aint ALWAYS a valid address.

PE> It is your responsibility to make sure those are not set to
PE> random values.

RS> And robust code is about checking that what is the responsibility
RS> of the originating code has been actually done, particularly when
RS> the consequence of NOT doing that can be spraying a password to a
RS> random fido address.

PE> That's why I wrote PQWK222, Rod.

And there is a tad more in the world than PQWK222 Paul.

PE> There is plenty of software that will do this for you,
PE> PQWK222 being one of them.

RS> And there just happens to be a tad more in the world that that too.

PE> Most of it using mail readers that force you to enter an address. 

Your record has stuck Paul.

(Continued to next message)

--- PQWK202