Text 7811, 77 rader
Skriven 2014-12-28 02:06:20 av Torsten Bamberg (2:240/5832)
   Kommentar till text 7808 av Roy Witt (1:387/22)
Ärende: ENC user flag
=====================
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>> It's a bit like the actually TOR-System.
 RW> I don't know of it.
http://en.wikipedia.org/wiki/Tor_(anonymity_network)

 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?

Bye/2 Torsten

... MAILBOX02: Up 20d 09h 48m (BTUp2-1.3)
--- GoldED+/EMX 1.1.4.7
 * Origin: DatenBahn BBS (2:240/5832)