Always wondered...

An email is sent in HTML with attached files totaling 22MB. The size of the
sent file, as it went out, and the received file, was 33MB.

What is the email overhead all about? Would sending in plain text lessen the
overhead?

TIA

Boris wrote:
> Always wondered...
>
> An email is sent in HTML with attached files totaling 22MB. The size of the
> sent file, as it went out, and the received file, was 33MB.
>
> What is the email overhead all about? Would sending in plain text lessen the
> overhead?
>
> TIA

BASE64 is a common encoding.

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

And you can see in the worked examples, it expands
the message a fair amount, encoding things that way.

BASE64 is a six bit code and can travel on seven bit transparent
or eight bit transparent channels. The BASE64 table consists of
62 characters and two punctuation characters, for a total of 64.
If you're on a channel with robbed bit signaling, BASE64 still gets
through, unharmed.

Paul

On 4/29/2021 8:40 PM, Boris wrote:
> Always wondered...
>
> An email is sent in HTML with attached files totaling 22MB. The size of the
> sent file, as it went out, and the received file, was 33MB.
>
> What is the email overhead all about? Would sending in plain text lessen the
> overhead?
>
> TIA
>

The problem is that HTML-formatted messages cause bloat. That is,
according to a study I did in 2019, an HTML-formatted message is -- on
the average -- 16.0 times the size of the plain-text message containing
the same information.

Furthermore, E-mail applications too often generate erroneous HTML. For
every 1000 bytes, an average HTML-formatted message contains 7.3 HTML
syntax errors.

See my <http://www.rossde.com/internet/ASCIIvsHTML.html> for details on
how I conducted my study, what I found, and what I concluded.

--
David E. Ross
<http://www.rossde.com/>

News item: "Conservative U.S. House Republicans to
form 'America First' caucus"

During the 1930s, America First was a pro-Nazi political movement.

On Thu, 29 Apr 2021 at 21:56:54, David E. Ross
<not_me@not_there.invalid> wrote (my responses usually follow points
raised):
>On 4/29/2021 8:40 PM, Boris wrote:
>> Always wondered...
>>
>> An email is sent in HTML with attached files totaling 22MB. The size of the
>> sent file, as it went out, and the received file, was 33MB.
>>
>> What is the email overhead all about? Would sending in plain text lessen the
>> overhead?
>>
>> TIA
>>
>
>The problem is that HTML-formatted messages cause bloat. That is,

That's not the explanation in this case: note that Boris was talking
about _attachments_. As Paul has explained, that's due to the encoding
necessary to send non-text material over what - in a few places at least
- is still a text-only medium. (Base64 probably; the old UUcode is even
less efficient, but these days is rarely used, and many email/news
clients can no longer decode it.)

>according to a study I did in 2019, an HTML-formatted message is -- on
>the average -- 16.0 times the size of the plain-text message containing
>the same information.

(Did that include the plain-text copy that is also often included
[unknown by the sender in most cases]?)
>
>Furthermore, E-mail applications too often generate erroneous HTML. For
>every 1000 bytes, an average HTML-formatted message contains 7.3 HTML
>syntax errors.

And - if the HTML is autogenerated - phenomenal inefficiency. From what
I've seen, from about 6 to 20 or 30 unnecessarily nested DIV structures,
and frequently at least 3 nested TABLE structures.
>
>See my <http://www.rossde.com/internet/ASCIIvsHTML.html> for details on
>how I conducted my study, what I found, and what I concluded.
>
>--
>David E. Ross
><http://www.rossde.com/>
>
>News item: "Conservative U.S. House Republicans to
>form 'America First' caucus"
>
>During the 1930s, America First was a pro-Nazi political movement.

There must come a point - and I'd say we've already passed it - where
just because some phrase was used by the Nazis, it must be vilified. (To
give another example: some decades ago, looking at an exhibition of the
engineering challenges involved in building the channel tunnel, my
mother was somewhat displeased to see the phrase "final solution"
heading the panel showing what they did.) I know nothing of the
present-day "America First" organisation, but wouldn't automatically
assume it is Nazi-like just because it uses that phrase (which I didn't
know the history of anyway).
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

_IMPORTANT INSTRUCTIONS_ BEFORE ALL TECHNICAL INTERVENTION ON THE [CASE CUT THE
ELECTRICAL FEEDING REGULAR MAINTENANCE PROVIDES THE GOOD WORKING OF A CASE (SEE
INSTRUCTIONS BOOK) [seen on bacon cabinet in Tesco (a large grocery chain)]

"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote

| >
| >The problem is that HTML-formatted messages cause bloat. That is,
| | That's not the explanation in this case: note that Boris was talking
| about _attachments_.

I think it's both. Base64 adds 1/3, plus a line return for
every 76 characters. It works by splitting bytes and assigning
a character for every 6 bits, rather than every 8 bits. That
allows it to convert binary files into a printable-text version.
So 22 MB should come out to less than 30 MB. That implies
that the HTML was also a mess. HTML does tend to be very
bloated. The real question is what kind of nut sends 22 MB
attachments?

On Fri, 30 Apr 2021 at 08:48:25, Mayayana <mayayana@invalid.nospam>
wrote (my responses usually follow points raised):
>"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote
>
>| >
>| >The problem is that HTML-formatted messages cause bloat. That is,
>|
>| That's not the explanation in this case: note that Boris was talking
>| about _attachments_.
>
> I think it's both. Base64 adds 1/3, plus a line return for

What Boris actually said was "An email is sent in HTML with attached
files totaling 22MB." So the attachments were not necessarily HTML.

>every 76 characters. It works by splitting bytes and assigning
>a character for every 6 bits, rather than every 8 bits. That
>allows it to convert binary files into a printable-text version.
>So 22 MB should come out to less than 30 MB. That implies
>that the HTML was also a mess. HTML does tend to be very

Though only uses plain text characters, so doesn't _need_ to be encoded.
Though I'd certainly agree tends to be very bloated, if automatically
generated (which virtually all HTML is these days, certainly the
non-plain-text parts of emails).

>bloated. The real question is what kind of nut sends 22 MB
>attachments?
>
(-: Agreed - to some extent. (I'd certainly hesitate, not least because
some of those I correspond with, their ISP has a size limit around 30M.)
Mined Yew, I can't stand most of the third-party upload sites either,
because of their script-soddenness. (I'd put the file on my website, but
not everyone has set one of those up.)
>
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Does God believe in people?

Boris <nospam@nospam.invalid> on Fri, 30 Apr 2021 03:40:17 -0000 (UTC)
typed in alt.windows7.general the following:
>Always wondered...
>
>An email is sent in HTML with attached files totaling 22MB. The size of the
>sent file, as it went out, and the received file, was 33MB.
>
>What is the email overhead all about? Would sending in plain text lessen the
>overhead?

Yes. There's a lot in HTML which you don't read [formatting etc}
but which has to be included in the encoded text.
--
pyotr filipivich
This Week's Panel: Us & Them - Eliminating Them.
Next Month's Panel: Having eliminated the old Them(tm)
Selecting who insufficiently Woke(tm) as to serve as the new Them(tm)

On 4/30/21 12:11 AM, this is what Paul wrote:
> Boris wrote:
>> Always wondered...
>>
>> An email is sent in HTML with attached files totaling 22MB.  The size of the sent file, as it went out, and the received file, was 33MB.
>>
>> What is the email overhead all about?  Would sending in plain text lessen the overhead?
>>
>> TIA
>
> BASE64 is a common encoding.
>
> https://en.wikipedia.org/wiki/Base64
>
> And you can see in the worked examples, it expands
> the message a fair amount, encoding things that way.
>
> BASE64 is a six bit code and can travel on seven bit transparent
> or eight bit transparent channels. The BASE64 table consists of
> 62 characters and two punctuation characters, for a total of 64.
> If you're on a channel with robbed bit signaling, BASE64 still gets
> through, unharmed.
>
>    Paul
Not only does the BASE64 add bloat, but some HTML emails will also send the email body in plain text also giving you two copies of the body.
All in all you get a lot more bang for your buck!.

--
Linux Mint Cinnamon 20.1 64bit, Dell Inspiron 5570 laptop
Quad Core i7-8550U, 16G Memory, 512G SSD, 750G & 1TB HDDs
*I collect teddy bears.

On 4/30/2021 5:48 AM, Mayayana wrote:
> "J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote
>
> | >
> | >The problem is that HTML-formatted messages cause bloat. That is,
> |
> | That's not the explanation in this case: note that Boris was talking
> | about _attachments_.
>
> I think it's both. Base64 adds 1/3, plus a line return for
> every 76 characters. It works by splitting bytes and assigning
> a character for every 6 bits, rather than every 8 bits. That
> allows it to convert binary files into a printable-text version.
> So 22 MB should come out to less than 30 MB. That implies
> that the HTML was also a mess. HTML does tend to be very
> bloated. The real question is what kind of nut sends 22 MB
> attachments?

When I want to send a very large file, I do not attach it to an E-mail
message. Instead, I upload the file to my Web site and send a message
with a link to the file. In the message, I also request the recipient
to let me know that he or she has downloaded the file so that I can then
remove it from my Web site.

I follow a similar process when I want to send my annual newsletter.
The last newsletter was about 93 KB. With 97 recipients, sending the
actual newsletter would have meant over 9 MB going out over the Internet
all at once. Instead, the newsletter was a subset of my Web site. The
message was less than 1 KB with only 93 KB going out at once.

--
David E. Ross
<http://www.rossde.com/>

News item: "Conservative U.S. House Republicans to
form 'America First' caucus"

During the 1930s, America First was a pro-Nazi political movement.

"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote

| What Boris actually said was "An email is sent in HTML with attached
| files totaling 22MB." So the attachments were not necessarily HTML.
| No, the email is HTML, which is far more bloated than
plain text, despite usually looking the same. The attachment
is encoded in Base64 and appears as a separate section of
text in the email body. So it's 29+ MB + the HTML of the email.
The numbers still seem off, but maybe the email was very
bloated or had embedded pictures.

Boris <nospam@nospam.invalid> wrote:

> An email is sent in HTML with attached files totaling 22MB. The size
> of the sent file, as it went out, and the received file, was 33MB.
>
> What is the email overhead all about? Would sending in plain text
> lessen the overhead?

All e-mail, and I mean ALL e-mail, is sent as text. HTML is text with
tags. Attachments get encoded into long text strings placed in MIME
parts within the body of the message. Base64 encoding increases size by
about 37%. You message will bloat up 137%. Your message has so many
bytes (doubled if you send using HTML) plus the size of the file (as
shown in your file system) is *NOT* the size of your sent message.
Whether you send at HTML or plain text, any attachments get encoded as
long text strings (which you see inside a MIME part within the message
if you look at the raw source of the message).

If you send as plain text:
X bytes for your message + 137% file size of each attachment.

If you send in HTML format:
X bytes for your plain text message + X bytes for HTML message + N bytes
for HTML overhead (text for tags and arguments) + 137% file size of each
attachment.

Send as plain text: one copy of your message gets sent. Send as HTML:
two copies of your message gets sent. Attachments are separate, but
will enlarge by 137%, or more.

Note: To ensure recipients can read your HTML message, it should contain
a text part and a MIME part for the HTML format. This ensures that the
recipient can read your message. They may not have an e-mail client
that supports HTML, or they configured their e-mail client to not
support HTML. Sending as HTML means you double the size of your
message: one text/plain MIME part for a plain text version of your
message, and a text/html MIME part that duplicates your message. For
most messages, the duplication that doubles the size of your message due
to using HTML formatting is unimportant. A message might be 15KB in
size, and double to 30K if you use HTML, but 30K is still small for
e-mail size. Attachments are not duplicated as those are stored as
separate MIME parts in your message whether you send as text or
text+HTML.

While your e-mail provider might allow you to send messages larger than,
say, 10MB, and perhaps you don't care about consuming lots of e-mail
storage despite you obviously already have the file outside of e-mail,
the recipient could have quotas that limit the size of incoming e-mails
as well as the max size of storage in their online account. If they are
restricted to 10MB incoming e-mails, their e-mail server will reject
your oversized incoming messages. Even if your large e-mails are
accepted, the attachments will consume some of their storage quota the
result of which could block reception of later e-mails (they've run out
of storage quota, so future e-mails get rejected since there is no more
space to store them).

Upload the file to online file storage (OneDrive, Google Drive, Dropbox,
etc) where the file is shared, and give the URL to the file in your
message. Not only do you reduce the size of your e-mail storage,
especially for a file that you obviously have separate of e-mail, you
are also being polite to the recipient by not bloating the size of their
e-mail storage, especially if they may not want your file, or want a
choice of whether or not to retrieve it. The recipient may not have as
large quotas regarding size of incoming message or for e-mail storage as
do you.

The larger the message, the longer it takes to download. E-mail servers
throttle the client connections, so the massive number of concurrent
users get some share of processing time by the server. The admins want
their e-mails servers to remain responsive, and that is a priority over
abusing e-mail for file transfer. In addition, even without throttling,
large message take time to transfer due to bandwidth. A recipient may
not have as high the speed for an Internet connection as do you, so it
take them a lot longer to download your huge message compared to how
long it takes for you to send. Retrieving a huge e-mail can take so
long that it will fail, and then keep getting retried each time the
recipient's e-mail client re-polls a mail server. The client tries to
retrieve a new message, the message starts downloading, but the client
does another re-poll before the message completed getting downloaded, so
the client aborts that download on the next poll which result in
starting the message download all over again. This repeats indefinitely
with the client never managing to download the message (often because
the user configured their e-mail client to poll at excessively short
intervals, like 1 or 5 minutes instead of 10 minutes, or longer). There
is no resume function in e-mail.

E-mail was NOT designed for file transfer. MIME was added to e-mail to
allow a simple method to send documents or images, not for transferring
videos, large installers, or other huge files. Upload large files to
online storage, and provide the URL to it in your message.

Don't use e-mail for file transfer unless the files are small, like
under 7 MB (since a 7 MB attachment will bloat to 10 MB, and many
recipients have a 10 MB max size quota on incoming e-mails). Also
remember the recipient may have slower bandwidth, so it will take longer
to download your message than it took you to upload.

On 2021-04-30, Boris <nospam@nospam.invalid> wrote:
> An email is sent in HTML with attached files totaling 22MB. The size of the
> sent file, as it went out, and the received file, was 33MB.
>
> What is the email overhead all about? Would sending in plain text lessen the
> overhead?

HTML is a rogue format for email, which was intended for plain text. HTML
just adds needless bloat. (I use an email client, alpine, which renders
everything in plain text. Your fancy formatting doesn't show up.)

Hard to believe anyone would not know about Base64 encoding or the
fact that email was not designed for transmission of binary files
and cannot be assumed to be 8-bit clean. Next you'll be telling
us you don't know what the RFCs are. Sad.

--
------------------------------------------------------------------------------
Roger Blake (Posts from Google Groups killfiled due to excess spam.)

18 Reasons I won't be vaccinated -- https://tinyurl.com/ebty2dx3
Covid vaccines: experimental biology -- https://tinyurl.com/57mncfm5
The fraud of "Climate Change" -- https://RealClimateScience.com
Don't talk to cops! -- https://DontTalkToCops.com
------------------------------------------------------------------------------

On Fri, 30 Apr 2021 at 12:54:55, Mayayana <mayayana@invalid.nospam>
wrote (my responses usually follow points raised):
>"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote
>
>| What Boris actually said was "An email is sent in HTML with attached
>| files totaling 22MB." So the attachments were not necessarily HTML.
>|
> No, the email is HTML, which is far more bloated than
>plain text, despite usually looking the same. The attachment
>is encoded in Base64 and appears as a separate section of
>text in the email body. So it's 29+ MB + the HTML of the email.
>The numbers still seem off, but maybe the email was very
>bloated or had embedded pictures.
>
No; I share your abhorrence of HTML; I could well believe the factor of
16 times (for autogenerated HTML, which all is, anyway) you mentioned in
an earlier post. (Plus the plain text version usually included too, so
making 17 times in total.) But that doesn't explain the attachments;
that's due to the BASE64 encoding.
>
EVEN IF THE TEXT HAD NOT BEEN HTML, THE 22 MB OF ATTACHMENTS WOULD STILL
HAVE GROWN DUE TO THE ENCODING. The text being HTML does make it many
times bigger, but unlikely currently to get anywhere near that size.
(Not impossible, I guess.) And I'd still agree with those saying you
shouldn't send 33 MB emails.
>
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"Victory does not bring with it a sense of triumph - rather the dull numbness
of relief..." - Cecil Beaton quoted by Anthony Horowitz, RT 2015/1/3-9

In article <20210430175809@news.eternal-september.org>
Roger Blake <rogblake@iname.invalid> wrote:
>
> On 2021-04-30, Boris <nospam@nospam.invalid> wrote:
> > An email is sent in HTML with attached files totaling 22MB. The size of the
> > sent file, as it went out, and the received file, was 33MB.
> >
> > What is the email overhead all about? Would sending in plain text lessen the
> > overhead?
>
> HTML is a rogue format for email, which was intended for plain text. HTML
> just adds needless bloat. (I use an email client, alpine, which renders
> everything in plain text. Your fancy formatting doesn't show up.)
>
> Hard to believe anyone would not know about Base64 encoding or the
> fact that email was not designed for transmission of binary files
> and cannot be assumed to be 8-bit clean. Next you'll be telling
> us you don't know what the RFCs are. Sad.
>

Another tekkie moron who thinks that non-tekkies are stupid and
will burn in Hell.

Roger Blake <rogblake@iname.invalid> wrote in
news:20210430175809@news.eternal-september.org:

> On 2021-04-30, Boris <nospam@nospam.invalid> wrote:
>> An email is sent in HTML with attached files totaling 22MB. The size
>> of the sent file, as it went out, and the received file, was 33MB.
>>
>> What is the email overhead all about? Would sending in plain text
>> lessen the overhead?
>
> HTML is a rogue format for email, which was intended for plain text.
> HTML just adds needless bloat. (I use an email client, alpine, which
> renders everything in plain text. Your fancy formatting doesn't show
> up.)
>
> Hard to believe anyone would not know about Base64 encoding or the
> fact that email was not designed for transmission of binary files
> and cannot be assumed to be 8-bit clean. Next you'll be telling
> us you don't know what the RFCs are. Sad.
>

Do you feel better now?

Boris wrote:
> Roger Blake <rogblake@iname.invalid> wrote in
> news:20210430175809@news.eternal-september.org:
>
>> On 2021-04-30, Boris <nospam@nospam.invalid> wrote:
>>> An email is sent in HTML with attached files totaling 22MB. The size
>>> of the sent file, as it went out, and the received file, was 33MB.
>>>
>>> What is the email overhead all about? Would sending in plain text
>>> lessen the overhead?
>> HTML is a rogue format for email, which was intended for plain text.
>> HTML just adds needless bloat. (I use an email client, alpine, which
>> renders everything in plain text. Your fancy formatting doesn't show
>> up.)
>>
>> Hard to believe anyone would not know about Base64 encoding or the
>> fact that email was not designed for transmission of binary files
>> and cannot be assumed to be 8-bit clean. Next you'll be telling
>> us you don't know what the RFCs are. Sad.
>>
>
> Do you feel better now?

On my other computer, I used to have an email tool,
where there were four options offered for attachments.

And all I remember at the time, was "these options are
uniformly awful!". There really isn't a good option
you're missing, for direct transport.

That's why I knew about the BASE64 thing, because it
was one of the awful options offered on my other email tool.
The reason I would select BASE64, is "all my recipients
can decode this".

You have the choice of chopping large files into pieces.

8GB file ---> ZIP, store mode, max 2GB out ---> file.zip
file.001
file.002
file.003

Then, if your provider absolutely insisted on some email limit,
you could send each file.* as a separate message. Note that,
with such schemes, one of the files is "master", and opening
the master, then makes the menu available for unpacking
the original 8GB file in my example. It may insist all the
members be present, before unpacking the archive and making
the original 8GB file.

Using "store mode" in this context, is a "quick" way of
breaking an 8GB file, into four 2GB pieces. That means
no attempt is made to compress anything. The files are
plaintext. You can also select a compression mode, and
the output could be four files which are each smaller
than expected.

But there will still be overhead when they're encoded
in materials such as BASE64.

When you do this ad-infinitum, email transport reliability
might be an issue. Normally, email server design is one
of the most conservative transports around. Organizations
are proud of their ability to "not lose your email, once
it is received". At work, they would say "wait 12 hours"
or "wait 24 hours" before declaring a medical emergency,
as the queues on the machines needed a lot of time to drain.

But if for some reason, the email thing wasn't reliable,
and "a few emails in a burst of emails got lost", you can
use PAR and parity blocks (with some of the emails containing
parity blocks), and send 10% more messages than are necessary.
Then, if up to 10% of the sent messages are lost, you ask the
PAR tool "whether enough redundancy is available for recovery"
and the "message" you were sending might actually be complete
and recoverable. This represents a kind of "abuse" of email,
but it may be an option of you have no FTP servers of your own
(no Dropbox, Google Drive, Skydrive to share files). I believe
it's possible to control distribution on a Cloud server, so
that only a recipient with a token can get a file, and then
the file can be quite large.

Even Firefox had a scheme, but it's quite possibly turned off now.

https://blog.mozilla.org/blog/2020/09/17/update-on-firefox-send-and-firefox-notes/

Paul

On 2021-05-02, Boris <nospam@nospam.invalid> wrote:
> Do you feel better now?

No. It is a sad state of affairs that the know-nothings form the bulk
of the internet population. It was a mistake opening up the net to
the general public back in the 90s.

--
------------------------------------------------------------------------------
Roger Blake (Posts from Google Groups killfiled due to excess spam.)

18 Reasons I won't be vaccinated -- https://tinyurl.com/ebty2dx3
Covid vaccines: experimental biology -- https://tinyurl.com/57mncfm5
The fraud of "Climate Change" -- https://RealClimateScience.com
Don't talk to cops! -- https://DontTalkToCops.com
------------------------------------------------------------------------------

"Roger Blake" <rogblake@iname.invalid> wrote

| No. It is a sad state of affairs that the know-nothings form the bulk
| of the internet population. It was a mistake opening up the net to
| the general public back in the 90s.
|

Not to worry. They should be by to give you your
pills and put you to bed any minute now.

VanguardLH <V@nguard.LH> wrote in news:1ntqmqcn1x34x$.dlg@v.nguard.lh:

> Boris <nospam@nospam.invalid> wrote:
>
>> An email is sent in HTML with attached files totaling 22MB. The size
>> of the sent file, as it went out, and the received file, was 33MB.
>>
>> What is the email overhead all about? Would sending in plain text
>> lessen the overhead?
>
> All e-mail, and I mean ALL e-mail, is sent as text. HTML is text with
> tags. Attachments get encoded into long text strings placed in MIME
> parts within the body of the message. Base64 encoding increases size by
> about 37%. You message will bloat up 137%. Your message has so many
> bytes (doubled if you send using HTML) plus the size of the file (as
> shown in your file system) is *NOT* the size of your sent message.
> Whether you send at HTML or plain text, any attachments get encoded as
> long text strings (which you see inside a MIME part within the message
> if you look at the raw source of the message).
>
> If you send as plain text:
> X bytes for your message + 137% file size of each attachment.
>
> If you send in HTML format:
> X bytes for your plain text message + X bytes for HTML message + N bytes
> for HTML overhead (text for tags and arguments) + 137% file size of each
> attachment.
>
> Send as plain text: one copy of your message gets sent. Send as HTML:
> two copies of your message gets sent. Attachments are separate, but
> will enlarge by 137%, or more.
>
> Note: To ensure recipients can read your HTML message, it should contain
> a text part and a MIME part for the HTML format. This ensures that the
> recipient can read your message. They may not have an e-mail client
> that supports HTML, or they configured their e-mail client to not
> support HTML. Sending as HTML means you double the size of your
> message: one text/plain MIME part for a plain text version of your
> message, and a text/html MIME part that duplicates your message. For
> most messages, the duplication that doubles the size of your message due
> to using HTML formatting is unimportant. A message might be 15KB in
> size, and double to 30K if you use HTML, but 30K is still small for
> e-mail size. Attachments are not duplicated as those are stored as
> separate MIME parts in your message whether you send as text or
> text+HTML.
>

Thanks for answering the 'overhead' question.

> While your e-mail provider might allow you to send messages larger than,
> say, 10MB, and perhaps you don't care about consuming lots of e-mail
> storage despite you obviously already have the file outside of e-mail,
> the recipient could have quotas that limit the size of incoming e-mails
> as well as the max size of storage in their online account. If they are
> restricted to 10MB incoming e-mails, their e-mail server will reject
> your oversized incoming messages. Even if your large e-mails are
> accepted, the attachments will consume some of their storage quota the
> result of which could block reception of later e-mails (they've run out
> of storage quota, so future e-mails get rejected since there is no more
> space to store them).
>
> Upload the file to online file storage (OneDrive, Google Drive, Dropbox,
> etc) where the file is shared, and give the URL to the file in your
> message. Not only do you reduce the size of your e-mail storage,
> especially for a file that you obviously have separate of e-mail, you
> are also being polite to the recipient by not bloating the size of their
> e-mail storage, especially if they may not want your file, or want a
> choice of whether or not to retrieve it. The recipient may not have as
> large quotas regarding size of incoming message or for e-mail storage as
> do you.
>
> The larger the message, the longer it takes to download. E-mail servers
> throttle the client connections, so the massive number of concurrent
> users get some share of processing time by the server. The admins want
> their e-mails servers to remain responsive, and that is a priority over
> abusing e-mail for file transfer. In addition, even without throttling,
> large message take time to transfer due to bandwidth. A recipient may
> not have as high the speed for an Internet connection as do you, so it
> take them a lot longer to download your huge message compared to how
> long it takes for you to send. Retrieving a huge e-mail can take so
> long that it will fail, and then keep getting retried each time the
> recipient's e-mail client re-polls a mail server. The client tries to
> retrieve a new message, the message starts downloading, but the client
> does another re-poll before the message completed getting downloaded, so
> the client aborts that download on the next poll which result in
> starting the message download all over again. This repeats indefinitely
> with the client never managing to download the message (often because
> the user configured their e-mail client to poll at excessively short
> intervals, like 1 or 5 minutes instead of 10 minutes, or longer). There
> is no resume function in e-mail.

Above three paragraphs considered. Recipient said they had enough 'room'
to accept whatever I sent. Yes, moving large files up and down via email
is agony.

>
> E-mail was NOT designed for file transfer. MIME was added to e-mail to
> allow a simple method to send documents or images, not for transferring
> videos, large installers, or other huge files. Upload large files to
> online storage, and provide the URL to it in your message.

While I don't like online storage, for storage purposes, for transfers, I
agree. But, this recipient only knows how to get files when attached to
email. Windows Explorer is new to her.
>
> Don't use e-mail for file transfer unless the files are small, like
> under 7 MB (since a 7 MB attachment will bloat to 10 MB, and many
> recipients have a 10 MB max size quota on incoming e-mails). Also
> remember the recipient may have slower bandwidth, so it will take longer
> to download your message than it took you to upload.

Thanks for the reply, VanguardLH.

"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote in news:rBYabMBKOAjgFwnB@
255soft.uk:

> On Fri, 30 Apr 2021 at 08:48:25, Mayayana <mayayana@invalid.nospam>
> wrote (my responses usually follow points raised):
>>"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote
>>
>>| >
>>| >The problem is that HTML-formatted messages cause bloat. That is,
>>|
>>| That's not the explanation in this case: note that Boris was talking
>>| about _attachments_.
>>
>> I think it's both. Base64 adds 1/3, plus a line return for
>
> What Boris actually said was "An email is sent in HTML with attached
> files totaling 22MB." So the attachments were not necessarily HTML.
>
>>every 76 characters. It works by splitting bytes and assigning
>>a character for every 6 bits, rather than every 8 bits. That
>>allows it to convert binary files into a printable-text version.
>>So 22 MB should come out to less than 30 MB. That implies
>>that the HTML was also a mess. HTML does tend to be very
>
> Though only uses plain text characters, so doesn't _need_ to be encoded.
> Though I'd certainly agree tends to be very bloated, if automatically
> generated (which virtually all HTML is these days, certainly the
> non-plain-text parts of emails).
>
>>bloated. The real question is what kind of nut sends 22 MB
>>attachments?
>>
> (-: Agreed - to some extent. (I'd certainly hesitate, not least because
> some of those I correspond with, their ISP has a size limit around 30M.)
> Mined Yew, I can't stand most of the third-party upload sites either,
> because of their script-soddenness. (I'd put the file on my website, but
> not everyone has set one of those up.)
>>

My ISP has an outbound limit of about 35MB. I've tested it.

I rarely move large amounts of data over email, but the recipients that
request data from me aren't particularly interested in 'pc stuff' (as much as
I am). To each his own. They don't do much more than browse, email, or
Microsoft Office stuff. They don't know about forums (yuck) let alone
newsgroups.

I don't have a website. So it's just another thing to maintain, that would
be rarely used, and for which most of my friends/relatives wouldn't
understand, except my millenium and younger kids and nephews, who are in IT,
and who would understand how to use. But they never ask for my files of old
songs or scanned in prints of their older relatives from much earlier
decades. :-)

I do have an acquaitance with Dropbox. My youngest son recently passed away
unexpectedly, and had music files on Soundcloud. When he was around, he
would send me links to music he had placed on Soundcloud, but he left no ID
or PW on Soundcloud; I could only listen to his voice and instrument playing,
I couldn't download and save from Soundcloud. I asked my oldest son, an IT
guy, what could he do to help me save his younger brother's creations that
were on Soundcloud. My oldest son was able to figure out how get into
Soundcloud such that he could zip up the files from Soundcloud, and he then
placed them on Dropbox for me to download. I had to create a Dropbox account
to get the zip file. I now have them locally so I can listen to my son's
voice anytime.

I was surprised that when I went back to Dropbox, because besides the zip
file, there were 1222 pics that were uploaded from my hard drive. I guess I
didn't pay enough attention as to what folder Dropbox was going to
interrogate/upload when I created a Dropbox account. Shame on me.

Thanks for the reply.

"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote in news:rBYabMBKOAjgFwnB@
255soft.uk:

> On Fri, 30 Apr 2021 at 08:48:25, Mayayana <mayayana@invalid.nospam>
> wrote (my responses usually follow points raised):
>>"J. P. Gilliver (John)" <G6JPG@255soft.uk> wrote
>>
>>| >
>>| >The problem is that HTML-formatted messages cause bloat. That is,
>>|
>>| That's not the explanation in this case: note that Boris was talking
>>| about _attachments_.
>>
>> I think it's both. Base64 adds 1/3, plus a line return for
>
> What Boris actually said was "An email is sent in HTML with attached
> files totaling 22MB." So the attachments were not necessarily HTML.
>
>>every 76 characters. It works by splitting bytes and assigning
>>a character for every 6 bits, rather than every 8 bits. That
>>allows it to convert binary files into a printable-text version.
>>So 22 MB should come out to less than 30 MB. That implies
>>that the HTML was also a mess. HTML does tend to be very
>
> Though only uses plain text characters, so doesn't _need_ to be encoded.
> Though I'd certainly agree tends to be very bloated, if automatically
> generated (which virtually all HTML is these days, certainly the
> non-plain-text parts of emails).
>
>>bloated. The real question is what kind of nut sends 22 MB
>>attachments?
>>
> (-: Agreed - to some extent. (I'd certainly hesitate, not least because
> some of those I correspond with, their ISP has a size limit around 30M.)
> Mined Yew, I can't stand most of the third-party upload sites either,
> because of their script-soddenness. (I'd put the file on my website, but
> not everyone has set one of those up.)
>>

My ISP has an outbound limit of about 35MB. I've tested it.

I rarely move large amounts of data over email, but the recipients that
request data from me aren't particularly interested in 'pc stuff' (as much
as
I am). To each his own. They don't do much more than browse, email, or
Microsoft Office stuff. They don't know about forums (yuck) let alone
newsgroups.

I don't have a website. So it's just another thing to maintain, that
would
be rarely used, and for which most of my friends/relatives wouldn't
understand, except my millenium and younger kids and nephews, who are in
IT,
and who would understand how to use. But they never ask for my files of
old
songs or scanned in prints of their older relatives from much earlier
decades. :-)

I do have an acquaitance with Dropbox. My youngest son recently passed
away
unexpectedly, and had music files on Soundcloud. When he was around, he
would send me links to music he had placed on Soundcloud, but he left no
ID
or PW on Soundcloud; I could only listen to his voice and instrument
playing,
I couldn't download and save from Soundcloud. I asked my oldest son, an
IT
guy, what could he do to help me save his younger brother's creations that
were on Soundcloud. My oldest son was able to figure out how get into
Soundcloud such that he could zip up the files from Soundcloud, and he
then
placed them on Dropbox for me to download. I had to create a Dropbox
account
to get the zip file. I now have them locally so I can listen to my son's
voice anytime.

I was surprised that when I went back to Dropbox, because besides the zip
file, there were 1222 pics that were uploaded from my hard drive. I guess
I
didn't pay enough attention as to what folder Dropbox was going to
interrogate/upload when I created a Dropbox account. Shame on me.

Thanks for the reply.

Mayayana <mayayana@invalid.nospam> wrote:
> "Roger Blake" <rogblake@iname.invalid> wrote
>
> | No. It is a sad state of affairs that the know-nothings form the bulk
> | of the internet population. It was a mistake opening up the net to
> | the general public back in the 90s.
> |
>
> Not to worry. They should be by to give you your
> pills and put you to bed any minute now.

Unintended self-satire is always a pleasure to observe.

On 2021-05-04, Frank Slootweg <this@ddress.is.invalid> wrote:
> Unintended self-satire is always a pleasure to observe.

Yes, and "Boris" is quite good at doing it to himself, and is a
case in point.

--
------------------------------------------------------------------------------
Roger Blake (Posts from Google Groups killfiled due to excess spam.)

18 Reasons I won't be vaccinated -- https://tinyurl.com/ebty2dx3
Covid vaccines: experimental biology -- https://tinyurl.com/57mncfm5
The fraud of "Climate Change" -- https://RealClimateScience.com
Don't talk to cops! -- https://DontTalkToCops.com
------------------------------------------------------------------------------

Roger Blake <rogblake@iname.invalid> wrote:
> On 2021-05-04, Frank Slootweg <this@ddress.is.invalid> wrote:
> > Unintended self-satire is always a pleasure to observe.
>
> Yes, and "Boris" is quite good at doing it to himself, and is a
> case in point.

<whoosh!>

Frank Slootweg wrote:
> Roger Blake <rogblake@iname.invalid> wrote:
>> On 2021-05-04, Frank Slootweg <this@ddress.is.invalid> wrote:
>>> Unintended self-satire is always a pleasure to observe.
>> Yes, and "Boris" is quite good at doing it to himself, and is a
>> case in point.
>
> <whoosh!>

You kids play nice now.

The purpose of the group is to help somebody.
IDK. The OP maybe.

At this point, we're firmly in the "mission accomplished" zone.

Paul