RFCs and spam
Oct. 18th, 2006 12:54 pmI mentioned a little while ago how I realised that there was an extremely easy way to stop pretty-much all spam. I found it hard to believe that I was the only one to come up with such an idea so I started looking into it. I'm extremely surprised to find that we should really be getting almost no spam at all. The major reason spam continues to swamp the network is that most mail servers don't actually implement the existing standards and everybody basically says "oh it's too hard" when really, it isn't.
I have first-hand experience at giving in to this. For many years I used Eudora for my email. A few years ago I found a lot of emails suddenly weren't getting through to me. At first I thought it was a bug in the latest version of Eudora, but eventually I realised Eudora was doing the right thing. It didn't recognise broken emails. In almost all cases those broken, invisible emails came from people using Microsoft Office to send emails. Amazing!
I tried and tried to get people to use a safe and standards-compliant email program, but I might as well have been talking to trees. In the end I had to drop Eudora because I couldn't afford to lose work. Mozilla is more lax, and I now get all those emails, but that isn't necessarily a good thing. I am seriously considering going back to Eudora. If people want to use broken shit then maybe I just shouldn't see it. The trouble is, of course, most people don't realise how seriously flawed Microsoft products often are. They are encouraged to think that they're some kind of standard.
I still get people sending me Microsoft Word and Microsoft PowerPoint documents as if they were standards. Aaaarrrgh! I and many other people don't own or want Microsoft Word or PowerPoint. They are costly, dangerous, bloated, anti-standards programs.
[end rant]
RFCs
Incidentally, in my reading about email standards I've been referring to the original RFC documents (Request For Comments) that are the discussion papers that most of the standards grow out of. I noticed that the very early ones are now up there too. http://www.faqs.org/rfcs/rfc-index.html For some time many of the early ones were missing.
The very first one rfc1 is there. It talks about packets (called messages) with a header containing a 5-bit destination. That means it could be sent to one of up to 32 possible destinations. hehehehehe :) Somehow I suspect the awsome future of the internet had not hit them yet.
I have first-hand experience at giving in to this. For many years I used Eudora for my email. A few years ago I found a lot of emails suddenly weren't getting through to me. At first I thought it was a bug in the latest version of Eudora, but eventually I realised Eudora was doing the right thing. It didn't recognise broken emails. In almost all cases those broken, invisible emails came from people using Microsoft Office to send emails. Amazing!
I tried and tried to get people to use a safe and standards-compliant email program, but I might as well have been talking to trees. In the end I had to drop Eudora because I couldn't afford to lose work. Mozilla is more lax, and I now get all those emails, but that isn't necessarily a good thing. I am seriously considering going back to Eudora. If people want to use broken shit then maybe I just shouldn't see it. The trouble is, of course, most people don't realise how seriously flawed Microsoft products often are. They are encouraged to think that they're some kind of standard.
I still get people sending me Microsoft Word and Microsoft PowerPoint documents as if they were standards. Aaaarrrgh! I and many other people don't own or want Microsoft Word or PowerPoint. They are costly, dangerous, bloated, anti-standards programs.
[end rant]
RFCs
Incidentally, in my reading about email standards I've been referring to the original RFC documents (Request For Comments) that are the discussion papers that most of the standards grow out of. I noticed that the very early ones are now up there too. http://www.faqs.org/rfcs/rfc-index.html For some time many of the early ones were missing.
The very first one rfc1 is there. It talks about packets (called messages) with a header containing a 5-bit destination. That means it could be sent to one of up to 32 possible destinations. hehehehehe :) Somehow I suspect the awsome future of the internet had not hit them yet.
no subject
Date: 2006-10-19 02:20 am (UTC)PDF viewers, while they are free, are large, slow, and difficult to search. If the text is in image form (and I've seen that in far too many PDF documents) then you can NOT search it. The older versions of the PDF format are almost open, in that Adobe have published details of the format, but they still own it and they constantly change it.
HTML is an extremely efficient format. I've on a few occasions had to convert PDF documents to other formats -- a nightmare, because the so-called portable document format is anything but portable. But the result, if converted to HTML, is almost invariably a tiny fraction the filesize with no loss of information or style. PDF is bloated and unwieldy.
One of the worst things about PDF is that it is an extremely unforgiving format. If you download a webpage and you got all but the last byte, no problem. The browser will display as much as it got. If you download a multi-megabyte PDF document and the final byte is damaged, the PDF viewer will refuse to show it for you. What is more, because caching of documents is common now on the net, you can't force downloading from the original source. If you download it a second time you will just get the cached damaged version again. At least with HTML you can hit shift-reload and it will force the request to bypass the caches.
Here are a couple of links on why PDF is a really bad idea for anything other than printing on paper:
http://www.useit.com/alertbox/20030714.html
http://www.useit.com/alertbox/20010610.html
and a report on the problems for search engines when presented with PDF documents
http://www.searchtools.com/info/pdf.html
no subject
Date: 2006-10-19 02:22 am (UTC)I may have to rethink my anti-HTML stance.