SMTP_TIMEOUT Question

[kpassaur]

I am looking for an example using SMTP_TIMEOUT, I cannot find one in the manual or on this forum.

The difficulty I am having is about one out of ten or so uses when I send mail it locks up. I use the Show Status and it will say connected and just hang there and the only way out is to shut down the process. I would like to think it is just me doing something wrong, but it works 90 percent of the time. My though was if SMTP_TIMEOUT allows it to bail out I could put a loop in and try later until it goes through. I have one now for when it fails to connect to the server. But this is connecting, so hopefully this command will allow it to exit.

Any ideas?

[Bob Hansen]

This does not use SMTP_TIMEOUT, but does show an example of using SMTP_RESULT:

Code: Select all

Label>SendEmail
Let>Delay=3
Let>MaxAttempts=5
Let>MailTry=%MailTry%+1

SMTPSendMail>%recipients%,%Server%,%FromAddress%,%FromName%,%EmailSubject%,%EmailBody%,
Wait>%Delay%
MidStr>%SMTP_RESULT%,1,3,EmailTest

If>%EmailTest%=250,GoodEmail,BadEmail

Label>BadEmail
MessageModal>%SMTP_RESULT% after %MailTry% attempts.
Wait>10
If>%MailTry%<%MaxAttempts%,SendEmail,End

Label>GoodEmail
Message>Mail for %recipients% has been sent
Wait>2

Label>End

No access to Macro Scheduler right now, but try this:
Add this line at the top:
Let_SMTP_TIMEOUT=10000
You can then step through and see what happens to SMTP_RESULT. You will probably get a specific code, different from "250" that indicates connection did not happen with the 10 seconds. As shown in this example you can then loop a number of times to try to reconnect.

You could also write %SMTP_RESULT% to a separate log file with some other information, date/time/recipient/subject, etc. to track the SMTP activities.

[kpassaur]

Thanks Bob that is similar to what I am doing now; however I don't get the result it just hangs up.

Any other ideas? It is connecting (it says it is in the Show Status Window) but just hanging there locked up.

I was hopeing the SMTP_TIMEOUT would cause it to disconnect if it was connected and not doing anything and then return the result code so I could process it.

[Bob Hansen]

When I have MS access again, I will try later tonight if you do not have an answer before then

[Bob Hansen]

Hello Keith

I jsut found this on a forum for Smart Email:

SMTP connection timeout occurs when the SMTP server does not respond within the default 30 seconds. You can increase the timeout setting to 60 seconds, which usually is long enough to wait for a response even if your internet connection is slow.

If the timeout is occurring for a group of e-mails within a domain then the SMTP server for that domain may be blocking SMTP verification. Thus you cannot ascertain the validity of such e-mails.

The Macro Scheduler SMTP_TIMEOUT is in milliseconds, so I guess you could increase to some value higher than the default of 30000 if you think timing out too soon is the problem.

And here is a much more detailed excerpt from: http://www.freesoft.org/CIE/RFC/1123/109.htm

5.3.2 Timeouts in SMTP

There are two approaches to timeouts in the sender-SMTP: (a) limit the time for each SMTP command separately, or (b) limit the time for the entire SMTP dialogue for a single mail message. A sender-SMTP SHOULD use option (a), per-command timeouts. Timeouts SHOULD be easily reconfigurable, preferably without recompiling the SMTP code.

DISCUSSION:

Timeouts are an essential feature of an SMTP implementation. If the timeouts are too long (or worse, there are no timeouts), Internet communication failures or software bugs in receiver-SMTP programs can tie up SMTP processes indefinitely. If the timeouts are too short, resources will be wasted with attempts that time out part way through message delivery.

If option (b) is used, the timeout has to be very large, e.g., an hour, to allow time to expand very large mailing lists. The timeout may also need to increase linearly with the size of the message, to account for the time to transmit a very large message. A large fixed timeout leads to two problems: a failure can still tie up the sender for a very long time, and very large messages may still spuriously time out (which is a wasteful failure!).

Using the recommended option (a), a timer is set for each SMTP command and for each buffer of the data transfer. The latter means that the overall timeout is inherently proportional to the size of the message.

Based on extensive experience with busy mail-relay hosts, the minimum per-command timeout values SHOULD be as follows:

* Initial 220 Message: 5 minutes

A Sender-SMTP process needs to distinguish between a failed TCP connection and a delay in receiving the initial 220 greeting message. Many receiver-SMTPs will accept a TCP connection but delay delivery of the 220 message until their system load will permit more mail to be processed.

* MAIL Command: 5 minutes

* RCPT Command: 5 minutes

A longer timeout would be required if processing of mailing lists and aliases were not deferred until after the message was accepted.

* DATA Initiation: 2 minutes

This is while awaiting the "354 Start Input" reply to a DATA command.

* Data Block: 3 minutes

This is while awaiting the completion of each TCP SEND call transmitting a chunk of data.

* DATA Termination: 10 minutes.

This is while awaiting the "250 OK" reply. When the receiver gets the final period terminating the message data, it typically performs processing to deliver the message to a user mailbox. A spurious timeout at this point would be very wasteful, since the message has been successfully sent.

A receiver-SMTP SHOULD have a timeout of at least 5 minutes while it is awaiting the next command from the sender.