= Сообщение: 1689 из 7125 ====================================== FTSC_PUBLIC = От : Torsten Bamberg 2:240/5832 28 Dec 14 02:06:20 Кому : Roy Witt 28 Dec 14 02:06:20 Тема : ENC user flag FGHI : area://FTSC_PUBLIC?msgid=2:240/5832+549f646d На : area://FTSC_PUBLIC?msgid=1:387/22+549f465a = Кодировка сообщения определена как: CP866 ================================== ============================================================================== Hallo Roy! Samstag, den 27. Dezember 2014 17:43, Roy Witt schrieb an Torsten Bamberg:
TB>> Because the sysop needs a special setup for routing encrypted netmail TB>> and encrypted echomail. RW> Encrypted echomail? That's a new one. Well, did you ever took a look into golded.cfg? Afaik, (don't bother me if not) the rot13 encryption is one of the oldest and unsecured encryptions systems and it is implementad into golded. We've got also pgp and other encryption methods for echomail. It's not new, but unusual. All this need to be usual for the future. But this a political issue and I don't discuss the need of encryption.
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. RW> I'd like to have one of those witches myself. Well, ;-) the word like 'which/that/those' I ment. Sorry for this. I'm honesly not used to write english without a technical meaning.
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. RW> Not if I don't agree to do so. You must'd carry the enc flag, don't you?
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. RW> Or drop it into the bit bucket. Just take a look above. If you don't carry the enc-flag you can drop anything into the big green bucket.
Anyway, the need of enc is more actual than it was in the early 90's of the last century. GCHQ/NSA/BND and also ICANN and others are hot to get all data about any individual data communication. We've got to diskuss about a 'fido-enc-bucket' without political issues. How can we adopt actual encrytion systems into our systems without to forget our differnt software.
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. RW> ???? Well, we've got to document our technical needs. Theese technical needs are documented by the FTSC (Thanks for that). Theese technical documents are handeld in differnt dokuments, and are numberd. If an NC/RC/ZC compress theese informations and insert them into the network-/region-/zonelist than this is because she/he wants this to do. But reading the compressed form of the technical needs inside our nodelist doesn't mean that any fido-sysop has ignore any other rules. Any fido-sysop has to know about the policys and Ftsc-Documents even the Ftsc-proposals as well. Just take a look into Policy4.07.
RW> Have a day! RW> R\%/itt - K5RXT
RW> * Origin: South-Texas Area Hub - Gulf Coast Backbone (1:387/22) Does the city of Austin still got this nice metal-club in the middle of mainsteet?
