PE> You obviously don't get NET_DEV.

RS> I dont NEED to get NET_DEV to watch the MSGIDs that I see and see what

You do need to if you want to see a wider range of MSGIDs than
your tunnel vision allows.

PE> No they don't, they're always fidonet.

RS> I meant that its a problem that you cant just use it mindlessly.
RS> They can have dud fakenet addresses etc. So you have to look at
RS> what you get and check it in some way. Just like with the MSGID.

Nope, they're not allowed to have fakenet addresses in them.

RS> Atleast with the MSGID its rather easier to be sure what the address
RS> actually is, even if you do have to allow for the possibility that
RS> its not the RIGHT address. *BUT* thats JUST as much a problem with
RS> the OTHER candidate addresses TOO, and they are harder to find *TOO*

The MSGID is allowed to be a fakenet address.

PE> Nope, the other addresses are governed by appropriate specs
PE> and guaranteed to be addresses in the current network.

RS> Nice theory, pity about the reality tho. In fact out there in
RS> the real world its MUCH less common for the MSGID to be dud.

Nope, people are generating "dud" MSGIDs as a matter of course,
ie ones with internet addresses in them.  Since there's no flag
to say whether the address you are reading from the MSGID is in
the current network, only idiots read the address from there.

RS> Nope, you cant rely on that either. Whatever FTS-4 may say.

PE> Err Rod, it's because of FTS-4 that you can rely on it.

RS> Nope, if they dont all perfectly adhere to it at
RS> all times, you CANT rely on it. Coz they dont.

It's their responsibility to follow the spec, you may as well
delete the message if it doesn't.  You may as well say we need
kludge lines to make up for the fact that they have not followed
the spec for all the header information, in case they don't get
that right.

PE> Try looking "spec" up in the dictionary.

RS> Try taking your dick out of your hand.

You try doing both.

PE> The INTL line is similarly robust.

RS> And is nothing remotely like universal.

PE> Crap.  You can't send international netmail without it,

RS> Yes, but that doesnt mean its universal does it ?

It's either universal, or not required.

PE> and if you're sending inter-zone netmail, then you don't need it anyway.

RS> Yes, so if you are say replying to an echomail message by netmail, and
RS> that original is in a different zone, you have a problem dont you ?

You only make use of the INTL kludge when you are replying to
netmail!!!  You make use of the address in the origin line
when replying to echomail!!!  It's not that difficult a 
concept to grasp.

PE> This is true.  Unfortunately I have no idea of the current
PE> status of my system, having run MSGID-generating software
PE> long before I took any notice of what algorithm it was using.

RS> And presumably its possible to know what you did use program wise
RS> in the last 3 years, and work out what algs they use if you want

I'm not dead sure.  I tried out a variety at one stage, e.g.
SQED or something.

PE> There was something I was going to respond to in the
PE> second part of your message, but I won't bother because
PE> I can't be bothered going and joining them together.

RS> Oh well, I wont be hanging myself any time soon.

And I won't be replying to it any time soon, whoopy do.

PE> the 150-line limit causes REAL problems but only fixes
PE> IMAGINARY problems.

RS> Tell that to those using mail readers with 150 line limits.

Like who?  Your imaginary friends again.  When was the last time
you saw one of them complain about not being able to see more 
than the first 150-lines?  I think I'll start making that my
own policy, not to read/reply to any more than the first of
your multipart messages.  Why didn't I think of that before?
BFN.  Paul.
@EOT:

---