[EMAIL PROTECTED] (Bengt Richter) wrote: > On 16 Oct 2005 00:31:38 GMT, John Bokma <[EMAIL PROTECTED]> wrote: > >>[EMAIL PROTECTED] (Bengt Richter) wrote: >> >>> On Tue, 04 Oct 2005 17:14:45 GMT, Roedy Green >>> <[EMAIL PROTECTED]> wrote: >>> >>>>On Tue, 23 Aug 2005 08:32:09 -0500, l v <[EMAIL PROTECTED]> wrote or quoted >>>>: >>>> >>>>>I think e-mail should be text only. >>> I think that is a useful base standard, which allows easy creation >>> of ad-hoc tools to search and extract data from your archives, etc. >>>> >>>>I disagree. Your problem is spam, not HTML. Spam is associated >>>>with HTML and people have in Pavlovian fashion come to hate HTML. >>>> >>>>But HTML is not the problem! >>> Right, it's what the HTML-interpreting engines might do that is >>> the problem. >> >>You mean the same problem as for example using a very long header in >>your email to cause a buffer overflow? That is possible with plain >>ASCII, and has been done. > Are you trolling? No, I don't mean the same problem. > What an HTML interpreter does by _design_ is not in the same category > as an implementation error enabling a root exploit.
Ok, what do you think are the bad things in HTML design? (For email that is). I can name only two: 1 - remote loading of objects 2 - when a user clicks on a link, this can be seen as a confirmation. The latter is also possible in the email clients I have used when plain text is used. Ok, you can say that in HTML you can hide somewhat the destination, e.g. <a href="http://example.com/user-1234";>Check out this </a>. OTOH, you are not forced not to read the status bar. [ ... ] > Don't get me wrong, I said "all good stuff," as far as control of > presentation is concerned. And I would be happy to have nice graphic > email if I could get it as a self-contained file from my ISP's mail > server, and I had a presentation engine involved that I knew was > guaranteed to stick to presentation work without communicating over > the web or doing anything else without my knowledge. > > I don't see any technical obstacle to that, but HTML is not designed > to be the solution to that. Of course: I can compose an HTML file which has the graphics embedded in HTML which works in the client I am using. Another option is to include the graphics as attachements (this works). I am convinced this also works for stylesheets and any other object. So in short, it's possible to get a self-contained email. [ pdf ] >>Ah, and that's exploit free? > That's not the issue. All programs can have the kind of exploit > possibilities that you are talking about. A program with the single > purpose of interpreting a page description and presenting it > graphically is easier to eliminate exploitable vulnerabilities from > than a program that involves a lot of additional stuff. I thought it was possible to add a remote link to PDF (but I couldn't make one with OOo -> export pdf). But I am afraid that as soon as PDF is taking over the role of HTML in email, it will certainly going to support things you consider harmfull (and are in some occasions, I mean, I agree that tracking of images in spam is a bad thing). >>>>Program listings are much more readable on my website. >>> IMO FOSS pdf could provide all the layout benefits while >>> avoiding (allowing for bugs) all the downsides of X/HTML in emails. >> >>Amazing, so one data format that's open is better compared to another >>open data format based on what? > I take it you don't understand the difference between pdf and html? > > A primary thing is the monitorable data-moving activity that is > involved. A pdf can have links, but they are not followed (not > counting what closed source proprietary softare might risk a PR black > eye doing) in the process of opening and presenting the document to > you. And a link in an HTML file is? (Ok, there are so called caching systems that do this with browsers). > The whole file comes as a single unit normally As I stated, this is possible with HTML, at least Firefox does support inline images (data scheme). CSS can already be included in the file itself. > (though I could see the > temptation to implement automatic font downloads and enable font-bugs > like web-bugs based on that, though in a FOSS implementation, such > [mal]features could easily be made optional). > > You could say features can be optional re HTML CSS and JS and all the > other automatic web-accessing and other features of HTML, but by the > time you made them all optional and turned them off, you wouldn't see > the HTML-author's intended presentation. That is not the case with > pdf. Also, a single pdf file would be coming from one place. There is > not an on-the-fly gathering of elements that you have to use a special > tool to determine for sure where all the requests to get them went, or > to prevent them from going, and having the activity logged, not to > mention what the interpretation of unknown elements might do. If it's not possible to remote link to an image in PDF, I wouldn't be amazed that if it is replacing HTML in email, such a thing will be added. -- John Small Perl scripts: http://johnbokma.com/perl/ Perl programmer available: http://castleamber.com/ I ploink googlegroups.com :-) -- http://mail.python.org/mailman/listinfo/python-list
