salmi@dicomed.UUCP (John Salmi) (06/25/85)
(Please forgive me if this is a re-hash of an earlier posting) Is is possible to use crypt with mail? THe experience I've had says no. Our guru has gone off to greener pastures. The BIG GUYS upstairs want to do this. Do I tell them Yes or No? I have not been able to locate any documentation on crypt. Does any exist? Thanks! -- john salmi {ihnp4,mgnetp}!dicomed!john dicomed corp minneapolis "... and if it doesn't work, there may be something wrong with it."
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (06/28/85)
> Is is possible to use crypt with mail? Depends on the mail system you use. Look for an "-x" option in the "mail" manual page, or for an "xsend" utility. > The BIG GUYS upstairs want to do this. Do I tell them Yes or No? Tell them Yes; it might be fun to read their mail when they think it can't be read. > I have not been able to locate any documentation on crypt. It should be in your UNIX manual, or on-line via "man crypt".
bsw@whuts.UUCP (WALDEN) (06/28/85)
> Is is possible to use crypt with mail? THe experience I've had says no. > Our guru has gone off to greener pastures. > > john salmi {ihnp4,mgnetp}!dicomed!john > dicomed corp > minneapolis > You cannot directly mail encrypt files. Mail(1) (AT&T's at least) will strip out all NUL characters before sending mail. So if crypt(1) generates any NULs the person receiving that mail will not be able to decrypt it correctly even with the correct key. You'll have to write two programs: One to replace NULs with someother character sequence before mailing. And another that puts the NULs back in to the file after reading that sequence. The same goes if you want to mail cpio(1) type files. Brian Walden AT&T-Bell Labs ...!ihnp4!whuts!bsw
steven@luke.UUCP (Steven List) (06/29/85)
In article <518@dicomed.UUCP> salmi@dicomed.UUCP (John Salmi) writes: >Is is possible to use crypt with mail? THe experience I've had says no. >-- > john salmi {ihnp4,mgnetp}!dicomed!john Wouldn't your purpose be served by using something like: crypt < mailfile | btoa | mail on the sending side and the reverse on the receiving side? It shouldn't be too difficult to write a mail front end program (similar in concept to the `smail' program I posted recently?) to perform all this stuff for you at both ends. -- *** * Steven List @ Benetics Corporation, Mt. View, CA * Just part of the stock at "Uncle Bene's Farm" * {cdp,greipa,idi,oliveb,sun,tolerant}!bene!luke!steven ***
ugthomas@sunybcs.UUCP ( Timothy Thomas) (06/30/85)
> Is is possible to use crypt with mail? THe experience I've had says no. > Our guru has gone off to greener pastures. > > The BIG GUYS upstairs want to do this. Do I tell them Yes or No? I have > not been able to locate any documentation on crypt. Does any exist? There used to be on our system a enroll, xsend, and xget which would send crypted mail. You would 'enroll', whereby it would ask you for a key. Then any secret mail sent to you by xsend could be read by xget. This is no longer supported on our system for some reason, but it should work. -- ____________ ____/--\____ \______ ___) ( _ ____) __| |____/ / `--' "I'm a programmer not a Doctor!" ) `|=(- \------------' Timothy D. Thomas SUNY/Buffalo Computer Science UUCP: [decvax,dual,rocksanne,watmath,rocksvax]!sunybcs!ugthomas CSnet: ugthomas@buffalo, ARPAnet: ugthomas%buffalo@CSNET-RELAY
jbc@mcc-db.UUCP (John B. Chambers) (07/01/85)
> > Is is possible to use crypt with mail? THe experience I've had says no. > > Our guru has gone off to greener pastures. > > > > john salmi {ihnp4,mgnetp}!dicomed!john > > dicomed corp > > minneapolis > > > > You cannot directly mail encrypt files. Mail(1) (AT&T's at least) will > strip out all NUL characters before sending mail. So if crypt(1) generates > any NULs the person receiving that mail will not be able to decrypt it > correctly even with the correct key. > > You'll have to write two programs: One to replace NULs with someother character > sequence before mailing. And another that puts the NULs back in to the file > after reading that sequence. The same goes if you want to mail cpio(1) type > files. > > Brian Walden > AT&T-Bell Labs > ...!ihnp4!whuts!bsw You should be able to adequately adapt uuencode and uudecode for the purposes of transmission, but I certainly wouldn't rely on crypt(1) to protect anything I really treasured. -- John B. Chambers, Microelectronics and Computer Technology Corp., Austin, TX {ihnp4,seismo,ctvax}!ut-sally!mcc-db!jbc, jbc@ut-sally.ARPA, chambers@mcc.ARPA
root@bu-cs.UUCP (Barry Shein) (07/02/85)
Re: Someone asked how to send encrypted mail, another pointed out the serious problem with sending non-printing characters an encryption program is likely to generate. See uuencode/uudecode, works wonderfully with mailed files, converts all non-printables into an encoded printable format (with a 2:3 expansion I believe), uudecode even strips the header (strips everything up to a magic little line uuencode put in.) It also keeps the records short (I think 45 chars by default) which is useful if you have to forward over some routes, especially BITNET spools, some of which will chop at 80 (punch spools ya know.) I even moved it to our IBM3081 to aid using SMTP as a 'poor person's FTP' (yes we have a license...geeez!) tho there are limits to ascii->ebcdic conversions. Note: regardless of the names uu(en/de)code have nothing directly to do with UUCP other than their origin [ie. works over any net], just handy UNIX tools. -Barry Shein, Boston University
herbie@watdcsu.UUCP (Herb Chong [DCS]) (07/05/85)
In article <455@bu-cs.UUCP> root@bu-cs.UUCP (Barry Shein) writes: >It also keeps the records short (I >think 45 chars by default) which is useful if you have to forward over >some routes, especially BITNET spools, some of which will chop at 80 >(punch spools ya know.) I even moved it to our IBM3081 to aid using SMTP >as a 'poor person's FTP' (yes we have a license...geeez!) tho there are >limits to ascii->ebcdic conversions. uuencoded files have problems in BITNET file transfers if you don't send in PUNCH or PRINT format because trailing blanks are stripped and need to be replaced before uudecodeing. also, UREP allows each site to define their own ASCII-EBCDIC translation tables (yes, there's more than one valid translation). both these problems have bitten me before when sending data to other Unix systems via BITNET. Herb Chong... I'm user-friendly -- I don't byte, I nybble.... UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!water!watdcsu!herbie CSNET: herbie%watdcsu@waterloo.csnet ARPA: herbie%watdcsu%waterloo.csnet@csnet-relay.arpa NETNORTH, BITNET, EARN: herbie@watdcs, herbie@watdcsu
uddeborg@chalmers.UUCP (G|ran Uddeborg) (07/06/85)
In article <231@mcc-db.UUCP> jbc@mcc-db.UUCP (John B. Chambers) writes: . . . >You should be able to adequately adapt uuencode and uudecode for the purposes >of transmission, but I certainly wouldn't rely on crypt(1) to protect anything >I really treasured. I wouldn't rely on a computer to do that. Would you? -- "For me, UNIX is a (way of) being." G|ran Uddeborg UUCP: {seismo,philabs,decvax}!{mcvax,ukc,unido}!enea!chalmers!uddeborg CSnet: uddeborg@chalmers.csnet