🚀 go-pugleaf

Jonathan Duddington (jsd@argonet.co.uk) wrote:
: I'm writing a bit of code to decode attachments to emails (and news items).

: What *exactly* is UUE encoding?
: What's the algorithm to encode and decode data?

You should be able to get source code for it fairly easily since its part
of all Unices. For a start, try something like ftp.netbsd.org pub/NetBSD/
NetBSD/current/src/bin/uuencode and ..../uudecode. Though it may not be
exactly right.... Its somewhere around there.

There might be an RFC describing it, you'd have to check an RFC index.

: UUE attachments to emails seem to be of the form:

: begin 644 <filename>
:  <UUE data>
: end

: is this always the case?

I think this is the standard way of doing it, yes. 644 refers to the Unix
file access permissions (in this case its something like owner read/read 
and group/other read only). This is useless on Risc OS systems, of course.

: I've seen two ways of including the RiscOS filetype.
: One is to put after the <filename> a comma followed by the filetype number,
: the other is an extra line after the "end" which is of the form:
:    RiscOS filetype : FFF

: Are there others?
: Are there other directives which a UUE decoder should recognise.

There are various different schemes which different readers/uuencoders
on different platforms seem to use. Its just a case of seeing what Arc
programs use and supporting it (or making one up), I suppose...

: And what is MIME? 
: Where can I find the definition?

Multi-Media Internet Mail Extensions. Its defined in a large number of RFCs.
grep and index for MIME and you should catch most of them.

Its a way of embedding various different encodings of data/text in e-mails.
One common way of encoding data with MIME is base 64. This is described
in an RFC somewhere.

sunsite has a complete set of rfs, in /rfc I believe...

Don't ls this directory though :-) Use ls *index* to find the index and
then use that.

They're heaving going.

--
alex@hayward.u-net.com; xelah@ferret.lmh.ox.ac.uk

In article <5o1ni4$bit@news.ox.ac.uk> xelah@ferret.lmh.ox.ac.uk (Alex Hayward) wrote:

> sunsite has a complete set of rfs, in /rfc I believe...
> 
> Don't ls this directory though :-) Use ls *index* to find the index and
> then use that.
> 
> They're heaving going.

How sickening.

Alan

-- 
Alan Wrigley                  alan@cybervillage.co.uk
                              awrigley@nc.com

In article <479acc6791jsd@argonet.co.uk>, Jonathan Duddington
<jsd@argonet.co.uk> wrote:

Hmmm... I wrote a long bit on UUcode not that long ago. Did it get lost?


> I've seen two ways of including the RiscOS filetype.
> One is to put after the <filename> a comma followed by the filetype
> number,
> the other is an extra line after the "end" which is of the form:
>    RiscOS filetype : FFF

It'd be nice if you could support the InfoSys method. It gives you size,
filetype and attributes. Optional CRC too.


> Are there other directives which a UUE decoder should recognise.

The first letter of each line (usually an 'M') is a count of how long the
line is.



-- 
   ___
  /__/         rmurray@argonet.co.uk          (ZFCA V)
 /  \ichard.   http://www.argonet.co.uk/users/rmurray/
     10.74%    AcornCodev1.00: A3 a5000/I240/4/ro+/ro*/tv/sp BB2
                               ed+++(ed) dc400 nl+ EC+++ pc-(pc----)
Tue,17 Jun 1997.21:13:44

In article <479acc6791jsd@argonet.co.uk>, Jonathan Duddington
<jsd@argonet.co.uk> wrote:
> UUE attachments to emails seem to be of the form:
> 
> 
> is this always the case?

I assume you wrote "begin 664 <filename>" there, but NewsAgent picked it up.

(Ho ho! :)

... Clinton Borg, Inhaling is irrelevant.
-- 
David Glover   IRCnet/EFnet IRC: "Mwongozi"    | ICQ: 1104026
Work:  glover@argonet.co.uk                    | From Oxford, UK
       http://www.argonet.co.uk/users/glover/  | ZFC A | FCOS Member
Play:  mwongozi@priderock.pridelands.org       | Certified Sarafinaholic
       http://www.pridelands.org/~mwongozi/    | TLKiaWoL!

In article <na.68b203479b.a40040rmurray@argonet.co.uk>,
 Richard Murray <rmurray@argonet.co.uk> wrote:
> In article <479acc6791jsd@argonet.co.uk>, Jonathan Duddington
> <jsd@argonet.co.uk> wrote:

> Hmmm... I wrote a long bit on UUcode not that long ago. Did it get lost?

The 6.Jun article? I've got that, but it doesn't tell me everything I need to know.  I've found the Unix source and document for UUE now, which looks helpful.

I'm still not sure though why (some) UUE attachments have every line
ending in an 'a' character.

There seem to be two topics:
a.  Basic UUE
b.  Attachments in mail and news messages.

How should an attachment be recognised?
Anything starting with "begin 644 "?
Or only if it's after the sig. (if there is a sig.)?
Does it have to have "644" in the "begin" line?
  (the Unix UUE document doesn't say it must be "644")
If not, then does "begin" at the start of *any* line of the message mean
  an attachment?  Or "begin <number>" ?

> It'd be nice if you could support the InfoSys method. It gives you
> size, filetype and attributes. Optional CRC too.

Where do I find the definition of "infoSys"?
-- 
  Demo version of !Speak from:  http://www.argonet.co.uk/users/jsd
  
  Jon Duddington                jsd@argonet.co.uk
  Coventry, England.            Speech synthesis for Acorn RiscOS computers

Jonathan Duddington (jsd@argonet.co.uk) wrote:
: There seem to be two topics:
: a.  Basic UUE
: b.  Attachments in mail and news messages.

: How should an attachment be recognised?
: Anything starting with "begin 644 "?

Certainly not 644, because 644 represents file access permission bits
which could be anything (well, any three numbers between 0 and 7).

'begin nnn' looks like it might be the best you can get, although you could
perhaps run a few checks to see if the rest looks like UUE (eg check for
equal length lines and 'end').

: Or only if it's after the sig. (if there is a sig.)?

Not as far as I know.

: Does it have to have "644" in the "begin" line?
:   (the Unix UUE document doesn't say it must be "644")

No (see above).

Furthermore, uuencode on this Linux system seems to put the filename
after the 'begin nnn' (I just got begin 600 /dev/stdout).

: If not, then does "begin" at the start of *any* line of the message mean
:   an attachment?  Or "begin <number>" ?

You'd probably have to try it out on any readers you have access too.

I could perhaps post or e-mail a short (1 or 2 character) attachment
from knews if you like? (I'm not using ATM, though).

--
alex@hayward.u-net.com; xelah@ferret.lmh.ox.ac.uk

: The "644" is an octal number giving private/public/read/write access;
: I don't know the bit assignments, but suspect your final option of
: recognising "begin <number>" would be the most appropriate, remembering
: that there will/should be a matching "end" after all the gubbins.

They are permissions in the order owner, group, other. They are octal
numbers. They form a bitfied, read is 4, write is 2, execute permission
is 1.

Somewhat dodgy even under Unix, I'd have thought... Surely you wouldn't
want permissions set to odd values without realising it?

-- 
alex@hayward.u-net.com; xelah@ferret.lmh.ox.ac.uk

In article <479c26d990jsd@argonet.co.uk>, Jonathan Duddington
<jsd@argonet.co.uk> wrote:
> 
> I'm still not sure though why (some) UUE attachments have every line
> ending in an 'a' character.

I /think/ it's just an end-of-line character in case newlines get lost?

> How should an attachment be recognised?
> Anything starting with "begin 644 "?
> Or only if it's after the sig. (if there is a sig.)?
> Does it have to have "644" in the "begin" line?
>   (the Unix UUE document doesn't say it must be "644")
> If not, then does "begin" at the start of *any* line of the message mean
>   an attachment?  Or "begin <number>" ?

The "644" is an octal number giving private/public/read/write access;
I don't know the bit assignments, but suspect your final option of
recognising "begin <number>" would be the most appropriate, remembering
that there will/should be a matching "end" after all the gubbins.

John


-- 
Don't ask the question if you cannot live with the answer.
 __    ZFC: B _               (protovale@argonet.co.uk)
  | _ |_  _  |_||| _| _ _  _|   john@protovale.co.uk
(_j(_)| )| ) | |||(_|| (-`(_|    in and around Oxford

xelah@ferret.lmh.ox.ac.uk (Alex Hayward) writes:

> They are permissions in the order owner, group, other. They are octal
> numbers. They form a bitfied, read is 4, write is 2, execute permission
> is 1.
> 
> Somewhat dodgy even under Unix, I'd have thought... Surely you wouldn't
> want permissions set to odd values without realising it?

I've just tested it on BSDI, and execute is masked off when you decode the
file, but read and write are verbatim. (So you can't accidentaly unpack a
program and then run it, but you umask setting is ignored. 50% secure)

Nick
-- 
#!perl -wlpifinger.liv.ac.uk	# Save this to a file *before* running it
BEGIN{use Socket;$_='YIN;$|=sockef,PZSOCK_STREAM,~proto"tcp"and connecf,pack
"Sna4x8",AZ79,(~host$^I)[4]or die$!YOUT;prinf"/w nickc\r";print"[$^I]"';s/Y/
;select STD/g;s/f/t STDIN/g;s/Z/F_INET,/g;s/~(\w*)/get$1byname/g;eval||die}