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
RS> what they have in them.

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

Bullshit. You made the completely silly claim that

  PE> Certainly it's of absolutely no use for getting an address from.

When in fact I ALWAYS use it to manually edit the MSGID field into
a To: field for netmail, have almost never had a problem doing that,
in fact only with the tiny number of messages which dont have an MSGID,
I dont NEED to look at the full range of MSGIDs in use to see that your
claim about 'absolutely no use' its a complete load of silly rubbish.

AND I actually replied to a netmail from you which didnt have a MSGID
and there WASNT any full point address of yours available. If there had
been a MSGID I could have used that. Nice theory, pity about the reality.

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.

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

Who gives a shit about 'allowed' ? The practical reality is that
at times they do. In spite of your claim that MSGID has 'absolutely
no use' address wise, the real world out there is a tad different.

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*

PE> The MSGID is allowed to be a fakenet address.

And as I said, in some circumstances it can be useful to get the address
detail out of BOTH the MSGID and the origin line, when they match, assume
that there is an excellent chance its a good address. When they differ it
can be handy to offer the alternatives to the user to choose what one he
wants to use. Nothing remotely like 'absolutely no use' for MSGID.

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.

PE> Nope,

Yep.

PE> people are generating "dud" MSGIDs as a matter of
PE> course, ie ones with internet addresses in them.

People are generating "dud" origin lines as a matter of course, ie ones
with various defects. If you choose to compare the address in the MSGID
with that in the origin line, and warn the user when they dont match,
its nothing remotely like 'absolutely no use' for the MSGID.

PE> Since there's no flag to say whether the address you
PE> are reading from the MSGID is in the current network,
PE> only idiots read the address from there.

Corse there is the tiny matter that thats not the only possibility
Paul. And if you do compare the MSGID and origin line, thats nothing
remotely like 'absolutely no use' for the MSGID, it is in fact a good
way to check for defective origin lines.

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
RS> at all times, you CANT rely on it. Coz they dont.

PE> It's their responsibility to follow the spec,

Nope, the sensible approach for robust code to take is to CHECK to see
if the spec is being adhered to and respond gracefully in the situation
where it is not. Because you know as well as I do that out there in the
real world, you dont actually see perfection that often. THATs what robust
reliable code is about, and the MSGID can be quite useful in MAKING that
code robust and reliable thru the inevitable warts and imperfections seen
with real live messages. Nothing remotely like 'absolutely no use' for MSGID.

PE> you may as well delete the message if it doesn't.

Thats not my idea of a good way to handle email. just delete
anything which isnt absolutely perfect in every way. No thanks.

PE> You may as well say we need kludge lines to make up for
PE> the fact that they have not followed the spec for all the
PE> header information, in case they don't get that right.

Nope, you have a MSGID for various reasons, one of which is dupe
detection. It can be handy to use it for other stuff like checking
the address too. Remarkably simple concept really. And sure beats
just deleting any message with the slightest imperfection.

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 ?

PE> It's either universal, or not required.

Crap, the reality is the message you are REPLYING TO may well not have
it, and so you need to get that from somewhere, and it may well produce
a more robust and reliable system if you get it from BOTH the MSGID and
the origin line and ask the user which to use if they dont match.

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 ?

PE> You only make use of the INTL kludge when you are replying to
PE> netmail!!!

Yes, so your rabbiting on about 'The INTL line is similarly robust'
is irrelevant as far as the message you are REPLYING TO by netmail
is concerned isnt it ?

PE> You make use of the address in the origin line when replying to
PE> echomail!!!

If its right.

PE> It's not that difficult a concept to grasp.

The irrelevance of INTL clearly is tho.

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.


(Continued to next message)

--- PQWK202