A question has arisen about how best to manage SMTP connections when using psSendMail. Here are some tips:
psSendMail does not have any specific time-out for your SMTP connection. But your SMTP server certainly should have a way to time-out idle connections. In fact, you should count on it.
If your program is designed to send email messages in response to certain, randomly timed events, like new database entries, it should take into account that long periods may transpire between such events.
In such a case, your use of psSendMail should be an “in-fast / out-fast” design. That is, when the event occurs, make the connection, send the message, and then close the connection. Don't leave the connection open indefinitely - expecting it to still be open at some undetermined future time. Your SMTP server may well close the connection according to its time-out rules.
If your program is designed to send a bunch of messages based upon a fast loop - say through database records - you can (theoretically) open the connection once, send each message successively, then close the connection.
I say "theoretically" because, even in the latter case, it may be prudent to limit the number of messages sent at once. We do this in the distribution of our E-Magazine. We send out a few, say 20, and then wait a while before sending the next batch.
The reason for this? SMTP servers can be very busy programs. They are not only sending your batches, they are simultaneously contending with messages coming in from other users. At some point, it's conceivable that their queue storage will run out - if they're not allowed some breathing room. Even if you have an entire SMTP server to yourself, you could overrun its queue. SMTP servers have a lot of work to do with each message they process, and psSendMail is FAST - it has no built-in "throttle."
When I say it's fast, I mean that the DLL is highly optimized, native machine code. There isn't an interpreter or script responder in sight. The performance of each call in psSendMail is limited (virtually) only by the time it takes the SMTP server to respond - meaning it's potentially faster than some SMTP servers, themselves.
Finally, consider how spam-paranoid servers may respond to a horde of messages, all originating from the same place in rapid succession. Such an event may be all it takes for the SMTP server to say "Whoa, there! Looks like spam to me. I'm closing that guy's connection."
Speaking of spam, psSendMail's documentation includes several tips for ensuring that your legitimate emails make it past the spam police.
Prestwood IT
Print This
Tags:
