PE> The MSGID address is defined to be the address in the ORIGINATING NETWORK.

RS> And THAT is more useful than the OTHER sources, like I said.

PE> Quite often, this is an internet address,

RS> Nothing remotely like quite often.

PE> You obviously don't get NET_DEV.

I dont NEED to get NET_DEV to watch the MSGIDs that I see and see what
they have in them. I normally sent netmail by just editing the MSGID line,
which is right at the top of a message I reply to, to replace the MSGID
with To: and just truncate the crap off the end of the node number etc.
Hardly even is that not possible, and the vast bulk of the time when its
not, its just because the is no MSGID to edit.

RS> And the other sources of the address suffer from the same problem too.

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

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

PE> but it could also be an Adultnet address, Zyxelnet
PE> address, or any other net, with numbers that are
PE> shared by another net, or maybe even a fakenet.

RS> Yes, its possible, no its not that common. Yes
RS> the other sources ALSO have that as possible *TOO*.

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

But not necessarily always usable fidonet.

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> Since there is NO WAY of knowing what net it was
PE> that created the message, you HAVE to treat that
PE> as a character string that is not to be interpreted,

RS> Bullshit. You can treat it as a readily findable
RS> address, which has to be used with the SAME caution
RS> as any other address, *BUT* its more easily findable.

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

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

PE> anything else is irresponsible.

RS> Pathetically bogus form of argument, just stick the word
RS> 'irresponsible' on it and hope that wins the day |-)

PE> Nope, just telling you the truth.

Nope, pathetically bogus form of argument.

PE> On the other hand, the address in the origin line is defined in FTS-4,

RS> And suffers from the SAME deficiencys, and is not as easy to find.

PE> Nope, doesn't have the same deficiencies at all.

The detail is different, it has the SAME deficiency that
it cant just be blindly assumed to be perfect in every way.

AND, as far as your claim that the the MSGID is completely useless
for that info, its still crap if you choose to get that data out of
BOTH those sources and use it *IF* they match, and say get confirmation
from the user when addressing a netmail if they dont match, say offering
a list of what other addresses you have found in the message for the
user to choose from. Your argument has just gone up in flames.

PE> and will be a fidonet address (or more to
PE> the point, an address in the CURRENT network).

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.

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

PE> They are the specs, you see.

They arent always perfectly adhered to. you see.

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

Try taking your dick out of your hand.

PE> The INTL line is similarly robust.

RS> And is nothing remotely like universal.

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

Yes, but that doesnt mean its universal does it ?

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

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

PE> unless you can change all the software in existence
PE> that dupe detects quite validly based on the FTS-9 spec.

RS> Bullshit. Your other option is better MSGID management at your end.

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.

And presumably its possible to know what you did use program wise
in the last 3 years, and work out what algs they use if you want
to. And the risk is absolutely microscopic if you say choose to
start using MSGIDs based on seconds since 1970 today. There is a
theoretical chance of a problem in very low volume echoes, where
you happen to reuse that MSGID in that echo. There is more chance
of a 747 crashing on your house. And even that risk is only for
3 years. All seems utterly anal if you ask me.

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.

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

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

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

--- PQWK202