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