RW>> Thanks, but that doesn't answer the question of; why isn't the flag RW>> implemented in an all zones nodelist?
TB> Well, this Userflag is used for a long time now, and some systems TB> carry this flag over years now. As 5001.005 says, it is common for TB> all zones.
I understand that it may have existed for a long time. At the bottom of my nodelist, issued by the Z1C every week, there are definitions of flags used in the nodelist. But the non-existence of a definition for the oft seen flag of ENC is not there.
RW>> If it's good for the goose, why not the gander?
TB> Because the sysop needs a special setup for routing encrypted netmail TB> and encrypted echomail.
Encrypted echomail? That's a new one.
TB> It's a bit like the actually TOR-System.
I don't know of it.
TB> You need a entry-point and a exit-point, and your system has to know, TB> if the routing has to be forwarded with encrypted mail or not.
TB> Let me give you an example:
TB> 1.) your system gets an pgp-encrypted echomail, but the public key TB> doesn't match. Basically, your system bounces the echomail, and it TB> will get lost. If you carry the enc flag, you've got to route the TB> echomail, if it is not possible, you've got to inform the sysop about TB> the bounce, and try to find an encrypted route to the exit-point, TB> means that sysop, witch has the public key to decrypt the message.
I'd like to have one of those witches myself.
TB> 2.) your system gets a zip-encrypted netmail via unprotect inbound TB> Usually this netmail will be bounced, because it comes up via TB> unprotect inbound. But, because of your enc-flag you've got to route TB> or crash the netmail to the specific exit-system.
Not if I don't agree to do so.
TB> 3.)
MvdV>>> ENC This node accepts inbound encrypted mail and will route MvdV>>> it MvdV>>> like other mail
TB> in the meaning of, find a system wich also carrys the enc-flag, or TB> crash the mail to the exit-node.
Or drop it into the bit bucket.
RW>> Basically, I don't see a need for separate documentation when it can RW>> all be had in one without having to go to any one document that only RW>> the uber *Cs use in their nodelist compilation.
TB> Well, to document the technical needs is a completly different point, TB> then compiling the daily nodelist.