Discussion:
indy 10... a piece of crap
(too old to reply)
twistedvoid
2006-03-28 05:53:05 UTC
Permalink
After spending hours cleaning up the mess the 'install program' made, I finally got the latest release of Indy 10 installed only to find that things that worked with indy 9, simple things mind you, are causing me major headaches with indy 10.

Example... antifreeze doesn't. period. I've seen my app on a dialup connection totally lock up for over a minute while indy tries to decide what to do. Yes, it's active, Yes, the app has priority, yes, chaged the timeout, onlywhenidle setting.. ect. ONE MINUTE freezes while working on just one e-mail. I know damn well it isn't my code causing the freezups and I don't have the time to rip out 1000 lines of code that would work fine if antifreeze worked and rearrange it into threads.

Next. Stupid things... like the smtp component not disconnecting properly. Here's my code:

procedure Tform1.dosmtpconnect(sender:tobject);
begin
application.processmessages;
try
try
log('SMTP','Sending: '+mailmessage.subject+' To: '+mailmessage.Recipients.EMailAddresses,form1);
SMTPclient.Connect;
SMTPclient.Send(MailMessage);
inc(msgssent);
except on E:Exception do
begin
log('SMTP','ERROR: ' + E.Message,form1);
smtperror:=true;
if sendingmail then
try
SMTPclient.Disconnect;
except;
// this code used to be in the smtpclient.ondisconnect event
// I had to move it here because Indy bombs every time
// I try to smtpclient.disconnect
sendingmail:=false;
smtpclient.Free;
if configform.sslcheckbox.Checked then
smtpsslsocket.free;
end;
end;
end;
finally
smtperror:=false;
if sendingmail then
try
SMTPclient.Disconnect
except
// this code used to be in the smtpclient.ondisconnect event
// I had to move it here because Indy bombs every time
// I try to smtpclient.disconnect
sendingmail:=false;
smtpclient.Free;
if configform.sslcheckbox.Checked then
smtpsslsocket.free;
end;
end;
end;

Seems simple enough. But, I had to put the smtpondisconnect routines into the try/except blocks because Indy, in some wisdom beyond mine, is disconnecting the smtp somewhere in the middle of disconnecting, raises an exception and never gets to the ondisconnect routine. Even if I tell it,

if smtpclient.connected then smtpclient.disconnect

it comes back true true on .connected and gives me an exception with the smtpclient.disconnect. 'connection gracefully closed.' There isn't a damn thing graceful about something that simple that worked in indy 9 and doesn't work in indy 10.

next thing, intuitive shit that should work doesn't...

The only reason I even went through the agony of installing indy 10 and rewriting my code was so I could put 'inline' 'text/plain' message parts in the message. Stupid me for thinking Indy 10 could do it when Indy 9 couldn't.

Here's what I'm trying to do.
messagepart:=tidtext.Create(mailmessage.messageparts);
messagepart.Body.Text:=mystrings.Strings.Text;
messagepart.ContentType:='text/plain';
messagepart.Headers.Add('Content-Disposition: inline');

You would think that the headers.add would add a header line in that messagepart. I thot so. It doesn't. You would think that those writing the Indy code would give me a messagepart.contentdisposition string in tidtext like they do with tidattachment. Even though the RFC's allow this type attachment. They don't.
Yes, I tried using tidattachment. Damned if I can figure a way to assign a string list as the body of a tidattachment, there's no tidattachment.body to assign it to. Forget tidattachmentfile. I want a string list, a small notice attached to every outgoing e-mail message, not a mime encoded attachment and I don't want to have to savetofile my string list then reload it into the attachment and then delete the file when I'm done.

And while I'm ranting: The tidlogfile with the smtp component has ceased to be of use. I was using it to debug the connection between my client and the servers. The POP intercept seems to work just fine. Here's what I get with the SMTP intercept:

Stat Connected.
Stat Disconnected.
Stat Connected.
Stat Disconnected.
Stat Connected.
Stat Disconnected.
Stat Connected.
Stat Disconnected.
Stat Connected.
Stat Disconnected.
Stat Disconnected.

Damned useful. And I know e-mail was being sent and recieved in the midst of those connects and disconnects. Worked in Indy 9. Crap in Indy 10.

The only reason I started using Indy and became a traitor to ICS was because I needed SSL and I didn't have years to wait for the ICS crew to get around to writing SSL for the pop and smtp components and then, wait another year for them to release it to the public. Now I'm regretting my decision. I should have just told my customers to stay the hell away from g-mail and use a less paranoid POP/SMTP server so that I could use a less screwed up POP/SMTP component set.
twistedvoid
2006-03-28 06:26:37 UTC
Permalink
Furthermore, I can't even intercept what the log intercepts
because when you doubleclick on the idlogfile.onreceive event
to create a new procedure you get this:

procedure IdLogFile2Receive(ASender: TIdConnectionIntercept; var ABuffer: TBytes);
begin
showmessage('This really sucks.');
end;

Try to compile it and 'undeclared identifier Tbytes'.
Remy Lebeau (TeamB)
2006-03-28 12:19:32 UTC
Permalink
Post by twistedvoid
Furthermore, I can't even intercept what the log intercepts
because when you doubleclick on the idlogfile.onreceive event
procedure IdLogFile2Receive(ASender: TIdConnectionIntercept; var ABuffer: TBytes);
begin
showmessage('This really sucks.');
end;
Try to compile it and 'undeclared identifier Tbytes'.
That is a known Delphi bug, not an Indy one.


Gambt
twistedvoid
2006-03-28 12:27:40 UTC
Permalink
Post by twistedvoid
Post by twistedvoid
Furthermore, I can't even intercept what the log intercepts
because when you doubleclick on the idlogfile.onreceive event
procedure IdLogFile2Receive(ASender: TIdConnectionIntercept; var
ABuffer: TBytes);
Post by twistedvoid
begin
showmessage('This really sucks.');
end;
Try to compile it and 'undeclared identifier Tbytes'.
That is a known Delphi bug, not an Indy one.
Then that brings to question... why even use Tbytes if it's a known bug.
Post by twistedvoid
Gambt
Remy Lebeau (TeamB)
2006-03-28 19:56:59 UTC
Permalink
Post by twistedvoid
Then that brings to question... why even use Tbytes if it's a known bug.
It doesn't. It uses TIdBytes instead. The bug is that Delphi parses the
signature wrong when generating the event handler. As for why TIdBytes is
used in the event, it is because the Intercept system in Indy 10 is based on
TIdBytes to begin with. It Indy 9, it was based on Streams instead.


Gambit
Remy Lebeau (TeamB)
2006-03-28 12:18:59 UTC
Permalink
Post by twistedvoid
After spending hours cleaning up the mess the 'install program' made
What "mess" are you referring to?
Post by twistedvoid
I finally got the latest release of Indy 10 installed only to find that
things
Post by twistedvoid
that worked with indy 9, simple things mind you, are causing me major
headaches with indy 10.
Such as?
Post by twistedvoid
antifreeze doesn't. period.
TIdAntiFreeze has always been a bastardized component, even in older
versions of Indy. You should avoud TIdAntiFreeze whenever possible, even in
older versions.
Post by twistedvoid
I know damn well it isn't my code causing the freezups and I don't have
the time to rip out 1000 lines of code that would work fine if antifreeze
worked and rearrange it into threads.
You should have been using threads to begin with.
Post by twistedvoid
Next. Stupid things... like the smtp component not disconnecting
properly.

What makes you think that?
Use this code instead:

procedure Tform1.dosmtpconnect(ASender: TOobject);
begin
Application.ProcessMessages;
try
try
log('SMTP', 'Sending: ' + MailMessage.Subject + ' To: ' +
MailMessage.Recipients.EMailAddresses, Form1);
SMTPClient.Connect;
try
SMTPClient.Send(MailMessage);
Inc(msgssent);
finally
SMTPClient.Disconnect;
end;
finally
sendingmail := False;
FreeAndNil(SMTPClient);
if configform.sslcheckbox.Checked then
FreeAndNil(smtpsslsocket);
end;
smtperror := False;
except
on E: Exception do
begin
smtperror := True;
log('SMTP', 'ERROR: ' + E.Message, Form1);
end;
end;
end;
Post by twistedvoid
Seems simple enough. But, I had to put the smtpondisconnect routines
into the try/except blocks because Indy, in some wisdom beyond mine,
is disconnecting the smtp somewhere in the middle of disconnecting
No, that was your fault, not Indy's. You should not have been using the
OnDisconnect event to disconnect and free the sockets. That was just plain
wrong, in any version of Indy.
Post by twistedvoid
next thing, intuitive shit that should work doesn't...
Such as?
Post by twistedvoid
The only reason I even went through the agony of installing indy 10 and
rewriting my code was so I could put 'inline' 'text/plain' message parts
in
Post by twistedvoid
the message.
You did not need Indy 10 for that.
Post by twistedvoid
Stupid me for thinking Indy 10 could do it when Indy 9 couldn't.
Why do you think that Indy 10 cannot do it? Indy 10's message handling is
vastly more complete than Indy 9's is.
Post by twistedvoid
You would think that the headers.add would add a header line in that
messagepart. I thot so. It doesn't.
You need to add custom headers to the ExtraHeaders property, not the Headers
property. The Headers property is only for those values that provide the
backend for the cooresponding TIdMessagePart, TIdText, and TIdAttachment
properties. Everything else is Extra.
Post by twistedvoid
You would think that those writing the Indy code would give me a
messagepart.contentdisposition string in tidtext like they do with
tidattachment.

Why, though? There is no reason to declare text as 'inline' - it is already
inlined by its very nature. Why do you need 'Content-Disposition: inline'
for text?
Post by twistedvoid
Yes, I tried using tidattachment. Damned if I can figure a way to assign
a
Post by twistedvoid
string list as the body of a tidattachment, there's no tidattachment.body
to
Post by twistedvoid
assign it to.
TIdAttachmentMemory has a DataStream property. You can save the TStringList
to that TStream, either directly or via the
TIdAttachment.PrepareTempStream() method.

Alternatively, TIdAttachmentMemory accepts a String as a parameter to its
constructor. You can pass the TStringList's Text property as that value.

Alternatively, you can write your own TIdAttachment-derived class that holds
a TStringList internally. One of the new features in Indy 10 is that the
TIdAttachment architecture is no longer locked down to files only.
TIdAttachment is an abstract base that that user-defined classes can be
derived from now. Indy just happens to provide TIdAttachmentMemory and an
alternative to TIdAttachmentFile, but you are not required to use it if it
does not suit your needs.
Post by twistedvoid
Forget tidattachmentfile.
See above.
Post by twistedvoid
And while I'm ranting: The tidlogfile with the smtp component has ceased
to be of use.

And your actual problem is ... ? Please be more specific.
Post by twistedvoid
Damned useful. And I know e-mail was being sent and recieved in the midst
of
Post by twistedvoid
those connects and disconnects. Worked in Indy 9. Crap in Indy 10.
If it is working in TIdPOP3, then it is guaranteed to work in every other
component as well, including TIdSMTP. They all send their data to the same
place, which is where the Intercept is implemented. It is not possible for
any Indy component to send outgoing data, or receive incoming data, without
that data going through the Intercept system.
Post by twistedvoid
The only reason I started using Indy and became a traitor to ICS was
because
Post by twistedvoid
I needed SSL and I didn't have years to wait for the ICS crew to get
around to
Post by twistedvoid
writing SSL for the pop and smtp components and then, wait another year
for
Post by twistedvoid
them to release it to the public. Now I'm regretting my decision. I
should have
Post by twistedvoid
just told my customers to stay the hell away from g-mail and use a less
paranoid
Post by twistedvoid
POP/SMTP server so that I could use a less screwed up POP/SMTP component
set.
Indy works just fine with GMail. Many users have reported that they have
been able to use Indy with GMail without problems. And the latest Indy 10
snapshot has full support for the standard OpenSSL DLLS now, so the SSL
support is even more stable.


Gambit
twistedvoid
2006-03-28 12:26:10 UTC
Permalink
Post by Remy Lebeau (TeamB)
Post by twistedvoid
antifreeze doesn't. period.
TIdAntiFreeze has always been a bastardized component, even in older
versions of Indy. You should avoud TIdAntiFreeze whenever possible, even in
older versions.
Antifreeze worked in Indy 9. Does not in Indy 10.
Post by Remy Lebeau (TeamB)
You should have been using threads to begin with.
The more complex you make the plumbing the easier it is to stop
up the drain. I have no need for threads. I'm not doing
multiple things here. I'm making one POP connection,
downloading and making one SMTP connection and uploading. If
the antifreeze in 10 would work as it should, I could drop one
little component on the form, activate it and problem solved.
Compare that to the bottle of aspirin needed for me to deal with
threads and it's not a difficult choice.
Post by Remy Lebeau (TeamB)
Post by twistedvoid
Next. Stupid things... like the smtp component not disconnecting
properly.
What makes you think that?
Did that, still bombing. Modified it:
log('SMTP', 'Sending: ' + MailMessage.Subject + To: ' +MailMessage.Recipients.EMailAddresses, Form1);
SMTPClient.Connect;
try
log('SMTP','Client connected',form1);
SMTPClient.Send(MailMessage);
log('SMTP','Message Sent',form1);
Inc(msgssent);
finally
SMTPClient.Disconnect;
end;

Never gets to 'Client connected' It claims that the server is
disconnecting while the program is still trying to send. It's
probably something ignorant like a password problem. But, since
I can't see the actual output from the SMTP server, and the only
response Indy gives me is 'gracefully disconnected', I don't
have a clue.
Post by Remy Lebeau (TeamB)
No, that was your fault, not Indy's. You should not have been using the
OnDisconnect event to disconnect and free the sockets. That was just plain
wrong, in any version of Indy.
My formal computer education consists of a Pascal course on the
DEC10 in 1982. To me, a try/except is just a glorified
if/then. My code may have not been pretty, but it worked in
Indy 9.
Post by Remy Lebeau (TeamB)
Post by twistedvoid
The only reason I even went through the agony of installing indy 10 and
rewriting my code was so I could put 'inline' 'text/plain' message parts
in
Post by twistedvoid
the message.
Why do you think that Indy 10 cannot do it? Indy 10's message handling is
vastly more complete than Indy 9's is.
Thanks, I'll try that, as soon as I can get the software sending mail again.
Post by Remy Lebeau (TeamB)
Post by twistedvoid
You would think that those writing the Indy code would give me a
messagepart.contentdisposition string in tidtext like they do with
tidattachment.
Why, though? There is no reason to declare text as 'inline' - it is already
inlined by its very nature. Why do you need 'Content-Disposition: inline'
for text?
If you want to display text after an HTML part you have to put
that 'inline' in there, otherwise, the email client doesn't
display it. Hence, when AVG scans an email, it inserts a tag as
such:

-------------------------------1143221539--
--=======AVGMAIL-44283FC07536=======
Content-Type: text/plain; x-avg=cert; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Content-Description: "AVG certification"

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.2.6/287 - Release Date: 3/21/2006

--=======AVGMAIL-44283FC07536=======--

The best I've come up with is that 'inline' guarantees that
messagepart will be shown regardless of how many other
messageparts exist.
Post by Remy Lebeau (TeamB)
TIdAttachmentMemory has a DataStream property. You can save the TStringList
to that TStream, either directly or via the
TIdAttachment.PrepareTempStream() method.
Alternatively, TIdAttachmentMemory accepts a String as a parameter to its
constructor. You can pass the TStringList's Text property as that value.
Alternatively, you can write your own TIdAttachment-derived class that holds
a TStringList internally. One of the new features in Indy 10 is that the
TIdAttachment architecture is no longer locked down to files only.
TIdAttachment is an abstract base that that user-defined classes can be
derived from now. Indy just happens to provide TIdAttachmentMemory and an
alternative to TIdAttachmentFile, but you are not required to use it if it
does not suit your needs.
Sounds like a lot of work. I classify streams right up there
with threads and pointers. Great if you wanna shave off a few
picoseconds, a pain in the ass when it just doesn't matter.
Post by Remy Lebeau (TeamB)
Post by twistedvoid
those connects and disconnects. Worked in Indy 9. Crap in Indy 10.
If it is working in TIdPOP3, then it is guaranteed to work in every other
component as well, including TIdSMTP. They all send their data to the same
place, which is where the Intercept is implemented. It is not possible for
any Indy component to send outgoing data, or receive incoming data, without
that data going through the Intercept system.
If what you say is true, then for some reason, the Indy group
decided that nobody needs to see the actual communications with
the SMTP server anymore. You saw exactly what I get.
Post by Remy Lebeau (TeamB)
Indy works just fine with GMail. Many users have reported that they have
been able to use Indy with GMail without problems. And the latest Indy 10
snapshot has full support for the standard OpenSSL DLLS now, so the SSL
support is even more stable.
Yes, I am connecting and was sending through G-mail (until I
'upgraded'). However, the fact is that I've had to reinstall
Delphi due to a screwed-up Indy install, spend hours rooting out
old Indy 9 code scattered everywhere, download a working copy
of Indy 10, (1.15 still gives me a corrupt download), install it
and rewrite the program to use Indy 10 instead of 9, learn Indy
from scratch and SSL from scratch... all to satisfy Google's
paranoia. Whereas, if ICS, which I've used for years, had SSL
for POP and SMTP or if I had said the hell with Google (smite me
now daytraders) I would have been done a month ago and with lot
less coding.

Thanks for the advice but from what I've seen of the SMTP and
Antifreeze units, Indy 10, compared with 9... is crap.
Guillem
2006-03-28 16:12:50 UTC
Permalink
Post by twistedvoid
The more complex you make the plumbing the easier it is to stop
up the drain. I have no need for threads. I'm not doing
multiple things here. I'm making one POP connection,
downloading and making one SMTP connection and uploading. If
the antifreeze in 10 would work as it should, I could drop one
little component on the form, activate it and problem solved.
Compare that to the bottle of aspirin needed for me to deal with
threads and it's not a difficult choice.
Indy is and AFAIK has always used a multi-threaded non-event-driven
blocking synchronous approach, while ICS uses a single-threaded
(although it's possible to make it multi-threaded) event-driven
non-blocking asynchronous way to do things.

You simply can't use Indy as you would use ICS.
Post by twistedvoid
Thanks for the advice but from what I've seen of the SMTP and
Antifreeze units, Indy 10, compared with 9... is crap.
Then don't use it
--
Best regards :)

Guillem Vicens Meier
Dep. Informatica Green Service S.A.
www.clubgreenoasis.com
--
Contribute to the Indy Docs project: http://docs.indyproject.org
--
In order to contact me remove the -nospam
John Jacobson
2006-03-28 19:05:19 UTC
Permalink
Post by twistedvoid
I have no need for threads.
Then you need to use a non-blocking framework like ICS. Indy is a blocking
framework, intended for threaded use.

The future of good software development is in threads, because the new CPU's
are hyperthreaded and/or multicore and software needs to take advantage of
that architecture to appear responsive and efficient. The sooner you start
writing multithreaded code the sooner you will get comfortable with it.
twistedvoid
2006-03-28 21:28:10 UTC
Permalink
Post by John Jacobson
Post by twistedvoid
I have no need for threads.
Then you need to use a non-blocking framework like ICS. Indy is a blocking
framework, intended for threaded use.
The future of good software development is in threads, because the new CPU's
are hyperthreaded and/or multicore and software needs to take advantage of
that architecture to appear responsive and efficient. The sooner you start
writing multithreaded code the sooner you will get comfortable with it.
Agreed. I like ICS, wish I could use it, it's simple, like me.
Unfortunately, it does not do any form of POP or SMTP SSL/TSL.

Re: the future of good software-

Cars used to use carburetors. Now they use fuel injection. Fuel injection, they said, was more efficient. Damned if it isn't. What they neglected to tell us years ago was that fuel injection is also a lot more complex than carburetors. Buy a shadetree mechanic a six pack of beer and he'll fix your carburetor. Hand your credit card to a school educated mechanic in a greaseless white suit and he'll fix your fuel injection.

I graduated to Turbo Pascal from GWBasic. Programming was a 'hobby' I took up that allowed me to manipulate text files faster than I could manually. Pascal was an easy language to learn. Anyone with a little time could comprehend it. It was a six pack of beer.

Look at Delphi now. Threads, streams, pointers, OOP, etc. The only resemblance between Pascal and Delphi is the semicolon. Delphi has become fuel injection that needs a credit card education to understand.

I like beer and carburetors.
Ciaran Costelloe
2006-03-28 23:38:04 UTC
Permalink
Post by twistedvoid
Cars used to use carburetors. Now they use fuel injection.
...
Post by twistedvoid
I graduated to Turbo Pascal from GWBasic.
You have learned more in the intervening period, and are tackling more
ambitious problems. Adding SSL SMTP functionality to your application
is like adding a turbo and cooling the inlet manifold without learning
about them: you will be lucky if it even starts.

Sooner or later, you will end up dealing with threading, exceptions and
streams. Indy has had similar problems: relevant to you, emails were
just single-part plain-text, then attachments were embedded as UUE or
XXE encodings, then MIME parts were added, and multipart's, QP, base64,
BinHex, TNEF, etc. Indy 9's email structure could not cope, the
structure had to be changed in Indy 10. It will have to be changed
again when my granny wants to send me 3D interactive emails, and
undoubtedly you will want to use this feature in the next version of
your program.

You have an option to read and implement all the current and future
RFCs on emails (and there are lots) which the Indy developers had to
do, a bit like making a turbo from a block of steel, or learn
Indy/ICS/etc, as in how to fit a turbo. For your specific problem, you
also need to read http://www.flogas.ie/indy/indymsg.html or Gambit's
blog (he posted the link elsewhere in this group).
Post by twistedvoid
I like beer and carburetors.
I like the feeling of a turbo kicking in (and beer).

Ciaran
Loren Pechtel
2006-03-29 15:53:16 UTC
Permalink
On 28 Mar 2006 14:28:10 -0700, "twistedvoid"
Post by twistedvoid
Cars used to use carburetors. Now they use fuel injection. Fuel injection, they said, was more efficient. Damned if it isn't. What they neglected to tell us years ago was that fuel injection is also a lot more complex than carburetors. Buy a shadetree mechanic a six pack of beer and he'll fix your carburetor. Hand your credit card to a school educated mechanic in a greaseless white suit and he'll fix your fuel injection.
This is true. My father used to tell a story of changing IIRC the
water pump on some ancient car while wearing a tuxedo--it was simple
enough he could actually do it without getting the tuxedo dirty.

Remy Lebeau (TeamB)
2006-03-28 20:39:55 UTC
Permalink
Post by twistedvoid
The more complex you make the plumbing the easier it is to stop
up the drain. I have no need for threads. I'm not doing
multiple things here. I'm making one POP connection,
downloading and making one SMTP connection and uploading. If
the antifreeze in 10 would work as it should, I could drop one
little component on the form, activate it and problem solved.
Compare that to the bottle of aspirin needed for me to deal with
threads and it's not a difficult choice.
TIdAntiFreeze works the same in Indy 10 that it did in Indy 9.
Post by twistedvoid
Did that, still bombing.
You need to be more specific. You haven't provided ANY details about what
EXACTLY is hanppening.
Post by twistedvoid
SMTPClient.Connect;
try
log('SMTP','Client connected',form1);
<snip>
Post by twistedvoid
Never gets to 'Client connected'
The only way that can happen is if the socket is not actually connecting to
the server at all. Did you set the ConnectTimeout property to a
non-infinite value? Did you verify that you are specify a valid Host and
Port for the server?

Incidently, you were using the OnDisconnect event earlier. Are you using
the OnConnect event as well? If so, what does that code look like?
OnConnect is triggered after the underlying socket connects to the server
socket, but before TIdSMTP actually negotiates the login with the server.
So, if you are doing anything with the socket inside that event, you could
be screwing up the data exchange, such that Connect() hangs waiting for data
that it never receives because you received in your own code.
Post by twistedvoid
It claims that the server is disconnecting while the program is still
trying to send.

But your code is not sending anything at all if Connect() is not succeeding.
Post by twistedvoid
It's probably something ignorant like a password problem.
If that were the case, then Connect() would be throwing an exception when
the server reports a login error.
Post by twistedvoid
My formal computer education consists of a Pascal course on
the DEC10 in 1982. To me, a try/except is just a glorified if/then.
Hardly. You need to brush up on what exception handling is actually about.
It is much more complex then a simple if/then, and much more flexible.
Indy's architecture relies heavily on exceptions.
Post by twistedvoid
My code may have not been pretty, but it worked in Indy 9.
Only by a fluke on your part. Then code you showed was not effecient even
for Indy 9.
Post by twistedvoid
If you want to display text after an HTML part you have to
put that 'inline' in there, otherwise, the email client doesn't
display it. Hence, when AVG scans an email, it inserts a tag
Fair enough. Like I said earlier, the TIdMessagePart.ExtraHeaders property
can be used for that.
Post by twistedvoid
The best I've come up with is that 'inline' guarantees that
messagepart will be shown regardless of how many other
messageparts exist.
The formal defination of the 'Content-Disposition' header is defined in RFC
2183:

Communicating Presentation Information in Internet Messages: The
Content-Disposition Header Field
http://www.ietf.org/rfc/rfc2183.txt
Post by twistedvoid
Sounds like a lot of work. I classify streams right up there
with threads and pointers. Great if you wanna shave off a few
picoseconds, a pain in the ass when it just doesn't matter.
All the more reason to write your own TIdAttachment-derived class to do what
you need. Look at TIdAttachmentFile.pas and TIdAttachmentMemory.pas to see
how they are implemented.
Post by twistedvoid
If what you say is true, then for some reason, the Indy group decided
that nobody needs to see the actual communications with the SMTP
server anymore.
You completely missed the point I was making. *ALL* Indy traffic, both
inbound and outbound, goes through the Intercept system. There is no way
that TIdSMTP can be sending data to the SMTP server without the Intercept
system seeing it. Thus, the TIdLog components must be able to log *ALL*
data that Indy exchanges, regardless of the component being used.
Everything that Indy sends ultimately goes through
TIdIOHandler.WriteDirect(), which is where the Intercept for outbound data
is invoked. The only place that receives data from the connection directly
is in TIdIOHandlerStack.ReadFromSource(), which is where the Intercept for
inbound data is invoked. What you describe is simply not possible. And if,
by some chance, it were possible, it would have been seen and addressed a
long time ago.
Post by twistedvoid
However, the fact is that I've had to reinstall Delphi due to a screwed-up
Indy install

... to which you still have not provided any details ...
Post by twistedvoid
learn Indy from scratch and SSL from scratch...
You do not need to re-learn Indy or SSL from scratch in order to migrate
from 9 to 10.


Gambit
twistedvoid
2006-03-28 21:09:02 UTC
Permalink
Post by Remy Lebeau (TeamB)
But your code is not sending anything at all if Connect() is not succeeding.
Post by twistedvoid
It's probably something ignorant like a password problem.
I was right, it was something ignorant. It was a problem with
the wrong port number. I had the program written in Indy set to
the same port as my netscape email client, 465. The e-mail
client sent SMTP fine through that port, the program didn't. I
set the program to port 587 and it started working. I still
have no idea why netscape email has no problem with port 465 but
the program written with Indy does.
Post by Remy Lebeau (TeamB)
Post by twistedvoid
My formal computer education consists of a Pascal course on
the DEC10 in 1982. To me, a try/except is just a glorified if/then.
Hardly. You need to brush up on what exception handling is actually about.
It is much more complex then a simple if/then, and much more flexible.
Indy's architecture relies heavily on exceptions.
Agreed, but in the past few years, there have been so many
'changes'; OOP, pointers, streams, threads, exceptions, and a
host of other 'creations' that I spend more time learning how to
rewrite the same Pascal I've known for over 20 years, than I do actually writing software.
Post by Remy Lebeau (TeamB)
Post by twistedvoid
My code may have not been pretty, but it worked in Indy 9.
Only by a fluke on your part. Then code you showed was not effecient even
for Indy 9.
Agreed. But I'm a 'if it works, don't mess with it' kinda guy.
Post by Remy Lebeau (TeamB)
Post by twistedvoid
If you want to display text after an HTML part you have to
put that 'inline' in there, otherwise, the email client doesn't
display it. Hence, when AVG scans an email, it inserts a tag
Fair enough. Like I said earlier, the TIdMessagePart.ExtraHeaders property
can be used for that.
I tried your extraheaders and it added the header just fine,
thanks for that. But, it put the messagepart in the wrong
place. In order for the 'inline' attachment to be displayed
properly it has to come after all other messageparts, including
attachments. When Indy assembles the message it lumps all text
messageparts together. For example: Create a textpart then add
a file attachment. Then add in my 'inline' attachment as
TIDtext, it gets placed between the text part and the file
attachment.

I need this

Textpart
HTMLpart
FileAttachment
'Inline' part

I get this

Textpart
'Inline' part
HTMLpart
FileAttachment
Post by Remy Lebeau (TeamB)
Post by twistedvoid
The best I've come up with is that 'inline' guarantees that
messagepart will be shown regardless of how many other
messageparts exist.
All the more reason to write your own TIdAttachment-derived class to do what
you need. Look at TIdAttachmentFile.pas and TIdAttachmentMemory.pas to see
how they are implemented.
Even if I do write my own class for this, will the mesageparts be added to the message in the order I create them, or the order predetermined by Indy?
Post by Remy Lebeau (TeamB)
Everything that Indy sends ultimately goes through
TIdIOHandler.WriteDirect(), which is where the Intercept for outbound data
is invoked. The only place that receives data from the connection directly
is in TIdIOHandlerStack.ReadFromSource(), which is where the Intercept for
inbound data is invoked. What you describe is simply not possible. And if,
by some chance, it were possible, it would have been seen and addressed a
long time ago.
Oh, I understood, I simply couldn't understand why I was getting
a connect message where it was obviously connecting to the port
but then, not doing anything. Once I got the port number set
properly, it started displaying traffic. It's also going to be
very confusing for my customers should they set the port
improperly as Indy with just display 'connection closed
gracefully.' Not a very helpful error message.
Post by Remy Lebeau (TeamB)
You do not need to re-learn Indy or SSL from scratch in order to migrate
from 9 to 10.
No, only some minor differences and additions. What I'm saying,
when I started this, ICS was the only internet component squite
I've used and have never had to use SSL. Indy is very
different. For me, (read old), there's a learning curve
involved in that.

Again, thanks for the help.
Remy Lebeau (TeamB)
2006-03-29 02:31:54 UTC
Permalink
I had the program written in Indy set to the same port as my netscape
email client, 465. The e-mail client sent SMTP fine through that port,
the program didn't. I set the program to port 587 and it started
working. I still have no idea why netscape email has no problem
with port 465 but the program written with Indy does.
Port 465 is for SSMTP, aka SMTP with SSL. You have to attach Indy's SSL
IOHandler class to the TIdSMTP in order for it to handle SSL connections.
Now your earlier hanging makes complete sense, since Connect() is trying to
read SMTP data over an encrypted connection that it does not understand how
to manage by default.

Also, just for reference, the standard SMTP port is 25, not 587. 587 is for
the Submission protocol, which has nothing to do with SMTP.
I tried your extraheaders and it added the header just fine,
thanks for that. But, it put the messagepart in the wrong
place.
Indy 10 writes the message parts in the order that they appear in the
collection. It is your own responsibility to make sure the parts are in the
order that you need them to be in, and that their ParentParts properties are
set correcty.
In order for the 'inline' attachment to be displayed properly it has
to come after all other messageparts, including attachments.
Then simply add your 'inline' part at the end of the MessageParts
collection.
When Indy assembles the message it lumps all text messageparts together.
Indy 10 writes them in the order they appear in the collection.
For example: Create a textpart then add a file attachment. Then add
in my 'inline' attachment as TIDtext, it gets placed between the text
part and the file attachment.
That may have been the case in Ind 9 , but that is not the case in Indy 10.
I need this
Textpart
HTMLpart
FileAttachment
'Inline' part
For Indy 10, you can set tht up using the following:

IdMessage.ClearBody;
IdMessage.ContentType := 'multipart/mixed';

TIdText.Create(IdMessage.MessageParts, nil).ContentType :=
'multipart/alternative';

with TIdText.Create(IdMessage.MessageParts, nil) do
begin
ContextType := 'text/plain';
Body.Text := 'whatever';
ParentPart := 0;
end;

with TIdText.Create(IdMessage.MessageParts, nil) do
begin
ContextType := 'text/html';
Body.Text := '<html>whatever</html>';
ParentPart := 0;
end;

with TIdAttachmentFile(IdMessage.MessageParts, 'filename.ext') do
begin
ContentType := GetMimeTypeFromFile('filename.ext');
ParentPart := -1;
end;

with TIdText.Create(IdMessage.MessageParts, nil) do
begin
ContextType := 'text/plain';
Body.Text := 'whatever';
ExtraHeaders.Values['Content-Disposition'] := 'inline';
ParentPart := -1;
end;
Even if I do write my own class for this, will the mesageparts be added to
the message in the order I create them

In Indy 10, yes.
Oh, I understood, I simply couldn't understand why I was
getting a connect message where it was obviously connecting to
the port but then, not doing anything. Once I got the port number
set properly, it started displaying traffic. It's also going to be very
confusing for my customers should they set the port improperly as
Indy with just display 'connection closed gracefully.' Not a very
helpful error message.
There is nothing you or Indy can do about that. If there is a server
listening on that port, then Indy will connect to it. If the data that is
exchanged on that socket is not what Indy expects, it has no way to detect
that ahead of time.

However, all is not lost. TIdSMTP in Indy 10 has built-in support for port
SSMTP on port 587. All you have to do is attach the SSL IOHandler to the
TIdSMTP before calling Connect(), and then set the UseTLS property to a
value other than utNoTLSSupport, ie:

utUseImplicitTLS uses SSL unconditionally from the moment the socket is
connected (which appears to be what your server is expecting in this
situation).

utUseRequireTLS and utUseExplicitTLS allow TIdSMTP to query the server for
its capabilities after connecting and then enable SSL dynamically only if
the server allows it.


Gambit
Loren Pechtel
2006-03-29 15:53:16 UTC
Permalink
On 28 Mar 2006 05:26:10 -0700, "twistedvoid"
Post by twistedvoid
Post by Remy Lebeau (TeamB)
Post by twistedvoid
antifreeze doesn't. period.
TIdAntiFreeze has always been a bastardized component, even in older
versions of Indy. You should avoud TIdAntiFreeze whenever possible, even in
older versions.
Antifreeze worked in Indy 9. Does not in Indy 10.
Post by Remy Lebeau (TeamB)
You should have been using threads to begin with.
The more complex you make the plumbing the easier it is to stop
up the drain. I have no need for threads. I'm not doing
multiple things here. I'm making one POP connection,
downloading and making one SMTP connection and uploading. If
the antifreeze in 10 would work as it should, I could drop one
little component on the form, activate it and problem solved.
Compare that to the bottle of aspirin needed for me to deal with
threads and it's not a difficult choice.
Antifreeze is a partial solution to the problems caused by not using
threads but it's nowhere near a complete solution. Comm activity is
slow, it should be in a thread.
tony caduto
2006-03-28 14:04:51 UTC
Permalink
Post by Remy Lebeau (TeamB)
And the latest Indy 10
snapshot has full support for the standard OpenSSL DLLS now, so the SSL
support is even more stable.
That is good news, that was one of the reasons I switched to Synpase.
--
Tony Caduto
AM Software Design
Home of PG Lightning Admin for Postgresql
http://www.amsoftwaredesign.com
Remy Lebeau (TeamB)
2006-03-28 20:41:27 UTC
Permalink
Post by tony caduto
That is good news, that was one of the reasons I switched to Synpase.
The latest snapshot of Indy 10 has been tested with the latest OpenSSL
0.9.8a DLLs.


Gambit
twistedvoid
2006-03-28 21:57:36 UTC
Permalink
I ripped out Indy 10, downloaded and installed the latest Indy 9 and my program is back in operation including a TidAntifreeze that works.

Thanks for all the help and suggestions, I do appreciate them.

One final note: Many suggested I was using Indy wrong. That it
uses a 'blocking' model and I'm trying to use it in a
non-blocking manner.

My component pallet has hundreds of icons, components written by
dozens of commercial and freeware authors. My goal is to take
the ideas in my head and turn them into workable, sellable
programs using those components. I have enough problems
figuring out how to accomplish my own coding goals. I don't
have the time to sit down and learn the methodology behind every
single component or set of components on my pallete. Whether
Indy uses a blocking or non-blocking model is inconsequential to
me. Can I learn it quick and can I get it to send and recieve
e-mail? Those were my only questions.

Every Indy example I looked at took me about 15 minutes of
button pushing to create an app exception in one form or
another. I still get 'stack overflow' errors in the IDE when
working with Indy. Furthermore, I have this innate difficulty
with paying for documentation when example programs crash.

As a whole, I still think Indy sucks and ICS is a much better
component suite, if for no other reason, ICS includes examples
of how to use every single component. I think Francois has done
an excellent job over the years. If it had SSL for POP and
SMTP, I'd still be using... nay, paying for it.
Angus Johnson
2006-03-28 23:49:27 UTC
Permalink
Post by twistedvoid
I have enough problems
figuring out how to accomplish my own coding goals. I don't
have the time to sit down and learn the methodology behind every
single component or set of components on my pallete. Whether
Indy uses a blocking or non-blocking model is inconsequential to
me.
Well, you should at least have a reasonable understanding of how your
components work, otherwise you'll continue to have the problems you've just
demonstrated you're having in this thread.

Also, to publically calling these Indy components "a piece of crap" simply
because you've failed to understand how to use them properly does the Indy
authors a great injustice. Having some appreciation of the effort that has
gone into the Indy project for no financial gain, I believe this sort of ill
considered feedback only discourages those who contribute so much to the
Delphi freeware community.

Next time, please don't be so hasty to blame your tools.
Remy Lebeau (TeamB)
2006-03-29 02:47:23 UTC
Permalink
Post by twistedvoid
My component pallet has hundreds of icons, components written
by dozens of commercial and freeware authors. My goal is to take
the ideas in my head and turn them into workable, sellable programs
using those components. I have enough problems figuring out how to
accomplish my own coding goals. I don't have the time to sit down
and learn the methodology behind every single component or set of
components on my pallete.
Then you are wasting what little time you do have, because you don't seem to
have an understanding of which components do what and how. If you knew what
your components actually did, and how, then you wouldn't have to waste your
time trying to figure it out, and you can better decide which component is
best to use for each situation that you run across.
Post by twistedvoid
Whether Indy uses a blocking or non-blocking model is inconsequential
to me.
With that kind of mentality, how do you program at all? That is a
fundamental architectural question that you should be asking yourself every
time you need to tackle a task. Will blocking or non-blocking suit your
needs better? With that decided, only then can you decide which components
meet those requirements.
Post by twistedvoid
Can I learn it quick and can I get it to send and recieve e-mail?
You also have to ask yourself if you want the rest of your code to be
blocked while sending and receiving those emails. If no, then you need to
use an asynchronous model. In which case, you then have to ask yourself
what components can be used asynchronously. ICS and Borland's native socket
componets can. Indy and Synapse can, via additional threading.
Post by twistedvoid
I still get 'stack overflow' errors in the IDE when working with Indy.
Then you probably aren't using it properly. Stack overflows only occur when
recursive calls don't break after xx number of iterations before the stack
fills up with too many values. Indy has few recursive calls in it at all.
So I have to suspect that your own code is causing endless recursion to
occur.
Post by twistedvoid
Furthermore, I have this innate difficulty with paying for documentation
when example programs crash.

Indy's documentation is free. It even has its own website
(http://docs.indyproject.org). The only thing Indy charges is for its eBook
and its Experts consulting.
Post by twistedvoid
As a whole, I still think Indy sucks and ICS is a much better component
suite

Then don't use Indy. Indy is not for everyone. Use what actually suits
your particular needs.


Gambit
tony caduto
2006-03-28 14:01:57 UTC
Permalink
you should switch to synapse. I also used to use Indy but gave up on it
because of the problems.
Now I use Synapse for everything from doing a http put/get to sending a
smtp email to creating a instant messenger app.
--
Tony Caduto
AM Software Design
Home of PG Lightning Admin for Postgresql
http://www.amsoftwaredesign.com
twistedvoid
2006-03-28 21:34:38 UTC
Permalink
Post by tony caduto
you should switch to synapse. I also used to use Indy but gave up on it
because of the problems.
Now I use Synapse for everything from doing a http put/get to sending a
smtp email to creating a instant messenger app.
--
Tony Caduto
AM Software Design
Home of PG Lightning Admin for Postgresql
http://www.amsoftwaredesign.com
Thanks, I will look into it. But, I currently have two internet component suites in my head, Indy and ICS. I'm not sure I have room for another.
John Jacobson
2006-03-28 19:13:26 UTC
Permalink
Post by twistedvoid
I should have just told my customers to stay the hell away from g-mail and
use a less paranoid POP/SMTP server so that I could use a less
screwed up POP/SMTP component set.
Personally I think you should have written your code to be multithreaded, or
should have switched to an event driven framework like ICS. There's nothing
wrong with Indy 10 in this regard, you simply haven't written your code to
fit it's (multithreaded) philosophy. It seems to me that your post is like
someone trying to use a screwdriver as a crowbar and complaining that it is
a terrible crowbar.
twistedvoid
2006-03-28 21:33:04 UTC
Permalink
Post by John Jacobson
Post by twistedvoid
I should have just told my customers to stay the hell away from g-mail and
use a less paranoid POP/SMTP server so that I could use a less
screwed up POP/SMTP component set.
Personally I think you should have written your code to be multithreaded, or
should have switched to an event driven framework like ICS. There's nothing
wrong with Indy 10 in this regard, you simply haven't written your code to
fit it's (multithreaded) philosophy. It seems to me that your post is like
someone trying to use a screwdriver as a crowbar and complaining that it is
a terrible crowbar.
Old programmer axiom: When the only tool you have is a hammer, everything looks like a nail.

My axiom: Everything IS a nail.
Loading...