I’m using Outlook Express 6 and XP home on my home PC, outgoing email is routed via my ISP’s SMTP server(NTL); I’ve not had any problems sending before.
Until the other day, when it became necessary to format a message as HTML (so that I could embed pictures and use font styles etc) - the message appeared to send OK (i.e. it went to the outbox, the progress bar showed the progress of it being uploaded and it then moved into the ‘sent items’ folder). But the message never arrived with the recipient.
Further tests (sending HTML format messages to one of my other accounts etc) seem to suggest that HTML formatted messages consistently simply die somewhere in transit. There are no error messages and the addresses of the recipients was definitely entered correctly.
Has anyone heard of this and is there a fix?
P.S. I’m well aware that there are other email clients I could and probably should use, so there’s no need for… you know…
Key question, I believe: who’s your ISP? It sounds like your ISP is, for whatever reason, deciding that HTML messages are spam, and is filtering them out. Just a WAG, since I can’t think of any other explanation (I use HTML all the time, and they go to all sorts of recipients without any problems). It’s certainly not an Outlook problem.
It may be the ISP (NTL) - I’m going to install my own SMTP engine tonight and see if I can send the messages that way - usually I would only send plain text, but in this particular case, I needed to insert pictures and use a handwritten-style script font - I could have sent it as RTF, but I think I’m right in saying that HTML handles font equivalency better, should the exact script font not be available on the recipient’s machine (if it had worked at all, that is).
HTML is a security risk. If nothing else, it can contain web bugs: small images located on a spammer’s server. When someone downloads them in the process of reading the email, the spammer knows he’s got a live address. More devious tricks involve JavaScript and other languages powerful enough for crackers to write malware in.
Generally speaking, any way to get a remote computer to blindly execute arbitrary code is a cracker’s dream. HTML, while it itself is not a programming language, can certainly act as a host for programs written in actual languages. Since a good portion of email clients are not smart enough to dump the code but keep the HTML, security-conscious people have opted to reject all HTML.
Finally, you really don’t need HTML email. I know it would be nice, and you probably think me an ass for saying so, but if your content is worth anything, plain ASCII will work just fine. Include the URL of a web page containing the HTML if you really want them to see your latest images. It’s certainly more polite than dumping kilobytes of code on their hard drives, and it’s almost guaranteed to get through.
Although I take your point about all of the security reasons, With respect, I disagree about the universal suitability of plain text; in this particular (and somewhat unusual) case, there would have been no point at all in saying what I had to say unless I could present it in the desired style - the style was to be at least half of the effect for this message. You may of course interpret this to mean that the textual content was fundamentally pointless, but I assure you this was not the case either.
It can’t be getting blocked at the recipient’s client or ISP level because I have tried sending to several of my own (other)accounts, which I know from experience are able to receive HTML messages.
Most of the time with OE, when someone sends an HTML message, it arrives at the recipient with a plain text part, followed by an HTML attachment, followed by any pictures that you put in. I know this because my email reader is plain text only, and I see the text that they send even when they’ve sent it from OE as HTML. An HTML-capable reader will see this arrangement of attachments and show you the message with HTML formatting.
Every once in a while, I get HTML messages that have no plain text part. 99% of the time, these are spam. Out of the remainder, 99% of those are from Hotmail accounts. Apparently, Hotmail when configured to send HTML doesn’t send the plain text part first.
I’m wondering whether your message is going out somehow without the plain text part first, and is getting deleted along the way by a spam-killing bot.
All HTML messages I sent were received okay, so it’s either something gone mental with your system or else just restricted to the mail server you’re using.
Ah, a quick check of NTL’s service status page shows an unresolved mail problem:
I think the best idea will be for me to expedite my own SMTP solution and bypass NTL’s servers altogether. I’m thinking about using PostCast, but if anyone else has any suggestions for good (free) SMTP server programs, I’d be intertested to hear.
Not to be a shill for Microsoft, but one of the best features of Outlook 2003 is that (by default) it won’t render HTML emails. You can right-click on any of the pictures to download all of the pictures and other web components if you’d like, otherwise you can just delete the email without the sender being the wiser. This is a nice inbetween for us that like the concept of HTML mail but hate the spam.
Before you start running a SMTP server, check with NTL’s support dept first. Here is the relevant help page. When I spoke to them about this and other things - I work in IT - before signing up they said that they would perform checks for an open relay.
Ayuh, unless the person you are trying to send to has, like me, determined for themselves that any e-mail that arrives with html formatting is unlikely to contain anything of interest or importance, you are most likely being pegged as spam.
Here’s a typical report on a message intercepted by SpamAssassin:
Note how many of those indicators are purely related to formatting, regardless of content.
I doubt that your ISP’s POP server is running filters on your outgoing mail. It’s much more likely to be snagged at the other end. Sending as an attachment is probably the way to go.
Rex Fenestrarum: And, of course, none of the text-based Unix/Linux email clients will do anything with HTML (beyond what they do with normal text). This includes the rather easy to use pine, which `emulates’ a graphical environment in text. I also know Mozilla’s client, the graphical email client I prefer, can be trivially configured to not parse HTML.
In fact, the option of not parsing HTML is probably more widespread than the option to parse HTML, web-based clients excepted.
Well, the problem seems to have gone away now; I suspect it was connected with the problem Kal mentions above (it may be that the size of the HTML formatted messages (with emnbedded images) was a factor, if their server was under duress.
If you do insist on HTML email, one solution is not to include the images - reference them from an external site (in Outlook/Outlook Express, go to Insert => Images and type the URL of the image into the location box). This is what I do when my management insists on this sort of mail against my advice.