RS> Wouldnt it be a heap easier to have a fail safe at your end for
RS> the netmail which doesnt have a proper destination address ?

PE> There is technology to do so, but I don't have it.

RS> Dunno, something odd is going on here. I have NEVER included a node
RS> number on my AREAFIX messages, coz I assumed that they werent meant
RS> to have one, coz they werent going anywhere. Thats not memory either,
RS> I have check on the old ones. They have always worked too and they
RS> are one of the few netmails where you can be completely sure if the
RS> work or not coz you get a response if they do.

PE> Like I say, I don't know how that happens, whether just by luck
PE> the last thing on the stack was 3:711/934 so you got away with
PE> it, or whether there is some default set that I wasn't aware of.

Frank appeared to be saying that a message to AREAFIX fanged his
arse without a To: field yesterday, so presumably you must have
changed something at your end since ALL of mine worked. And I
have sent quite a few. Or thats the result of the mappings you
said you didnt add for him coz he is one of the later arrivals.

PE> Actually, it's not so much to make sure it's nodelisted,
PE> but something you entered, rather than just random.
PE> The random address could be a valid nodelisted address.

RS> I doubt that later is worth worry about too much. The main problem is
RS> just no To: field at all. Its very easy to forget to include it. Its
RS> far less likely that you include a dud one. And certainly better to
RS> handle the dud cases you can and just accept that some you cant catch.

PE> Exactly, which is why I wrote PQWK222.

But not what you said in the para above on random numbers.

PE> All except one prompt for a netmail address which you have to
PE> enter, so it's not a problem.

RS> Still got sweet fuck all to do with the desirability of ALWAYS
RS> having a safety net when its practical.

PE> There is in PQWK222.

Thats no use for those who us something other than PQWKanything now is it ?

RS> Dunno, I did check that the QWK form of the message doesnt have any
RS> To: field at all, didnt check what ends up in the PKT. I'll check
RS> that out and if this is still in the mail message, I have forgotten.

I didnt forget but couldnt find InspectA so hadnt got around to it. Some
stupid problem with some fucked choice of archive file name as I recall.

PE> Anyway, that obviously changed

RS> Looks like another support for not having bothered to upgrade.

PE> Relying on some unknown defaulting mechanism rather than
PE> using PQWK222 which definitely has a default is up to you,

Its not unknown if its worked every time its been used. In a
situation where its always obvious if it works or not.

PE> so long as the unknown default keeps working, all's OK.

Yep, and it SHOULD default like that anyway coz not everyone
uses PQWKanything. It makes absolutely no sense to fire it at
random into Fido with a password in it at all.

PE>> (or there is a latent bug in the old version),

RS> Dunno. It depends essentially on how the AREAFIX messages are handled.

PE> There is no difference on this end.

Welp, there is no doubt whatever that 2.21 works somehow. And does
what its supposed to too, so presumably thats not an accident.

PE> All the nodes and points connected to me are just normal
PE> Fidonet nodes, and my system, like all other Fidonet systems,
PE> expects them to be obeying the protocols.

The AREAFIX convention aint a normal Fido protocol.

PE> If you want a message to go to 3:711/934, there are a
PE> couple of fields in the PKT that need to be filled in.
PE> I can't second-guess those fields from here.

Of course you can from the AREAFIX To: field. Or more legalistically
the system as a whole can, which isnt the same thing as you. It does
anyway by treating the AREAFIX To: field as a special case.

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?

We were discussing why it worked before that Paul.

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

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

PE>> You should always specify a destination address.

RS> And code should always react gracefully to the inevitable imperfect
RS> data thats bound to be seen, particularly when its generated by a
RS> human. Even when its generated by an automatic process, it should
RS> ALWAYS fail safe when thats possible.

PE> Yep, it fails perfectly safe at the moment.
PE> Any problem at all and it comes straight back to you.

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

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.

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

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


(Continued to next message)

--- PQWK202