[Coco] [OT - Sort of?] Sizes of emails sent to this alias

[William Astle]

Actually, no. The Received: line does not include the key. That just 
indicates the cipher algorithm used between the two servers. A key would 
be substantially longer.

The block of text you report is just Dennis's response in base64 
encoding. It is not encrypted at all.

That said, this is way off topic now so we should probably let it drop.

On 2015-11-12 14:14, Stephen H. Fischer wrote:
> What is strange is Dennis's response:
>
> SSByZWFsaXplIHRoYXQgbW9kZXJuIG1hY2hpbmVzIGhhdmUgbXVjaCBtb3JlIG1lbW9yeSB0aGFu
> IGxlZ2FjeSBtYWNoaW5lcywKYnV0IHBsZWFzZSBiZWFyIHdpdGggbWUuCgogCgpJIHdhcyBsb29r
> aW5nIGF0IHRoZSBzaXplIG9mIHRoZSBsYXN0IGZldyBlbWFpbHMgc2VudCB0byB0aGlzIGFsaWFz
> IGFuZCB0aGUKYXZlcmFnZSBzaXplIHdhcyBqdXN0IG92ZXIgMTZLLiAgVGhpcyBtZWFucyB0aGF0
> IG15IG9yaWdpbmFsIENvY28gY291bGQgbm90CmV2ZW4gb3BlbiBtb3N0IG9mIHRoZXNlIG1haWxz
> LiAgSGVoLgoKIAoKQnV0IEkgYWxzbyBub3RpY2VkIHRoYXQgZXZlcnkgbWFpbCBJIHJlY2VpdmUg
> dG8gdGhpcyBsaXN0IGlzIHN0cmljdGx5IGxhcmdlcgp0aGFuIG9yIGVxdWFsIHRvIDEzSyBpbiBz
> aXplLiAgVGhhdCBzZWVtcyBhIGJpdCBleGNlc3NpdmUgc2luY2UgYWxtb3N0IGFsbAp0aGUgY29u
> dGVudCBpbiB0aGUgbWFpbCBpcyB0ZXh0LCBhbmQgbm90IHZlcnkgbXVjaCB0ZXh0IGF0IHRoYXQu
> CgogCgpJIGxvb2tlZCBhdCB0aGUgZW1haWxzIGFuZCBpdCBzZWVtcyBhIGNvbnN0YW50IGFtb3Vu
> dCBvZiBoZWFkZXIgaW5mb3JtYXRpb24KaXMgYmVpbmcgYWRkZWQgYXMgdGhlIG1haWwgaXRlbXMg
> YXJlIGJlaW5nIHJvdXRlZCBhcm91bmQuICBJbiBhIHR5cGljYWwKbWVzc2FnZSwgdGhpcyBhbW91
> bnRzIHRvIDRLIG9yIHNvLgoKIAoKVGhlIHRleHQgb2YgdGhlIGF2ZXJhZ2Ugb2YgdGhlIGxhc3Qg
> MjUgbWFpbHMgSSByZWNlaXZlZCBpcyA8MUsuCgogCgpTbyB0aGVyZSBpcyBzdGlsbCA4SyBvZiBl
> bWFpbCBvdmVyaGVhZCBiZWluZyBhZGRlZCBzb21ld2hlcmUuICBBbnkgaWRlYQp3aGVyZSB0aGF0
> IG1heSBiZSBjb21pbmcgaW4/ICBBbmQgYmVmb3JlIHRoaXMgcXVlc3Rpb24gbmVlZHMgYW4gYW5z
> d2VyLCBkbwpvdGhlciBmb2xrcyB1c2luZyB2YXJpb3VzIGVtYWlsIGNsaWVudHMgc2VlIGFib3V0
> IHRoZSBzYW1lIHNpemUgbWFpbCBpdGVtcz8KCiAKClRoYW5rcyBhbGwsCgpKb2huCgogCgoKLS0g
> CkNvY28gbWFpbGluZyBsaXN0CkNvY29AbWFsdGVkbWVkaWEuY29tCmh0dHBzOi8vcGFpcmxpc3Q1
> LnBhaXIubmV0L21haWxtYW4vbGlzdGluZm8vY29jbwo=
>
> In the headers is the key:
>
> Received: from BLU004-OMC4S28.hotmail.com (blu004-omc4s28.hotmail.com
>   [65.55.111.167])
>   (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits))
>   (No client certificate requested)
>
> So the message is encrypted with the key in the header, what good is that?
>
> SHF
>
> ----- Original Message -----
> From: "James C. Hrubik, Sr." <jimhrubik at earthlink.net>
> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
> Sent: Thursday, November 12, 2015 11:21 AM
> Subject: Re: [Coco] [OT - Sort of?] Sizes of emails sent to this alias
>
>
>> John, as Stephen Fischer replied in response to your original email, that message was just a bit over 5K.  Dennis' response below, containing your original, was just over 6K.  It could be that your email client is attempting to turn the plain text into rich text, or it could be that your ISP is adding some junk to it in delivery.  Based on what I have seen in responses, it takes a humongous reply to bump the additional count more than 1K, which appears to be a minimum reported size for the content of a new message.  Remember back to your BASIC programming -- 1 byte per char -- and look at the number of chars in the plain text of the message, as you noted.  The extra padding is being added somewhere outside the CoCoList.
>>
>>
>> -----Original Message-----
>>> From: Dennis Bathory-Kitsz <bathory at maltedmedia.com>
>>> Sent: Nov 12, 2015 8:51 AM
>>> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
>>> Subject: Re: [Coco] [OT - Sort of?] Sizes of emails sent to this alias
>>>
>>> John,
>>>
>>> This is a mailing list that goes through several stages, all of which are
>>> maintained in the full header.
>>>
>>> In the header, there's the list information itself (name, sub, unsub, archive,
>>> post, help); the message ID (thread, language, subject, etc.), the original
>>> path of user to ISP (which can travel through several servers, as yours does),
>> >from there to list (servers, time, date, etc.), spam and virus checks (with
>>> status flags), and the route back out from the list to the user, which in my
>>> case also invokes spam and virus checks (the same ones, as it's my server).
>>> Time and date are embedded at many steps as well. You can read all of this by
>>> viewing the full header. I use Squirrel Mail, which has a 'view full header'
>>> option.
>>>
>>> On the other hand, you'll notice that the messages themselves are all
>>> converted to plaintext (reducing size significantly for those who post in
>>> richtext/html) and almost all attachments are stripped (ditto).
>>>
>>> Dennis
>>>
>>>
>>> On Wed, November 11, 2015 4:46 pm, John Guin wrote:
>>>> I realize that modern machines have much more memory than legacy machines,
>>>> but please bear with me.
>>>>
>>>> I was looking at the size of the last few emails sent to this alias and the
>>>> average size was just over 16K.  This means that my original Coco could not
>>>> even open most of these mails.  Heh.
>>>>
>>>> But I also noticed that every mail I receive to this list is strictly larger
>>>> than or equal to 13K in size.  That seems a bit excessive since almost all
>>>> the content in the mail is text, and not very much text at that.
>>>>
>>>> I looked at the emails and it seems a constant amount of header information
>>>> is being added as the mail items are being routed around.  In a typical
>>>> message, this amounts to 4K or so.
>>>>
>>>> The text of the average of the last 25 mails I received is <1K.
>>>>
>>>> So there is still 8K of email overhead being added somewhere.  Any idea
>>>> where that may be coming in?  And before this question needs an answer, do
>>>> other folks using various email clients see about the same size mail items?
>
>