home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.next.misc
- Path: sparky!uunet!usc!sdd.hp.com!ux1.cso.uiuc.edu!jeffo
- From: jeffo@ux1.cso.uiuc.edu (J.B. Nicholson-Owens)
- Subject: Re: Encription in 3.0?
- Message-ID: <BuFx43.D05@ux1.cso.uiuc.edu>
- Reply-To: jeffo@ux1.cso.uiuc.edu
- Organization: University of Illinois at Urbana
- References: <1992Sep11.141830.15497@next.cambridge.ma.us> <1992Sep11.170937.7106@leland.Stanford.EDU>
- Date: Sat, 12 Sep 1992 00:52:37 GMT
- Lines: 27
-
- spagiola@frinext.stanford.edu (Stefano Pagiola) writes:
- >Further, even if they are, you may not be able to reliably
- >send NeXTMail because some gateways trash NeXTMail completely.
-
- That would occur with sufficiently long mail too; in other words, it's
- not NeXTmail that is making this happen.
-
- >The bottom line is you need to know exactly what the recipient can or
- >cannot receive. I don't see how knowing whether they can receive
- >encrypted mail would make that any harder. Besides, I imagine that
- >one doesn't send encrypted mail to everybody; more likely, its sent
- >to people you know well, so that you're likely to know whether they
- >can get encrypted mail or not.
-
- This is the same case with NeXTmail. Just replace 'encrypted' with
- NeXTmail. In both cases, non-ASCII, encrypted mail should never be
- assumed to be the default.
-
- From what I read about the whole encryption issue, I came away with
- the feeling that it's a case of the US Government being unable to
- crack this encryption so they're making it illegal to export
- encryption systems using this method (or maybe it's decryption systems
- using NeXT's method, but either way, it means NeXT can't sell the
- encryption stuff outside the USA).
- --
- -- Jeff (jeffo@uiuc.edu)
- -- No NeXTmail please
-