> Lawrence Lile wrote:
>> I had a chance to examine the software this outfit used in these
>> "studies". The way it calculated savings from PFC on the service
>> entrance was to add up the utility bills for a year, and multiply the
>> result by 10%. Olin, please have a field day with this
>
> I don't know what else you said after that since you sent this paragraph as
> one long line and it got truncated somwhere, apparently at 256 characters.
> You really should set your mailer to send lines wrapped to lengths in the
> 72-80 characters range. Long lines are not guaranteed by SMTP or POP3.
It seems that me and several other recipients received the complete message
just fine. Thus it may be that this is a problem with your mail client (or
POP server?).
Every paragraph of the original message was on a single line. No line was
over 400 characters. The advantage compared to line lengths set by the
sender is that the receiver can view the message in whatever format suits
him or her, rather than having to view it in whatever format suits the
sender.
SMTP requires servers to support a line length of 1000 characters http://www.faqs.org/rfcs/rfc821.html (which hasn't been changed by
subsequent extensions like MIME, AFAIK).
> Olin Lathrop wrote:
>
>> Lawrence Lile wrote:
>>> I had a chance to examine the software this outfit used in these
>>> "studies". The way it calculated savings from PFC on the service
>>> entrance was to add up the utility bills for a year, and multiply
>>> the result by 10%. Olin, please have a field day with this
>>
>> I don't know what else you said after that since you sent this
>> paragraph as one long line and it got truncated somwhere, apparently
>> at 256 characters. You really should set your mailer to send lines
>> wrapped to lengths in the 72-80 characters range. Long lines are
>> not guaranteed by SMTP or POP3.
>
> It seems that me and several other recipients received the complete
> message just fine. Thus it may be that this is a problem with your
> mail client (or POP server?).
>
> Every paragraph of the original message was on a single line. No line
> was over 400 characters. The advantage compared to line lengths set
> by the sender is that the receiver can view the message in whatever
> format suits him or her, rather than having to view it in whatever
> format suits the sender.
>
> SMTP requires servers to support a line length of 1000 characters
> http://www.faqs.org/rfcs/rfc821.html (which hasn't been changed by
> subsequent extensions like MIME, AFAIK).
>
> Also AFAIK neither the POP3 standard
> http://www.faqs.org/rfcs/rfc1939.html nor the standard email format
> spec http://www.faqs.org/rfcs/rfc822.html include a line length
> limitation for the body of a message.
While that's all true and is to "the letter of the law", it does
conflict with the netiquette rfc: http://www.faqs.org/rfcs/rfc1855.html
which asks you to kindly wrap your lines at less than 65 characters.
> Gerhard
> ______________________________________________
> While that's all true and is to "the letter of the law", it does
> conflict with the netiquette rfc:
> http://www.faqs.org/rfcs/rfc1855.html
> which asks you to kindly wrap your lines at less than 65 characters.
>From the document:
"Status of This Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. "
(Sorry if that quote goes beyond the proposed 65 characters, but I wanted
to quote the original text, which seems to be 72 characters wide...
Confusion seems to reign when trying to standardize text width :)
I agree with most of the document, but since it is an RFC (Request For
Comment), I humbly comment that this part of the document, which was
written in 1995, took probably into account that at that time, most email
was read on text mode terminals with 80 characters wide lines and email
clients with very rudimentary user interfaces.
Now, almost ten years later, the human interface and email client situation
is quite different, and it may very well be argued that fixed line breaks
are more disturbing than they do good. How could the sender ever know my
reading preferences? It looks almost ridiculous to see a text hard-broken
at 65 characters displayed in a window with 150 character width, so who
prefers to read email at that width could argue for a hard break at column
130.
I personally would prefer flowing text with double line breaks at the end
of a paragraph; it accommodates all reader preferences (at least
potentially -- that is, with an email client that knows how to display
that). This, together with a standard about quoting that would allow email
clients to automatically reflow quoted text as needed, would make
text-based email much better readable.
I could write an RFC about that, and it would be just as valid as that one
from 1995... :) But I don't think that the line length is really that
important. If somebody can't see the remainder of long lines, he could
simply get an email client that can wrap long lines (or configure his to do
it), and be done with it.
Gerhard Fiedler wrote:
> michael brown wrote:
>
>> While that's all true and is to "the letter of the law", it does
>> conflict with the netiquette rfc:
>> http://www.faqs.org/rfcs/rfc1855.html
>> which asks you to kindly wrap your lines at less than 65 characters.
>
>> From the document:
>
> "Status of This Memo
> This memo provides information for the Internet community. This
> memo does not specify an Internet standard of any kind. "
>
> (Sorry if that quote goes beyond the proposed 65 characters, but I
> wanted to quote the original text, which seems to be 72 characters
> wide... Confusion seems to reign when trying to standardize text
> width :)
72 does seem to be the de-facto standard at the moment.
> I agree with most of the document, but since it is an RFC (Request For
> Comment), I humbly comment that this part of the document, which was
> written in 1995, took probably into account that at that time, most
> email was read on text mode terminals with 80 characters wide lines
> and email clients with very rudimentary user interfaces.
In all fairness, you also used rfc's to support your arguments.
> Now, almost ten years later, the human interface and email client
> situation is quite different, and it may very well be argued that
> fixed line breaks are more disturbing than they do good. How could
> the sender ever know my reading preferences? It looks almost
> ridiculous to see a text hard-broken at 65 characters displayed in a
> window with 150 character width, so who prefers to read email at that
> width could argue for a hard break at column 130.
The sender wouldn't always know but sometimes he does; would you deny
him that? The rfc makes the (valid) point that you don't know what kind
of device someone is using to read your mail, and that it's courteous to
keep that in mind. Also, I believe that the sender should have the
ability to set the line length as only he knows best how it should go.
HTML based e-mail is blasphemous. ;-)
> I personally would prefer flowing text with double line breaks at the
> end of a paragraph; it accommodates all reader preferences (at least
> potentially -- that is, with an email client that knows how to display
> that). This, together with a standard about quoting that would allow
> email clients to automatically reflow quoted text as needed, would
> make text-based email much better readable.
That's not a bad argument, but then again the client could easily do
allot of this work now. Code samples and schematics might be hard to
read though. ;-)
> I could write an RFC about that, and it would be just as valid as
> that one from 1995... :) But I don't think that the line length is
> really that important. If somebody can't see the remainder of long
> lines, he could simply get an email client that can wrap long lines
> (or configure his to do it), and be done with it.
I agree with that somewhat, but the sender should only send long lines
if that is somehow important to the data presentation. Also, I think it
takes a bit more than that to get a number assigned to an rfc. :-)
Gerhard Fiedler wrote:
> I could write an RFC about that, and it would be just as valid as
> that one from 1995... :) But I don't think that the line length is
> really that important. If somebody can't see the remainder of long
> lines, he could simply get an email client that can wrap long lines
> (or configure his to do it), and be done with it.
RFCs are about interoperability. If you stick to the RFCs, you can
be pretty sure that things will mostly work most of the time. It's not
perfect, but what is?
Besides, just from a most reward for least effort perspective, it
would be a lot easier to write a quick mail filter that would convert
hard line stops to flowing text (and vice-versa) than getting everybody
else in the world to agree to a new format.
On Dec 24, 2004, at 11:54 AM, michael brown wrote:
>
> In all fairness, you also used rfc's to support your arguments.
>
>
One should note that RFCs range from "international standard" to
"April Fools Joke" in their intent, and they tend to be carefully
labeled as to their level of "seriousness." Quotes from a "Standards
track" RFC have more weight than quotes from "informational" RFCs.
The argument about whether the composer or reader should have more
control of the formatting of the document has become a religious issue
and is therefore banned from piclist :-) The "problem" here is that
the composer is assuming that the reader will format it, and the reader
is assuming that the document is already correctly formated.
(probably.)
All the email standards (excepting MIME, which allows anything to
be enclosed within an email) pretty much predate the concept of
reader-side formatting of "content." I tend to believe that if you
send a text email, it ought to be formatted with CRLFs after each
line instead of after each paragraph. Microsoft seems to have
disagreed,
probably gratuitously, possibly maliciously, and almost certainly
arrogantly,
and (unfortunately) they've been widely copied in modern mail clients.
> RFCs are about interoperability. If you stick to the RFCs, you can
> be pretty sure that things will mostly work most of the time. It's not
> perfect, but what is?
But then, things _do_ change. Especially in computing -- and in computing
standards, real ones and de-facto. I don't think that an informal document
from 1995 (note that this is /not/ a standard) can be taken at its face
value without detailed analysis. Take the fact that almost nobody (not even
some of the defenders of the validity of this document) uses 65 character
wide lines as an example. I think that changing the line length from 65
characters to 72 characters is a rather arbitrary deviation usually
performed without reference to the cited RFC and without a clear goal in
mind, and doesn't help us much to solve any involved problems -- compared
to what I'm talking about, which would actually solve a real problem.
> Besides, just from a most reward for least effort perspective, it
> would be a lot easier to write a quick mail filter that would convert
> hard line stops to flowing text (and vice-versa) than getting everybody
> else in the world to agree to a new format.
There are a number of email and news clients that do that, but because of
the multitude of formatting styles in use and the differences in content,
this doesn't work very well.
And note that the problem these text reformatters try to solve predates
flowing text without hard returns. However short you set the line length,
quoted text that's not reflowed is bound to exceed the maximum line length
sooner or later -- assuming there is one (which is the base assumption for
setting a fixed line length in the first place). This is probably the
strongest argument for flowing text combined with a quoting standard. All
fixed-line-length cited text either looks ugly or needs to be reflowed --
manually or automatically.
> The argument about whether the composer or reader should have more
> control of the formatting of the document has become a religious issue
> and is therefore banned from piclist :-)
Wise words... I'll try to stay away from that :)
> The "problem" here is that the composer is assuming that the reader will
> format it, and the reader is assuming that the document is already
> correctly formated. (probably.)
Actually I think the real problem is that some people use readers that
don't support email standards that post-date 1995...
> All the email standards (excepting MIME, which allows anything to be
> enclosed within an email) pretty much predate the concept of reader-side
> formatting of "content."
..., for example MIME. A standard just as "standard" as SMTP, and almost as
widely supported, albeit not always correctly. I just can't see what's
wrong with it... I suppose even the guys that still use readers that don't
support MIME are using Flash PICs these days ("real men use EEPROM" :)
> I tend to believe that if you send a text email, it ought to be formatted
> with CRLFs after each line instead of after each paragraph. Microsoft
> seems to have disagreed, probably gratuitously, possibly maliciously,
> and almost certainly arrogantly, and (unfortunately) they've been
> widely copied in modern mail clients.
How do you come to this conclusion?
I don't use Outlook Express myself, but a quick check of posts by OE users
in mailing lists (like in this one -- for example michael brown's posts)
and newsgroups reveals that many are in fact hard-broken. I also know that
Outlook (the other Microsoft email client) provides an option to
automatically hard-wrap text. And I'm not sure, but I think both come
pre-configured to hard-wrap lines in text-only messages at column 72.
So it seems to me that whoever is using a Microsoft email or news client
and is not using a fixed line length in text messages does so because he
didn't configure it properly (or even changed the default setting). So even
though I'm not specifically a Microsoft fan, I don't see much reason in
stating that Microsoft "probably gratuitously, possibly maliciously, and
almost certainly arrogantly" violated any standard WRT this subject. This
judgment seems to tell more about the judge than the judged... (as most do
:)
> > All the email standards (excepting MIME, which allows anything to be
> > enclosed within an email) pretty much predate the concept of reader-side
> > formatting of "content."
>
> ..., for example MIME. A standard just as "standard" as SMTP, and almost as
> widely supported, albeit not always correctly. I just can't see what's
> wrong with it... I suppose even the guys that still use readers that don't
> support MIME are using Flash PICs these days ("real men use EEPROM" :)
I use fairly modern techniques in everything else, but I much prefer to
read my email in a unix text-only way. I prefer "elm". I do this because
I haven't seen a virus that can go through a purely text-only email client.
It also helps me weed out unwanted email: if it's html formatted (except
if its from my father who doesn't know any better) I pitch it.
--
D. Jay Newman ! Rock is Dead! spam_OUTjayTakeThisOuTsprucegrove.com ! Long live paper and scissors! http://enerd.ws/robots/ !
D. Jay Newman wrote:
> I use fairly modern techniques in everything else, but I much prefer to
> read my email in a unix text-only way. I prefer "elm". I do this because
> I haven't seen a virus that can go through a purely text-only email client.
I frequently have to exchange files of all sorts, and in terms of virus
spreading it doesn't really matter whether I exchange these files through
email, ftp a version control system or something else. It's just that email
in some cases is more convenient.
> It also helps me weed out unwanted email: if it's html formatted (except
> if its from my father who doesn't know any better) I pitch it.
In my personal and professional email (that is when I'm not writing to a
discussion group that prefers text-only :), I usually use html. I find that
formatting helps a lot to bring the point across: like bold and italics, a
proportional font for normal text and a monospaced one for program-type
stuff, bullet points and indented paragraphs... I just don't see why not
use these possibilities when they are so conveniently available. Most
people wouldn't want to miss these when writing normal documents, so why
not use them for email just as well?
Gerhard Fiedler wrote:
> William ChopsWestfield wrote:
This is one of my all time favorite rants (honest I'm not a troll!).
>>The "problem" here is that the composer is assuming that the reader will
>>format it, and the reader is assuming that the document is already
>>correctly formated. (probably.)
>
>
> Actually I think the real problem is that some people use readers that
> don't support email standards that post-date 1995...
Maybe it's a problem with a particular OS vendor who has decided that
such standards need to be updated to match their needs and as such they
are no longer following the standards have called it their own.
>>All the email standards (excepting MIME, which allows anything to be
>>enclosed within an email) pretty much predate the concept of reader-side
>>formatting of "content."
> ..., for example MIME. A standard just as "standard" as SMTP, and almost as
> widely supported, albeit not always correctly. I just can't see what's
> wrong with it...
Let me start with when HTML first started appearing in email I thought
it was a good thing but now I know it's a bad thing (sorry I'm having a
little fun with words)! I would say to most of the HTML and all of the
mime encoded email, I receive is SPAM or virus (?). The SNR of HTML
ratio is about 1%. The SNR of plain text messages, around 85% (I use
news groups too).
In a business setting I hate mime and HTML even more as it leads
to top post (another rant). Responding to various points in a message
about 40 pages long is impossible. Trimming it to make sense is just
as difficult! Just because it's done doesn't make it a good thing.
I'm another person who has fallen back to using a plain text mail
user agent or Mozilla in plain text, fixed font mode.
It is my opinion (and that's all it is) that Microsoft has done more
to ruin written communications by "extend & embrace" through
introduction of non-standard HTML & mime as standard parts of their
products. It seems to me they have made it easy to be lazy rather than
follow the lessons learned with the text era communications. Also their
loose idea of security has lessened the value of HTML & mime.
> I suppose even the guys that still use readers that don't
> support MIME are using Flash PICs these days ("real men use EEPROM" :)
Bad example, while I use PIC's, AVR, etc. etc. ... I don't try to
mix the new technology into an environment of old technology when
the benefits don't out-weigh the costs. My 6800 systems run fine
on the 2708s, no need to redesign them to run with flash. But when
it comes time to do so I won't be using the 6800s.
BTW, my web pages currently use XHTML 1.0 (I haven't learned 1.1
yet). Using the right tool at the right time or media is always a
good idea. Too bad I've had to toss the JavaScript and Java for
external pages.
>My 6800 systems run fine
> on the 2708s, no need to redesign them to run with flash. But when
> it comes time to do so I won't be using the 6800s.
Of course not. That would be stupid. The obvious thing to do then would be
to upgrade to 6802's. (Or if you insist on leading edge stuff, maybe make
the quantum leap to 6809!).
RM
(
I can still write some 6800 machine code in my head :-). Less used op codes
have been forgotten.
Favourite is, of course, $DD
)
> I would say to most of the HTML and all of the
> mime encoded email, I receive is SPAM or virus (?).
No one sends you pictures? Much as I disapprove of HTML and MIME
in general, the ability to send and receive photos in a moderately
seamless manner is awfully useful. For that matter, I consent to
receiving a fair quantity of commercial email (not quite spam, since
it's by request), and its ability to load non-inline graphics is
pretty nice too. And clickable links in email? Very nice, usually.
The ability to trivially (MUCH, MUCH too easily) attach a 2M powerpoint
presentation to email sent to an internal mailing list containing a
couple thousand people is ... less nice.
The mail client I use for most of my mail is older than elm, sort of.
Text only. I modified the source so that I can pipe messages though
the mime filter from mh, if I get really desperate. But usually any
non-proprietary email with attachments that aren't obvious spam or
viri just gets forwarded to yahoo, gmail, or mail.com where more modern
tools can be applied...
> Maybe it's a problem with a particular OS vendor who has decided that
> such standards need to be updated to match their needs and as such they
> are no longer following the standards have called it their own.
I'm using products of a certain OS vendor (not on this email account
though) and I don't think you'll find much wrong with my emails. We can try
that if you want... I'd be interested to know if there actually are
problems with my emails WRT standards.
> Let me start with when HTML first started appearing in email I thought
> it was a good thing but now I know it's a bad thing (sorry I'm having a
> little fun with words)!
You didn't say why you "know" that. I seem to not yet "know" that... was
that some kind of extrasensorial experience? What do I have to do to see
the light? :)
> I would say to most of the HTML and all of the mime encoded email, I
> receive is SPAM or virus (?). The SNR of HTML ratio is about 1%. The SNR
> of plain text messages, around 85% (I use news groups too).
This must be the selection of senders you receive. I almost don't receive
any spam on my "real" email accounts (not counting the ones I use for
public lists, web site registrations and newsgroups), and most of the
significant email I receive on these accounts is HTML. WRT viruses, I think
they usually come as attachment -- whether to HTML formatted email or text
mode emails doesn't really matter. AFAIK there's nothing inherent in HTML
that opens you to viruses. Unless you are willing to forgo all attachments,
you need to deal with this issue whether or not you format your email in
HTML.
It seems that the SNR of the different formats is a very individual
criterion, and depends a lot on how people treat their email addresses and
select their partners. Of course, if you let everybody know you prefer text
mode, people write to you in text mode and the only HTML messages you
receive are spam. (I have a few people in my address book that are marked
for "text only" and emails to them get automatically created as text only
emails... Doesn't say anything about characteristics of text or HTML mode,
but about individual preferences.)
> In a business setting I hate mime and HTML even more as it leads to top
> post (another rant).
Why is that? IMO there is nothing inherent in HTML that leads to top posts.
For example the Eudora email client (one of the traditional ones on
Windows) does not encourage top post in HTML mode.
There is something inherent in the way Microsoft Outlook formats replies
that encourages top post, but that's independent of whether you use it with
HTML or text only messages.
> Responding to various points in a message about 40 pages long is
> impossible. Trimming it to make sense is just as difficult!
I didn't understand that... are you saying that 40 page emails are too
long? If so, I tend to agree -- but again, I don't see a point here that
affects the question of email format. I think that a well-structured 40
page HTML email is probably easier to read than a 40 page text-only
document (and, everything else being equal, the 40 pages HTML probably need
some 50+ pages text only), but if the 40 pages are not really necessary,
they should be avoided in either format. If they are necessary -- well,
then you better use all you have at your disposal to make them /readable/.
> It is my opinion (and that's all it is) that Microsoft has done more to
> ruin written communications by "extend & embrace" through introduction
> of non-standard HTML & mime as standard parts of their products. It
> seems to me they have made it easy to be lazy rather than follow the
> lessons learned with the text era communications. Also their loose idea
> of security has lessened the value of HTML & mime.
All Microsoft email clients support text only mode, and probably most X
email clients support HTML. So how does that relate to the question whether
to choose either mode? This is an argument about whether or not to choose
Microsoft products, but not about HTML vs. text mode for emails.
If I understand your argumentation, it seems to go like "Microsoft products
don't implement standards well, encourage top post, are generally insecure,
and I don't like their overall attitude. Since Microsoft's email clients
come pre-configured to send out HTML messages, HTML messages are bad."
Pardon me if I find this lacking some logic :)
>> WRT viruses, I think they usually come as attachment
>
> "Attachments" are a thing enabled by MIME, supporting the original
> assertion that lots of mime emails were viri...
I believe you are referring to "I would say to most of the HTML and all of
the mime encoded email, I receive is SPAM or virus (?)" -- which includes
the affirmation that "... most of the HTML ... email I receive is SPAM or
virus".
The whole issue was about text formatting at first, and then got extended
to include HTML formatting. MIME came also in, but the whole discussion was
still about formatting.
Most users of text mode would not want to miss the ability to send
attachments, so this argument isn't really on the side of text mode (unless
you really don't want to use attachments).
So my point was that it isn't really clear against what or for what Neil
argumented. - Against MIME? He didn't really say that he doesn't use attachments, and I
suspect he does use them. And if we were against MIME, we would have to ban
the "£" sign also that gets used here once in a while -- and of course all
communication in non-English languages. Probably not a big thing for most
people on this list, but the 'net goes beyond the USA and the Commonwealth.
So bite the bullet, MIME is here to stay, as are languages that use
non-ASCII characters. And if you don't want to stay behind, you better get
an email client that knows how to handle MIME.
- Against HTML? Not much to do with viruses, so what's the point in talking
about them if HTML is the issue?
- Against Microsoft? Most likely, but not really closely related to
formatting of emails.
I'm surprised that nobody yet has brought up the evil characters beyond the
US English character set... :) After all, I'm sure there are still email
clients around that don't quite know what to do with "charset=ISO-8859-1"
or the like.
Gerhard Fiedler wrote:
> William ChopsWestfield wrote:
>>>WRT viruses, I think they usually come as attachments
>>"Attachments" are a thing enabled by MIME, supporting the original
>>assertion that lots of mime emails were viri...
There have been a few where it has been HTML formatting and buffer
overflows within MS dlls. But you are correct most of the Viri
have been via attachments.
> The whole issue was about text formatting at first, and then got extended
> to include HTML formatting. MIME came also in, but the whole discussion was
> still about formatting.
> So my point was that it isn't really clear against what or for what Neil
> argumented.
Sorry about that, my fault. Email is an extremely useful medium and I've
gotten really tick'd off about all the abuses. It's hard not to rant on
the other subjects since they tend to be inter-related.
> - Against HTML? Not much to do with viruses, so what's the point in talking
> about them if HTML is the issue?
> - Against Microsoft? Most likely, but not really closely related to
> formatting of emails.
OK, now you've hit a nerve! ;-) Here is where things start to heat up.
My problem isn't with HTML so much as it is with MS abuse of HTML,
clueless users who refuse to trim & top post, proportional fonts
that extend past 76 characters making the message difficult to read.
MS HTML it's full of redundant HTML statements and considering it's
the default product (OutLook & OutLook Express) on the majority OS
and it's defaults are set to MS extensions it's 90% of the problem.
Does anyone remember when MS's default was to send both HTML and
text (the funky stuff with the =0D for line endings). I think
Netscape was guilty of this also. The other 10% I'm beginning to
ignore but if I have to reread a top posted message which hasn't
been trimmed then forget about it. I'll be just as lazy as the
poster.
Now back to the HTML the problem are as follows, links to
images (this gets tremendous abuse in SPAM), javascript (just
turn it off), Java (turn it off), people playing with the fonts
(usually sizes), non-standard HTML (MS & Netscape are guilty
of this) and the considerable bloat (low SNR). The problem
is so much with HTML it's with it's potential for abuse.
My initial comments on HTML and email may not really carry much
weight as if I consider that I filter mail lists first, then
well known associates, what I have left is pretty much SPAM
which is mostly broken HTML like code. Not the other way around
which would have been HTML mail is mostly SPAM. Sorry about that.
> I'm surprised that nobody yet has brought up the evil characters beyond the
> US English character set... :) After all, I'm sure there are still email
> clients around that don't quite know what to do with "charset=ISO-8859-1"
> or the like.
I can read other character sets within reason (sorry I can't read
other languages). I also don't go nuts with other's spelling
unless it appears to be someone who is intentionally using 'IM
talk'. This is a more formal setting where elite speak and IM
talk are not appropriate. Technical mumbo-jumbo is acceptable
but limit the marketing talks! :-)
>> - Against Microsoft? Most likely, but not really closely related to
>> formatting of emails.
>
> OK, now you've hit a nerve! ;-)
> MS HTML it's full of redundant HTML statements
I guess any WYSIWYG HTML will be redundant. But I must admit, it's been a
while since I looked at it; these days, I simply look at the result, and as
long as it seems to display fine, I don't bother to check the HTML. When
reading email (as opposed to analyzing the HTML generator or fixing a
problem with the formatting) I don't really care about the structure or the
redundancy. However redundant, HTML email is a small part of what I
download every day, so the bandwidth waste isn't carrying so much weight
either.
> Does anyone remember when MS's default was to send both HTML and
> text (the funky stuff with the =0D for line endings). I think
> Netscape was guilty of this also.
I think almost all email clients that send HTML messages send this "funky
stuff," by default and to this day. The reasoning is like this: When you
send an HTML message, there are recipients that don't want to read HTML
formatted messages. So the email client sends a MIME multipart message: one
part text/html, the other part text/plain, without HTML formatting (but the
same content). You at the receiving end decide whether you want to see the
HTML encoded part or the plain text part. (Of course, your email client
needs to provide a configuration that allows you to tell it to show the
text/plain part of a multipart message by default if it is present. Most
will show the text/html part instead by default.)
The =0D line endings are simply CR characters in quoted-printable encoding,
which any email client that is worth this name should understand. Both the
text/plain and the text/html content often come as quoted-printable. (This
message probably not, because AFAICT I'm not using any character beyond
7-bit ASCII. But if I used the British Pound sign, for example, the message
would be automatically encoded as quoted-printable, and the character set
in use would be set to the standard West European ISO set.)
This is nothing funky or non-standard; it's all quite well-defined in email
standard RFCs.
> Now back to the HTML the problem are as follows, links to
> images (this gets tremendous abuse in SPAM)
I'm using Microsoft Outlook ("normal" email) and 40tude Dialog (newsgroups
and mailing lists). With earlier versions of Outlook, I allowed Outlook
only access to POP3 and SMTP ports and a few others, but no normal HTML
ports, with a few IP exceptions. So it simply didn't download any pictures.
The current version of Outlook can be configured to not download any
pictures by default. 40tude Dialog doesn't download anything (it can't). So
I never had a problem with this, not Microsoft-related or otherwise. This
is IMO a question of having the right email client -- and of having it
configured correctly (according to your preferences).
> people playing with the fonts (usually sizes),
I know what you mean :) But how about seeing this as a personal expression
of the sender, and respecting it as that? Even though you might think the
result is plain weird and this person is "email challenged"? Where did
tolerance go?
And, as mentioned above, the vast majority of HTML emails comes as MIME
multipart these days, so whoever doesn't like HTML in almost all cases has
the option to not even look at it and rather look at the text/plain version
of the message.
> non-standard HTML (MS & Netscape are guilty of this)
Really? As I wrote before, since I use Outlook, I would be interested in
finding out what exactly is non-standard in the emails I send out through
it. If you can point me to information or would be willing to receive email
from me and mark the non-standard elements, I'd be grateful. I did some
test, but couldn't find anything that's obviously non-standard.
I did also a quick check on the web about this. Most of the links that came
up seem to rant more about non-compatibility of Microsoft (and other) email
with certain *nix email clients or certain personal preferences than
specifically about deviations from documented standards; that is, they kind
of considered the specific features (or lack thereof) of a certain email
program and their personal preferences as the "standard".
> The problem is [not?] so much with HTML it's with it's potential
> for abuse.
Or maybe with the lower tolerance towards it? When you look at plain text
messages, they are just as often "TOFU" style (top post, full quote below).
The quoting is also quite often quite messed up, as the fixed line length
leads necessarily to messed up quotes unless it gets fixed regularly (which
many don't bother doing).
Fixed line length may be an old convention, but it sure is not necessarily
a good one. There are a number of problems with it. It seems to me that
some people just got so used to the limitations that they don't see them
anymore, whereas the newer problems with other conventions catch their
attention. Could that be lack of tolerance? Or maybe mental laziness?
> what I have left is pretty much SPAM which is mostly broken HTML
> like code.
No doubt about that. However I'm not sure one can make an argument that the
broken HTML found in spam messages was generated mostly through MS
products. From the structure, I'd say it's more likely to have been
generated through other means. I also do receive a good percentage of plain
text spam, so going back to plain text email is not going to solve the spam
problem either.
So far I haven't seen an argument that HTML emails are anymore "evil" than
plain text emails. I can't get rid of the feeling that most arguments about
HTML in emails end up in "I just don't like it". That's fine, and as you
can see -- this message is plain text :) --, to a large degree I respect
that (even though I do like it). But I can get ticked off when people try
to disguise their personal preferences as "standards".
(BTW, one good argument against a fixed line width for messages is the
desire to post long links without them getting broken. Works also like a
charm in HTML formatted messages :)
Regarding Microsoft products generating bad (non-standard) HTML check out
this link: http://elsewhat.com/thesis/
I can probably be said that the majority of web sites has not been created
with Microsoft tools, yet there are very few pages out there that actually
conform to the HTML standard. Which leads to the conclusion that the
majority of tools -- whether Microsoft or not -- get used by authors to
create non-standard HTML, with no involvement of Microsoft.
Possibly the HTML generated by current Microsoft email clients is more
standard conformant than the average of the www. Which means that if one is
concerned about good HTML, there are more important targets :)
On Dec 30, 2004, at 5:26 AM, Gerhard Fiedler wrote:
>
> (BTW, one good argument against a fixed line width for messages is the
> desire to post long links without them getting broken. Works also like
> a
> charm in HTML formatted messages :)
>
Used to be that only the most obnoxious of programs would break a line
at anything other than a space character. Fascinating that this broke
at just about the same time that very-long-words-not-containing-a-space
become more common.
>> (BTW, one good argument against a fixed line width for messages is the
>> desire to post long links without them getting broken. Works also like
>> a charm in HTML formatted messages :)
>>
> Used to be that only the most obnoxious of programs would break a line
> at anything other than a space character. Fascinating that this broke
> at just about the same time that very-long-words-not-containing-a-space
> become more common.
I'm not sure which programs do that, but I can't remember that any of the
two I'm using is doing that (40tude Dialog and Microsoft Outlook).
I received my own post with the long link intact and clickable through
gmane and 40tude Dialog.
> Used to be that only the most obnoxious of programs would break a line
> at anything other than a space character. Fascinating that this broke
> at just about the same time that very-long-words-not-containing-a-space
> become more common.
Looking at one of your posts with a long URL, it seems that your "Apple
Mail (2.619)" is one of the programs that break long URLs -- seemingly
because it breaks not only on whitespace, but also on slashes "/".
It's all about choosing programs that behave (or can be made to behave) the
way we want them to behave. There /are/ options...
sprucegrove.com ! Long live paper and scissors!
