Looking for a crappy email client [closed] - email

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I wrote some code to send email as both HTML & Text, and I am having having trouble testing it.
On Thunderbird and Outlook, there is an option to view as plain-text, however I have a feeling that they are being smart and doing something to the plain text (because it looks slightly different in thunderbird than in outlook).
What's the crappiest email client out there? One that simply has no HTML support and would not be smart enough to convert HTML to text by itself.
I'd like to see the worst solution.

mail on *nix is an option. Use it on a terminal, and there's no way you'll get automatic conversion of HTML!
( If mail is too crappy, you can try another text based email client, that is actually easy to use and often installed - Alpine ( although, if you want to err on the side of crappy go for Pine instead ) )

Lotus Notes. Even simple HTML is likely to be mauled. This would be a perfect application, and the only suitable purpose it could possibly fulfill. While you're at it, you can get a great example of how to design a bad interface.
Are you dealing with technical people with this? I can't imagine many people use something like Mutt except for CS professors and people who read SO, but realistically not many common readers (other than internal company email at places with limited computers like POS systems) use non-HTML mail.
Also, look into how it looks without externally linked images because most webmail providers (and others) block it.

The view plain text option in Thunderbird actually displays the plain text copy from the Multi-part MIME. That should be fine for what you're looking to do.
Outlook actually converts the HTML version into plain text and does not show the plain text version that was delivered in the MIME.
Bottom line, just use Thunderbird.

Make sure to test your mail in both outlook 2003 and 2007.
Outlook 2003 uses Internet Explorer to render HTML mails.
Outlook 2007 uses Word to render HTML mails. It doesn't support stuff like positioning of elements, so if you heavily rely on css, outlook 2007 is going mess things up for sure.

If you want to actually see the Text part of a multi-part email (an email sent with both an HTML version and a Text version in the same message), then I'd recommend having a look at Fastmail.fm. They have an option to show nothing but the Text part of the multipart.
If on the other hand you are looking for an email client with the worst heuristics to convert HTML to Text - then I'm going to take a guess and second Lotus Notes.

You could look for elm or pine on *nix - both very basic.

Whenever I want to see what the message actually is (not just what it looks like) in Thunderbird, I just use the view message source option. That gives me the plain text and the HTML source.
If you just want mangled e-mail, though, Lotus Notus is highly recommended.

Mail on *nix. Very, VERY crappy.

Related

Outlook email format changes when forwarded, How to format in such a way its not modified

The automated outlook emails using pywin32 and plain HTML were great till people started using it for forwarding and reply, Once you forward all the HTML formats are getting stripped and the borders of the table suddenly disappears. The way around is to go to your outlook settings and disable the option "Reduce message size by removing format information not necessary for the message".
The question is how to format the email so that it wont be lost when forwarded and make the format information necessary for the message ?
I have found out a work around though, It is observed that outlook is stripping of those styles which are defined in style block, If the styles are defined embedded in tags its escaping the stripping. As of now I have taken this approach

Exchange Disclaimer plain text formatting

I am using a Transport Rule in Exchange Server 2010 to append some HTML to the end of our company emails. This is working just fine when an email is sent out as HTML. When the message is plain text, the HTML and images are converted into [links] and it looks a mess.
Is it possible to apply conditional formatting to append an HTML message at the end of HTML emails, and a different layout for plain text emails? Failing that, can I get it to simply ignore the rule if the message isn't in HTML?
Thank you
I have discovered that the only way to achieve what I was after is by using a 3rd party add-on. So the answer to the question really is "no" for both parts!
3rd party tools like Symprex or Exclaimer may help people out in a similar situation.

Handling Outlook-style quoting in Gnus

Since a lot of my workflow is Emacs-based, I'm trying to migrate to using Gnus at the office. Most people here use Outlook and with it rely on the Microsoft-style top-quoting in replies.
I've set things up quite nicely with markdown automatically converted to HTML when I post etc. The problem is that I end with the text version of the quoted messages in the reply thread instead of the original HTML email. This is not really appreciated by the other participants in the thread.
My question is: Is there a way in which I can preserve the original HTML in the reply-chain when replying using top-posting style?
I've been looking at various ways of doing it myself, but there is actually a lot of work doing it right, as it involves parsing the original HTML and inserting my message in the right place, etc. So I was hoping that someone else might have done this already.
After a long time, this question has remained unanswered so I concluded that no one has had the need to do this.
So, I resorted to solve it myself. My solution involves taking the message that is written, passing it through muse in order to format it as HTML, then passing this generated HTML together with the original HTML source of the original mail and send it to an external application that I wrote that parses the HTML and merges them into a new HTML document. This HTML is them returned and is then inserted into the email buffer before being submitted.
There was quite a lot of hackery needed in order to make sure that attachments are handled correctly, but in the end it all worked out well.
The code is available at: https://github.com/lokedhs/gnus-outlook-style

Multipart email best practices

I am developing a web app that sends out emails. Currently, all emails have a HTML part.
Questions:
Is it important to include a text part also?
Do you include both?
Is just removing all the tags from the HTML message and adding a few line breaks good enough to create a text part from the HTML part?
Thanks, Kevin
Is it Important to include a text part also? It's a best practice to provide a plain text version of the email. However, in my opinion and in this day and age, I would guess that it is not such a big deal to leave it out. However, if you know more about your recipients' email clients (eg: if you're sending the emails in a corporate environment and everyone uses a particular email client), then you can determine how necessary it really is.
Do you include both? The .net framework (which I use) provides an AlternateView class (MSDN) that allows you to easily specify copies of an email in different formats. It makes things very easy to include a plain text version of the email. Perhaps you can find something similar in apache/php.
Is just removing all the tags from the HTML message and adding a few line breaks good enough to create a text part from the HTML part? Technically, yes but be VERY CAREFUL here. A complex HTML layout that has been converted to plain text will look absolutely terrible if all you do is remove HTML tags and pile the content together. It really depends on your content and how much you can do to manipulate said content. Also, take a look at Campaign Monitor'ssuggestions for formatting plain text emails.
One final word of advice for you HTML emails to test, test, and then test some more. When you're finished testing, test again. HTML emails will render differently in different email clients and, if some of your recipients are using Microsoft Word 2007/2010 then you can forget about web standards. I urge you to take a look at Campaign Monitor's Guide to CSS support in email.

Is there a Platform-independent Web-based replacement for Word Templates?

The above Title is my Manager's words, not mine. :)
This is a follow-up to a question that I posted previously. After reading my assessment on the impacts of converting Word Templates from PC to Mac, I have now been asked to investigate whether Word Templates can be replaced with a "Platform-independent Web-based solution" (her words, not mine). She has suggested using Adobe Forms (ie. Adobe Designer).
Personally, I think the only truly platform-independent web-based solution is text files or html forms. What do other people think?
It's called WordprocessingML (aka. WordXML, WordML)...
Overview of WordprocessingML [Word 2003 XML Reference] at http://msdn.microsoft.com/en-us/library/aa212812(office.11).aspx.
MSDN Search for "WordML" at http://social.msdn.microsoft.com/Search/en-US?query=WordML&ac=3
It could be called XForms...
The Web was suppose to be platform-independent electronic documents. In other words, if you truly want platform-independence, then I agree with you and your forms should be in HTML. Yet, HTML forms are really not a good development platform. That is why Adobe, Microsoft, and others provide "form" solutions. XForms is an attempt to make developing and using HTML forms more flexible, overcome its limitations, and provide a platform-independent object model for completing HTML forms. You might want to look at XForms at http://www.w3.org/MarkUp/Forms/.
But, I wouldn't call it PDF
In my opinion, working with PDF files is difficult. I have not looked at the file format specification, but I heard it is not trivial. Moreover, you need a custom editor and you are locked into one vendor, which is Adobe. (Yet, there are other open-source and vendors who support the file format.) Adobe is not know for creating programs that are easy to use.
My Suggestion
If you are already using Word, then moving to WordML should be fairly easy. You can easily convert your existing Word documents into WordML by simply saving them as XML from the Save Dialog; therefore, you can automate this process through code. In addition, I believe WordML supports form templates (the actual form) and data documents (the actual data for a form).
It's called PDF...
At the core (and without the million of extra unnecessary features" that's exactly the niche that Adobe PDFs were designed to fill.
I'd suggest you look more into Adobe Acrobat Professional for more info. Although, I don't think there's any good way to directly convert Word docs to PDF format.
Note: This question should be moved to Super User since it's not really programming related
Google Docs meets those requirements of a Platform-independent Web-based solution. Your mileage will vary with Google Docs though - if you just want to use it for letters, it's good. Much beyond that, it's rather limited. Unless you get the Premier (read: Corporate) version which you have to pay for, you won't be able to programmatically fiddle with the templates.
If you want a "Platform-independent solution", go with ODF or OOXML. You can make either "web-based" to your hearts content - maybe with HTML5 or another solution such as Flash or Silverlight.