PE> Would everyone please make sure that when they are sending netmail
PE> messages they use a proper (ie fidonet-listed) address, instead of
PE> just sending messages to random destinations to people who don't
PE> want to receive them. Anyone who doesn't have the technology to
PE> accomplish this, please contact me and we'll see if we can find
PE> some appropriate technology to solve the problem.

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.

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

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

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

Essentially the code which uses the To: field should be robust enough
that it doesnt just pick up crap from the message, it has to be basically
a node number.

RS> While its obviously best if the sender gets it right, there is no
RS> substitute for a safety net under that, particularly when you have
RS> a wild variety of different systems being used to create the netmail.

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

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

PE> This applies quadruply to messages to Areafix, where failure
PE> to specify either 3:711/934, or something innocuous like your
PE> own address, could cause your password to be compromised.

RS> Dunno, I have always explicitly NOT included a destination address
RS> in that situation because I thought thats what was supposed to be
RS> done. In other words if there was no destination address at all,
RS> it was supposed to default to YOUR address. Which is just what
RS> a message to AREAFIX is supposed to have. Why is it randomly
RS> netmailling that to anything it feels like ?  Thats quite mad.

PE> Oh, so old versions of PQWK did have a default destination
PE> addresss, and that was my address?  I wasn't aware of that.

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

PE> Anyway, that obviously changed

Looks like another support for not having bothered to upgrade.

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

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

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),
PE> and the message could go anywhere.

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

PE> You should always specify a destination address.

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

PE> People who have a password protected session with me get their
PE> mail processed automatically, unlike everyone else, so it is
PE> important not to compromise your password.

RS> Yes, by defaulting the destination to YOUR node number.

PE> Then if you send a message to "Trev Roydhouse" and you leave out the
PE> address, you will never know that your message didn't get anywhere. 

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

PE> At least if the message comes back to you the next day, you can take
PE> some action.

Yes, but I was talking there about what happens if you DONT explicitly
do that.

--- PQWK202