Bugzilla

Gene, there 'could' in theory be a need for multiple connections to a 'server' per it's normal definition, but not to the TB definition of a server/service, eg only associated with one outgoing account/server.  (MAIL FROM).  Generally a SESSION can be re-used for multiple transactions but from a client perspective it is rare.  As well, most ISP's or email providers have only a limited number of simultaneous connections, so it is frowned on for one customer/client to use up more than their expected share.  And with most email transactions being SO fast nowadaways, not like the slow dialup days, no real need to 'improve performance' at the session/connection level.  However, an email client can quickly trip up outgoing rate limiters, so I would recommend only doing 'batches' of 25 emails per session, close the session, and open another session for another 25 transactions.  You can even put a wait period between 'batches' if you want. (I personally know of quite a few email servers with sending limits of only 100 MAIL FROM's or even RCPT TO per connection, because of compromised email account spammers.  Make more sense that the explicit description in the RFC's ?  And other systems like Calendars etc, can't generate emails fast enough to warrant keeping SMTP connections open, given how quickly a new connection can be opened on demand.  But there are many different threat tools out there that will expect the email clients behavior to be similar to a human behavior.

Gene, there 'could' in theory be a need for multiple connections to a 'server' per it's normal definition, but not to the TB definition of a server/service, eg only associated with one outgoing account/server.  (MAIL FROM).  

Generally a SESSION can be re-used for multiple transactions but from a client perspective it is rare.  As well, most ISP's or email providers have only a limited number of simultaneous connections, so it is frowned on for one customer/client to use up more than their expected share.  And with most email transactions being SO fast nowadaways, not like the slow dialup days, no real need to 'improve performance' at the session/connection level.  

However, an email client can quickly trip up outgoing rate limiters, so I would recommend only doing 'batches' of 25 emails per session, close the session, and open another session for another 25 transactions.  You can even put a wait period between 'batches' if you want. (I personally know of quite a few email servers with sending limits of only 100 MAIL FROM's or even RCPT TO per connection, because of compromised email account spammers.  

Make more sense that the explicit description in the RFC's ?  

And other systems like Calendars etc, can't generate emails fast enough to warrant keeping SMTP connections open, given how quickly a new connection can be opened on demand.  But there are many different threat tools out there that will expect the email clients behavior to be similar to a human behavior.