Right PN, what is so 'Important' and apparently 'hot' that ....

[#1]

you can't send to a customer as a plain-text email???????
If I'm not at, or can't use, my main PC I use a "check-only" email app to see if any new email is waiting. It allows me to look at the content and,  if necessary,  just delete rubbish or spam.
Late last night I used it, after a gap of nearly a week. There were 2 emails from PN Customer Service title:
"Important information about your PlusNet Service", dated 12/4/12 12:46.
I elected to see what was inside and I just got nothing, blank space in the content window.
I arranged to get a basic text email sent to me. Sure enough, on checking it and its content, I saw what was inside.
That plain email was 2k in size, your email was 11k and my app shows it as "multipart/mixed".
My second line of defence against unwanted or malicious emails is a filter that immediately deletes non-plain email. I am keeping it that way.
So...
1. PN staff reading this. You had better tell me what is so important, right here, right now - if it was just general stuff the automated sender sent out. If you see that it was more personal and sensitive then initiate sending the replacement email in _plain text_.
2. Is this something to do with the Webmail nonsense?
3. Why don't you just act intelligently and sensibly by eschewing frippery and whoo-eee f-a-k-e-b-o-o-c-t-w-a-t-t-e-r-y-like nonsense and communicate with your customers in, to paraphrase, plain honest English language!!!!!

[#2]

Hi fishrow,
I'm not sure what happened but we do always send a plain text version of the html emails and I can assure you that was done in this case. The email was sent to advise you that fibre services are now available in your area, if you're interested in taking them up.
I'm not sure why the plain text version didn't show but would suspect it's something to do with the client you use?

[#3]

it may be plain text Matt, but it is still an image and not text as per this recent one

Quote

Content-Type: text/plain Content-Transfer-Encoding: base64

[#4]

Hi Pierre,
That is text (as per the Content-Type: text/plain in your quote) rather than an image, it's just that you have the base64 encoded text there - it can be decoded by somewhere like http://home.paulschou.net/tools/xlate/ for example (though I'd consider removing it from your post as I just did so and it has your username in it).
Normally the decoding is done by the mail program you use.

[#5]

thanks Matt, removed most of it, but my name is not in the HTML one that I looked at

[#6]

Quote from: Matt

Hi fishrow, I'm not sure what happened but we do always send a plain text version of the html emails and I can assure you that was done in this case. The email was sent to advise you that fibre services are now available in your area, if you're interested in taking them up. I'm not sure why the plain text version didn't show but would suspect it's something to do with the client you use?

Quote

That is text (as per the Content-Type: text/plain in your quote) rather than an image, it's just that you have the base64 encoded text there

thanks for the information.....but
Well, that reply you gave to pierre. There is, IMHO, absolutely no reason whatsoever for encoding in base64.  NONE!!!
You, or the person deciding to inform customers, orginates their thoughts about the new information and inputs the information via keyboard as text, as one does. That text will hopefully be in grammatically constructed plain English. The next process is delivering that simple plain text to the relevant customers.
If the reason for the base64 is that there is some sort of whizz-bang, gimmicky image to demonstrate the alleged features of the related content then.... I don't know what to say, well I do but it will invoke much blue lettering.
Absolutely unnecessary, stupid, useless, bandwidth hogging garbage!!!

[#7]

The reason for the base64 encoding will be the inclusion of the binary images/header in the HTML copy of the message I'd imagine. It's hardly unusual for companies to send emails in HTML format. In this day and age the bandwidth overhead is negligible IMO.

[#8]

If I may jump in here ...
The base64 encode is my fault since all the mails will be sent out using the code I wrote when I first started at Plusnet (or derived from it). 
<techy explanation>
The reason for the base64 is down to the difficulty I had detecting the character set that people were using to paste in text to send the emails (ISO-8859-1, quoted-printable, UTF8, UTF16, Windows-1252 etc), so to make the code as simple as possible, I base64 encoded it all and sent it out as that.
IIRC, the main problem I had was down to the pesky Windows users using MS Word to compose "plain text" mails with the "smart-quotes" option turned on, then copy-pasting that as the text body to be sent. The set of "smart" quotes aren't the same as normal quotes and cause all sorts of havoc if you've set your email content type as text/plain with charset anything-non-windows-specific.
Yes, the best option would be do everything in UTF-8, but if any of you techy peeps can get a stuck-in-their-ways, pointy-haired-boss-type to change the way they insist they must do things then I applaud you and bow down to your superiority
</techy explanation>
Apologies.
Bill

[#9]

Bill lives on.  Ghost in the system

[#10]

Thanks for the clarification Bill

[#11]

Quote from: bhau

If I may jump in here ... The base64 encode is my fault since all the mails will be sent out using the code I wrote when I first started at Plusnet (or derived from it).  Bill

Hmmm?
I left out the rest of the quote but the point raised is apparently _different_ sources within PN for the type or subject of emails sent to customers.
I had the usual emails about pre- and post- subscription payment at end of April. These were readable text I could look at with my checking-app before using the proper Mail app to fetch them.
And so wrt from BPullen  :-

Quote

The reason for the base64 encoding will be the inclusion of the binary images/header in the HTML copy of the messag e I'd imagine.

What binary image?
Or the main point,  WHY an image at all?
If that email stemmed from a  "marketing" desk then I can see where the, emm, "thinking" might be that some "cool" collection of pixels might impress -  as opposed to a sober, succinct, grammatically correct piece of informative text.

[#12]

Quote from: fishrow

Quote from: bhau If I may jump in here ... The base64 encode is my fault since all the mails will be sent out using the code I wrote when I first started at Plusnet (or derived from it).  Bill Hmmm? I left out the rest of the quote but the point raised is apparently _different_ sources within PN for the type or subject of emails sent to customers. I had the usual emails about pre- and post- subscription payment at end of April. These were readable text I could look at with my checking-app before using the proper Mail app to fetch them.

Payment notification emails are sent by our automated systems. Marketing emails are sent using a custom-built bulk mailing application. The latter requires human input which is susceptible to error as per Bill's post.
You can disregard my comments about binary content in light of what Bill has written.

[#13]

ok, thanks

[#14]

Quote from: bhau

Yes, the best option would be do everything in UTF-8, but if any of you techy peeps can get a stuck-in-their-ways, pointy-haired-boss-type to change the way they insist they must do things then I applaud you and bow down to your superiority

Made me smile. 
I might only suggest pointing out to said boss type, that he is working in a communications service industry and might consider, communicating with customers in the way they wish to be communicated with, is a communication service.
Of course this would require aforementioned boss stringing a fact to a logical conclusion, which is perhaps asking too much in this day and age.