Jochen said:
WinMail is the email application of Windows Vista.
--> this problem is very special to Microsoft email applications.
Microsoft has always referred to this product as Windows Mail. Example:
http://www.microsoft.com/windows/windows-vista/features/mail.aspx, and
WinMail is not used anywhere. WinMail is a colloquialism employed by
some users of the product.
WinMail, as another example, could refer to a 3rd party product called
WinMail Viewer, that is used by recipients of e-mails where an Outlook
sender chose to compose using RTF format that no other e-mail client
supports. When you said WinMail, that was the first product that I
thought of because that word is actually in the name of that product.
It has nothing to do on how to configure general e-mail settings. It is the
question how to control automatisms regarding appearance of content. For some
reasons, automatisms make sense, but not in all reasons. So there is the need
to be able to switch off this automatism if you know it's not working
properly within special situations.
So, again, you want to change what the recipient see despite what
configuration they have chosen for their e-mail client running on their
property. Scripts aren't allowed in e-mail for the same reason.
This is an option (or let's say a workaround) in many situations, but not a
real solution. I'm interested in a real solution.
Only 1 argument of several ones why a real solution is required: the SPAM
detection engines do another ranking if you use text-only, html-only or
text+html-mails.
All HTML-formatted e-mails should contain 2 MIME parts: a plaint-text
MIME part and an HTML MIME part. Not all e-mail clients can read
HTML-formatted e-mails, or users have configured their e-mail clients to
always show e-mails in plain-text format. The text MIME part ensures
that your e-mail is viewable by as many recipients as possible. It is
improper to compose an HTML-formatted e-mail without including a
plain-text version. Hotmail was like that for a long time but, as I
recall, they redeemed themself by eventually including both MIME types.
If some anti-spam filter is adding spam weight to an e-mail that
contains both text and HTML MIME parts than the author of that software
hasn't a clue how HTML-formatted e-mails are supposed to be composed, or
the user of that software misconfigured it.
About the best you can do if you decide to stick with plain-text e-mails
is to put a notice at the top of your e-mail notifying the user to NOT
have their e-mail client remove duplicate blank lines. Of course, in
Outlook, a yellow infobar already comes up to warn the user that Outlook
has removed the extra blank lines.
Since you don't want to use HTML, sending a .pdf, .doc, .txt, or other
file as an attachment that contains your code is probably not a viable
solution to you. However, I suspect your recipients would probably want
your code as an attachment rather than inside the body of the e-mail.
For example, when they reply, they're going to have to do a lot of
snipping out of that code that isn't needed in their reply.
Personally I don't see how code is any harder to read when it is
single-spaced with just a blank line for whitespace to provide
legibility than to double up, or more, on the blank lines. Reading
books, and even reading code, is a lot tougher when they're
double-spaced. You could, for example, place a single period character
at the start of the blank lines (if that doesn't interfere with whatever
is the data you are providing inside the e-mail). That wouldn't be a
blank line so it won't get removed as duplicate whitespace. I haven't
tried inserting just a tab character (which appears invisible to the
user) to see if that might qualify the line as non-blank to circumvent
the duplicate whitespace removal.
Of course, the removal of duplicate contiguous blank lines is a feature
in Outlook. Who know what another e-mail client might do with your
e-mail regarding whitespace.
