You all are giving excellent information in this mailing list, thanks a lot!

I guess my problem is - as you describe - that the component is still active, 
even if smtpQuit has been reached within OnRequestDone. I don't currently check 
if it's still connected, but I will change it. Errors will be checked and force 
to abort the entire mail and write some log entries. 

As Arno said earlier, I'd like to have async components because of their 
benefits. But in fact, for me it is a sync call, at least for each single mail. 
IOW, I've to wait until each particular mail has been finished before I'm 
advancing to the next one. So I'm starting with Connect(), let the 
OnRequestDone do the background stuff and set a flag if either aborted or quit. 
Now I know I've to wait also for not Connected. But what's the correct method 
to wait for completion? Currently, I have a loop after calling Connect() 
looking like this:

while not FlagDone do begin
  //Application.ProcessMessages;  // Don't know whether or not to use the 
message pump here

Any thoughts?


> -----Original Message-----
> Behalf Of DZ-Jay
> Sent: Tuesday, January 16, 2007 10:57 AM
> To: ICS support mailing
> Subject: Re: [twsocket] Still problems while sending SMTP
> On Jan 16, 2007, at 02:49, Arno Garrels wrote:
> > When the response to the Quit command is received the connection
> > (may) still be alive. So watch both, whether Quit response has been
> > received as well as the SessionClose event. Call connect only
> > after the session has been closed.
> > Don't start a loop directly from an event handler but post a custom
> > message to some Window, in it's message handler start the next loop.
> You could, in fact, re-use the connection if the next message 
> is to be 
> sent through the same server.  All you have to do is, after the DATA 
> command is completed and the server acknowledges receipt, check 
> SmtpCli.Connected, if you are still connected then reset your 
> state-machine to start the cycle fromthe MAIL FROM command.  Some 
> servers required a "reset" (RSET) command be sent to reset state, and 
> it doesn't hurt to send it anyway.  The important thing is to 
> check the 
> connection, because something may have happened -- and indeed, some 
> servers have anti-spamming filters that will kick you out after 
> receiving DATA that they determine is spam, and some won't 
> allow you to 
> re-send after one message.  So the algorithm would be something like:
> 1. Connect
> 2. HELO
> 4. RCPT TO
> 5. DATA
> 6. If connected:
>       6.a (yes) RSET then back to 3
> 7. QUIT
> 8. back to 1
> Of course, you should check for errors after each step (in 
> OnRequestDone, before changing states).  Keep in mind that 
> some errors 
> are recoverable (transient: 400+), some errors are not 
> (non-transient: 
> 500+), and some are somewhere in between (like RCPT warnings, etc).  
> Recoverable errors allow you to try again, or require a RSET 
> and start 
> from step 3, while non-transient errors require closing the 
> connection 
> and starting from scratch.  If you are sending general messages to 
> strange servers "in the wild" it gets pretty complicated, specially 
> when you factor in all the non-RFC-compliant servers; but if your 
> application is of limited purpose, sending using the same server all 
> the time, the errors and issues that may occur are predictable and 
> substantially less.
> Building this logic in a simple state-machine using 
> OnRequestDone makes 
> it fairly easy to make your application powerful and efficient -- the 
> reason we always push for the use of async methods.
>       dZ.
> -- 
>       DZ-Jay [TeamICS]
> -- 
> To unsubscribe or change your settings for TWSocket mailing list
> please goto
> Visit our website at
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to