Re: HELP! TIdMessageEncoderMIME bugs: it's eating/adding chars

Giganews Newsgroups
Subject: Re: HELP! TIdMessageEncoderMIME bugs: it's eating/adding chars
Posted by:  Ciaran Costelloe (ccostell…
Date: Tue, 1 Jun 2004

"Bernardo Riveira" <> wrote in message
> I think I have found some serious bugs with Indy 9 which render it
> completely unusable for sending HTML encoded SMTP messages.
> Some patches ago, I found what Marcio Ehrlich said in his "missing dots in
> web addresses", which basically consisted in Indy 9 removing dots from
> emails and web addresses, so the HTML received had its URLs and response
> e-mail addresses mangled... But as Marcio said, that has been corrected.
> But now, with ContentTransfer='quoted-printable', I find some "=" signs on
> the received HTML (sometimes more than one),

Roughly, quoted-printable encoding splits long lines with "=" signs (soft
line breaks) which the receiver should strip out and join the lines back up

> and with
> text.ContentTransfer:='8bit', those = signs don't get into the HTML, but
> then if you have a line that starts with a dot ".", that dot will get
> removed, so things like CSS styles like:

After the sender does any encoding specified, it then must add an extra "."
dot to the start of _any_ line that starts with a "." which ensures a
message terminator CRLF.CRLF never gets confused with message content.  The
receiver must strip one dot from any line that starts with a dot.

Given that, can you narrow down your problem?

> <style>
> .caption = ...
> </style>
> received as:
> <style>
> caption=...
> </style>
> ...which of course is not the same thing, and so the HTML will not render
> correctly on the mail reader.  I tried other encodings ('7bit', which show
> the "=" signs) but every time I have seen this same problem.

If you really want to experiment, try base64 encoding which does not use "."
or "=".

> I tried downloading the latest version from the cvs repository (well, Team
> Coherence, not really CVS) so as to make sure I was using the most up to
> date version,

The latest version is Indy 10, which may suit you better (though please try
to isolate it further and tell us what happens with both versions).

> but that one didn't even compile (maybe is someone taking a
> look at the TIdMesageEncoderMIME? I hope so!)
> Thanks in advance
> Bernardo Riveira



In response to

HELP! TIdMessageEncoderMIME bugs: it's eating/adding chars posted by Bernardo Riveira on Tue, 1 Jun 2004