OT; email attachment

[Ed Cryer]

Why is is that when I add an attachment to an email in Tbird the size of
the email increases disproportionally?
I wanted to send a file 2.63MB big. I put it in an email, and that email
jumped to 3.60MB.
Where has the extra 1MB come from?

Ed

 

[Beauregard T. Shagnasty]

Why is is that when I add an attachment to an email in Tbird the size of
the email increases disproportionally?
I wanted to send a file 2.63MB big. I put it in an email, and that email
jumped to 3.60MB.
Where has the extra 1MB come from?

The binary file needs to be encoded into textual characters for
transmission. Normally, binary files grow about 30% or so. Open up an
email with an attachment and view the source.

That's a newbie question, Ed! You've been around a pretty long time.

 

[Ed Cryer]

The binary file needs to be encoded into textual characters for
transmission. Normally, binary files grow about 30% or so. Open up an
email with an attachment and view the source.

That's a newbie question, Ed! You've been around a pretty long time.

Why does it have to be encoded like that? Why not just send the binary file?

Ed

 

[Paul]

Why is is that when I add an attachment to an email in Tbird the size of
the email increases disproportionally?
I wanted to send a file 2.63MB big. I put it in an email, and that email
jumped to 3.60MB.
Where has the extra 1MB come from?

Ed

In the "Content-Transfer-Encoding" section here, you
can see they have concepts such as '7bit' and '8bit'.

http://en.wikipedia.org/wiki/MIME

At one time, transports across the continent, weren't
necessarily 8 bit transparent. That led to encoding
schemes, so the top-most byte of characters would not
get corrupted. While you wouldn't think that is a problem
today, it's probably because the email system doesn't
take any chances.

As an example of an encoding (an encoding I used
as a discrete choice on Claris Emailer), we have

http://en.wikipedia.org/wiki/Base64

"The number of output bytes per input byte is approximately
4/3 (33% overhead) and converges to that value for a large
number of bytes."

2.63 * 1.333 = 3.51.

In Claris Emailer, you had your choice of encoding schemes,
and I had good luck with the base64 choice. At least, people
seemed to get attachments OK that way (PC user receiving
my Mac emails). My current email tool, doesn't even tell me
what it's doing It's like my email tool was an
appliance or something.

Paul

 

[Paul]

In the "Content-Transfer-Encoding" section here, you
can see they have concepts such as '7bit' and '8bit'.

http://en.wikipedia.org/wiki/MIME

At one time, transports across the continent, weren't
necessarily 8 bit transparent. That led to encoding
schemes, so the top-most byte of characters would not
get corrupted. While you wouldn't think that is a problem
today, it's probably because the email system doesn't
take any chances.

As an example of an encoding (an encoding I used
as a discrete choice on Claris Emailer), we have

http://en.wikipedia.org/wiki/Base64

"The number of output bytes per input byte is approximately
4/3 (33% overhead) and converges to that value for a large
number of bytes."

2.63 * 1.333 = 3.51.

In Claris Emailer, you had your choice of encoding schemes,
and I had good luck with the base64 choice. At least, people
seemed to get attachments OK that way (PC user receiving
my Mac emails). My current email tool, doesn't even tell me
what it's doing It's like my email tool was an
appliance or something.

Paul

And there are plenty of other encodings. When something
gets bigger than it should, pick a matching ratio from
the table

http://en.wikipedia.org/wiki/Binary-to-text_encoding

Paul

 

[Nil]

Why does it have to be encoded like that? Why not just send the
binary file?

Internet email was designed from the very beginning to be a text only
medium. The protocol has been twisted and stretched enough so that it
appears to the end user to contain other things, but that doesn't alter
what's going on behind the curtain.

In other words, that's the way it's always been... and it work well.
You or someone else are free to re-design internet email from scratch
(including all servers and local email agents) if you can find a good
reason to do so. 'Course, then you have to convince the rest of the
world to use it.

 

[J. P. Gilliver (John)]

In message <[email protected]>, Paul <[email protected]>
writes:
[]

At one time, transports across the continent, weren't

Now which continent might that be (-:

necessarily 8 bit transparent. That led to encoding
schemes, so the top-most byte of characters would not
get corrupted. While you wouldn't think that is a problem
today, it's probably because the email system doesn't
take any chances. []
In Claris Emailer, you had your choice of encoding schemes,
and I had good luck with the base64 choice. At least, people
seemed to get attachments OK that way (PC user receiving
my Mac emails). My current email tool, doesn't even tell me
what it's doing It's like my email tool was an
appliance or something.

Paul

In Turnpike I can choose MIME or UUcode. (I also have the option of
splitting into several emails, but usually don't, as virtually no other
software in common use has the ability to put them back together [news
posts ditto].)

Another Turnpike unusualness is the ability to truly embed attachments
within the body; other email softwares _appear_ to do that, but actually
put them at the end, with a link (often "cid:") in the text where they
_seem_ to be embedding. I find that these other softwares, if sent a
Turnpike mail with truly embedded attachment (e. g. a picture), present
the email with the text up to the point of the attachment, then present
two attachments - the actual one, and then the text that is after the
attachment as if it was another attachment.

 

[John Williamson]

Why does it have to be encoded like that? Why not just send the binary
file?

Because there *might* still be a router involved that doesn't understand
8 bit encoding. So it all gets sent as basic 7-bit ASCII.

 

[Mike Barnes]

In Turnpike I can choose MIME or UUcode. (I also have the option of
splitting into several emails, but usually don't, as virtually no other
software in common use has the ability to put them back together [news
posts ditto].)

More to the point, with today's systems there's no *need* to split big
messages like there used to be.

 

[Ed Cryer]

In the "Content-Transfer-Encoding" section here, you
can see they have concepts such as '7bit' and '8bit'.

http://en.wikipedia.org/wiki/MIME

At one time, transports across the continent, weren't
necessarily 8 bit transparent. That led to encoding
schemes, so the top-most byte of characters would not
get corrupted. While you wouldn't think that is a problem
today, it's probably because the email system doesn't
take any chances.

As an example of an encoding (an encoding I used
as a discrete choice on Claris Emailer), we have

http://en.wikipedia.org/wiki/Base64

"The number of output bytes per input byte is approximately
4/3 (33% overhead) and converges to that value for a large
number of bytes."

2.63 * 1.333 = 3.51.

In Claris Emailer, you had your choice of encoding schemes,
and I had good luck with the base64 choice. At least, people
seemed to get attachments OK that way (PC user receiving
my Mac emails). My current email tool, doesn't even tell me
what it's doing It's like my email tool was an
appliance or something.

Paul

I think I'll use Tbird's Filelink system from now on. It allows a choice
of three free hosting sites, uploads only what you send, and adds only a
few decabytes to the email size (just enough to include the web address
for the file).
I've started with Ubuntu1; used 116MB and have 5.4 GB left.

Yes, that's the baby for me from now on.

Ed

 

[Tim Slattery]

In Turnpike I can choose MIME or UUcode.

Use MIME. UUEncode is an older protocol in which the client simply has
to search through the message body to find something that looks like
it might have been UUEncoded, then try to decode it. MIME
(Multipurpose Internet Main Extensions) is a newer protocol that
splits the message into parts that are explicitly delimited and
described, so that the receiving client knows exactly where the parts
are, how to decode them (if necessary), and what to do with them once
they're encoded.