For Gambit - Indy10 left behind
Mike_
behavior
>in its apps. MS does not follow established RFCs very strictly like
>everyone else does
Not evryone else does! Friday this issue was solved in Java. So Indy lost!
Thank you for the support you've ever given me!
I think world isn't a standard. There are also parallel ways to be
considered!
And more ... remains (in my opinion) the possibility of an error, even not
accepted by you, in Indy at all levels (8, 9, 10)!
Mike_
Guillem
> Not evryone else does! Friday this issue was solved in Java. So Indy
> lost!
>
> Thank you for the support you've ever given me!
>
> I think world isn't a standard. There are also parallel ways to be
> considered!
> And more ... remains (in my opinion) the possibility of an error,
> even not accepted by you, in Indy at all levels (8, 9, 10)!
>
> Mike_
IMO, posts like this are not even worthy to answer. Oh, s***! i already
did <g>
--
Best regards :)
Guillem Vicens
Dep. Informática Green Service S.A.
www.clubgreenoasis.com
--
in order to contact me remove the -nospam
Mike_
did <g>
Anyhow, Indy has still to be elaborated to become suitable for a RAD
environment.
Otherwise, for various uncovered situations (which can give unpredictable
results - as an null attachment), we'll have to learn how to implement
different standards and protocols to substitute Indy. And this even though
is said there is available a library to do this.
I don't want to undermine the work of many persons who contributed to Indy,
but, from the users point of view, the wheel doesn't have to be reinvented.
At least in a RAD IDE as Delphi.
Regards :)
Mike_
Guillem
>
> Anyhow, Indy has still to be elaborated to become suitable for a RAD
> environment.
i don't agree. I have used Indy in a RAD way with little or no problem,
and when i had them it was mainly because of my lack of understanding
how the components worked
> Otherwise, for various uncovered situations (which can give
> unpredictable results - as an null attachment), we'll have to learn
> how to implement different standards and protocols to substitute
> Indy. And this even though is said there is available a library to do
> this.
so what? You want an Internet library where you simply pick a
component, drop it onto a form and it should do it all fine and alone?
Do you realize how many protocols is Indy implementing? That Indy is a
*totally* free library? No licenses, no limits, no money, therefore the
people developing it receive *almost* nothing else as being recognized
for their work? And even if it would be possible to cover all possible
situations, what would be the effort necessary to do it? All the Indy
developers work in other things to gain money for a living.
Besides, *no* RAD environment allows you to simply drop components and
voilà! there is my complex app working like charm. Except for very
simple apps, you'll always have to code some things on your own.
If you don't like Indy, you can always try ICS, Synapse, or stick with
the TServerSocket and TClientSocket classes and program the protocols
on your own
>
> I don't want to undermine the work of many persons who contributed to
> Indy,
IMO you did
> but, from the users point of view, the wheel doesn't have to be
> reinvented. At least in a RAD IDE as Delphi.
and how was it reinvented? It's not as simple as having Internet
components. The libraries usually use different approaches to
accomplish their goals. For example,
Indy: blocking sockets, multi-threaded, not event-driven
ICS: non-blocking sockets, single-threaded(possibility to use
multithread), event-driven
Both libraries do SMTP, for example, but using different approaches.
Which is best? It depends on what are your needs
--
Best regards
Mike_
>component, drop it onto a form and it should do it all fine and alone?
In this case (mine) was useless. And more undermined my work, as I develop
in Delphi and in java (JDK 1.4) was a question of only a couple of lines
(import and calls) to implement a simple app for downloading the attachment
of a mail (what could be simpler than that?!).
>> I don't want to undermine the work of many persons who contributed to
Indy,
>IMO you did
I do respect the work of everyone who developed in Indy!
>and how was it reinvented?
Wasn't! This is the point! And should stay like that! On both sides:
programmer - user. But if I have to substitute Indy in order only to get a
simple mail download ... in that case I reinvent (protocols and standards
implementations). I do not want to redevelop Indy, I want simply to use it!
I think that's enough! It's neither the place nor the moment to explain too
much in-depth.
Unfortunately was a simple Delphi app transformed into nothing, being
substituted by another one written in Java.
Mike_
Guillem
> But if I have to substitute Indy in order only to
> get a simple mail download
you don't need to. A lot of people have used Indy for such development
> ... in that case I reinvent (protocols and
> standards implementations). I do not want to redevelop Indy, I want
> simply to use it!
Do not simply blame Indy because it does not work for you. It could be
a bug, but it could also be you made the mistake
Won't reply more in this thread
--
Best regards
Ciaran Costelloe
> And more ... remains (in my opinion) the possibility of an error,
> even not accepted by you, in Indy at all levels (8, 9, 10)!
Rubbish. Indy 10 is parsing 5,000 emails a day here with no problems,
apart from me not having enough time to add UTF-8 support. If you are
generating emails that do not comply with the RFCs, some other clients
will _accidentally_ decode them (and fail on others), because they use
different parsing designs. One example is emails that use CRs or LFs
instead of CRLFs. There can be minor "issues" with Microsoft, but they
don't agree with non-RFC compliant emails.
Ciaran
Remy Lebeau (TeamB)
"Ciaran Costelloe" <ccost...@flogas.ie> wrote in message
news:4360...@newsgroups.borland.com...
> apart from me not having enough time to add UTF-8 support.
I've already begun work on that, though I don't think it can be enabled on
Win32 because decoding UTF-8 requires Unicode, which Indy doesn't support
under Win32 so there would be data loss for any non-Ascii strings.
Gambit
Mike_
"Ciaran Costelloe" <ccost...@flogas.ie>
> Rubbish. Indy 10 is parsing 5,000 emails a day here with no problems,
problem.
The only case when I had problems was with mails from a specific sender
(Debian).
And I didn't have problems in reading headers or even body text. Problems
came when downloading zip attachments.
Those zip archives had null content after downloaded with Indy POP3 in 10th
versions of Indy.
With the 8th version whatever downloaded was not even an archive. I've been
advised to change the version and I did it. With no results.
The code has been checked by more than one person. I've used also this code:
with TIdAttachment(lMessage.MessageParts.Items[I]) do
begin
Temp := OpenLoadStream;
try
ShowMessage(Sys.IntToStr(Temp.Size));
finally
CloseLoadStream;
end;
end;
sent by Gambit to see the dimension of the attachment and the result was 0
(null).
>If you are generating emails that do not comply with the RFCs ...
I don't generate mails, I only read them.
> ... emails that do not comply with the RFCs ... One example is emails that
use CRs or LFs instead of CRLFs.
Could be that!
Anyhow, now remains only the theoretical aspect. The application I talk of
has been replaced by a Java app.
I would like to know only if I've made some mistake in the use of Indy10.
Until now it wasn't clear where and if I did it.
I'm not a superspecialist and I used Indy 10 as it is also explained through
demos.
Mike_
Mike_
"Ciaran Costelloe" <ccost...@flogas.ie>
Please do read my message "Indy 10 doesn't read mails created on Linux
systems ?"
news:4360...@newsgroups.borland.com
Mike_
Ciaran Costelloe
My newsreader cannot access that link (probably something stupid I am
doing). The title of your message surprises me, because I use Linux
and get many emails from other Linux friends.
Can you send one of the emails directly to me at ccost...@flogas.ie
so that I can check it?
Ciaran
Ciaran Costelloe
I had not come across UTF-8 much before (apart from the MUTF-8 that I
added to TIdIMAP4) but I now see it coming in on attachment filenames
from some Microsoft users, where it is a pest because the users here
get perplexed when they see it. It does not even appear necessary in
the cases I see, because they are other Irish users with no strange
characters in the decoded name, though I totally agree it does not fit
in with the Win32 scenario.
Ciaran
Mike_
> My newsreader cannot access that link (probably something stupid I am
> doing). The title of your message surprises me, because I use Linux
> and get many emails from other Linux friends.
Essentialy I've said that I receive mails from a Debian Linux mail server.
With Indy 10 wasn't possible to read their attachment. Dimension of the
attachment (a zip file) was 0 (zero).
With Outlook was possible. With Java JDK 1.4 was also possible.
Starting from your idea and from Delphi documentation I presumed that mails
sent by a Debian Linux svr come with LF or CR (Linux style) instead of CR-LF
(Microsoft style).
Obviously Microsoft can handle those cases. Java also.
> Can you send one of the emails directly to me at ccost...@flogas.ie
> so that I can check it?
It isn't of use! If I resend that kind of mails (accross Outlook-MsExchange)
I can also read them. Obviously MS Exchange does some kind of
reinterpretation which gets the mail into standard.
Anyhow this issue (I presume) gives me problems not only for mails but also
for databases.
For example: if I connect to an Oracle database to a table with one field of
varchar2(2000) and if in that field exists new-line characters (CR-LF) on
the side of Oracle that couple is interpreted as one byte (LF I presume).
On Delphi side, in a TDBMemo, is interpeted as 2 bytes.
The result is very strange. If I put into that field 2000 characters
(including CRLF) when that record is fetched into the dataset (and displayed
through TDBMemo control) I loose the last character. (For example if the
last word -of those 2000 bytes- in the varchar2 field is LAST in TDBMemo
control can be seen LAS). That took me at one conclusion. When read from the
database the reading process takes into account the dimension of the field
but includes a supplementary byte for the pair CRLF and so looses one
character (the last one) not reading it because out of range (2000). What do
you say
Mike_
> so that I can check it?
I can give you the mail saved in ASCII and more important the section where
starts the attachment:
----1d41fa16ac0ef6d387d6500958ec6f1d
Content-type: application/x-zip-compressed;
name="EBG20051020AN.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="EBG20051020AN.zip"
UEsDBBQAAAAIANhYXDOtLME34BMAAA/KAAARAAAARUJHMjAwNTEwMjBBTi54bWztXV1v3Da6vl9g
The byte sequence that separates
filename="EBG20051020AN.zip"
of
UEsDBBQAAAAIANhYXDOtLME34BMAAA/KAAARAAAARUJHMjAwNTEwMjBBTi54bWztXV1v3Da6vl9g
(above is the first line of the attachment)
is
0D 0A 0D 0D 0A - STRANGE, NO?
And after every line of coded attachment there is the sequence: 0D 0D 0A
I don't know if this kind of byte sequence for new-line is handled by Indy10
and if not how can be handled?
As I understood from Gambit only LF and CRLF can be handled not
CR-LF-CR-CR-LF !!!
Mike_
Ciaran Costelloe
> > Can you send one of the emails directly to me at
> > ccost...@flogas.ie so that I can check it?
Copying-and-pasting does not help, because your newsreader
re-interprets the CRLFs. Can you copy-and-paste from a hex editor
(e.g. view it in Total Commander, and switch to hex view)?
Ciaran
Ciaran Costelloe
> Essentialy I've said that I receive mails from a Debian Linux mail
> server.
I doubt the mail server is at fault, they don't reformat the email, it
is more likely a Linux client.
> With Indy 10 wasn't possible to read their attachment.
> Dimension of the attachment (a zip file) was 0 (zero).
> With Outlook was possible. With Java JDK 1.4 was also possible.
> Starting from your idea and from Delphi documentation I presumed that
> mails sent by a Debian Linux svr come with LF or CR (Linux style)
> instead of CR-LF (Microsoft style).
The RFCs specify CRLFs for the line endings, whether the client is
Linux or Microsoft, and both Linux and Apple email clients generally
comply with this, which I just double-checked on some emails that I
received. On a Linux client, if it is not replacing the LFs with
CRLFs, then it is not compliant. This particularly happens when a user
does a copy-and-paste.
Obviously there is a problem when a Linux user wants to send a file
that will normally just have LFs, but in that case the Linux email
client should encode it as QuotedPrintable or even Base64.
The issue is not confined to Linux: I* also see it with text/html parts
which often have only LFs.
Some mail servers automatically reject emails that only have LFs.
> Obviously Microsoft can handle those cases. Java also.
This is often an accident. It is much slower to check for CRLFs
(because it is two bytes) than to check for either CRs or LFs and to
assume that if you find a CR, it is the first byte of a CRLF pair.
> > Can you send one of the emails directly to me at
> > ccost...@flogas.ie so that I can check it?
> It isn't of use! If I resend that kind of mails (accross
> Outlook-MsExchange) I can also read them. Obviously MS Exchange does
> some kind of reinterpretation which gets the mail into standard.
No, the mail is still non-standard.
> Anyhow this issue (I presume) gives me problems not only for mails
> but also for databases.
> For example: if I connect to an Oracle database to a table with one
> field of varchar2(2000) and if in that field exists new-line
> characters (CR-LF) on the side of Oracle that couple is interpreted
> as one byte (LF I presume). On Delphi side, in a TDBMemo, is
> interpeted as 2 bytes. The result is very strange. If I put into
> that field 2000 characters (including CRLF) when that record is
> fetched into the dataset (and displayed through TDBMemo control) I
> loose the last character. (For example if the last word -of those
> 2000 bytes- in the varchar2 field is LAST in TDBMemo control can be
> seen LAS). That took me at one conclusion. When read from the
> database the reading process takes into account the dimension of the
> field but includes a supplementary byte for the pair CRLF and so
> looses one character (the last one) not reading it because out of
> range (2000). What do you say
That is a different issue for a different forum, but databases always
return exactly what has been posted into the varchar field, and if your
program or a component re-interprets the line endings (replacing an LF
with a CRLF, for Linux, or a CR as a CRLF for Apple) and pushes
characters past the end of the buffer, that is a different issue.
Ciaran
Mike_
doesn't "read" mails created on Linux systems?).
They were the sequences 0D 0A 0D 0D 0A and 0D 0D 0A that caused the problem.
So it was the Linux client as you said maybe to produce this.
I'm still interested in finding out how to deal with such situations.
As for a sample mail, what I have now as a mail message is restricted
content, which, obviously, I cannot send it to anyone.
Other test message I can't get because the app was replaced by another one
and exited out of priorities.
Mike_
Ciaran Costelloe
> See the new evolution into news:43621147$1...@newsgroups.borland.com
> (Indy 10 doesn't "read" mails created on Linux systems?).
The email client that sent that email is _badly_ broken. It is not a
Linux issue: theoretically, you would have LFs instead of CRLFs, but
only in the unlikely event of a broken Linux client (and Indy could
probably deal with that, since it deals with LFs instead of CRLFs).
What you have is _extra_ CRs inserted. Are you using an old version of
Indy 10?
Ciaran
Mike_
> Linux issue: theoretically, you would have LFs instead of CRLFs, but
> only in the unlikely event of a broken Linux client (and Indy could
> probably deal with that, since it deals with LFs instead of CRLFs).
> What you have is _extra_ CRs inserted. Are you using an old version of
> Indy 10?
>
> Ciaran
I've downloaded Indy 10 less than two weeks ago.
The purpose of my (expired) application was to download a zip attachment and to unzip it.
What I wrote is what I've received.
So my issue is to handle received mails (even with this bug inside) not to build them.
Thanks
Mike_
I think we've overused this thread. If you have some idea how to deal with this situation using Indy10 I think is better to change thread.