Re: [Mailman-Developers] SMTPDirect timeout
It should but the MTA we're connecting to is a load balancer, and this is a known issue with our load balancer vendor (the backend goes down but the load balancer doesn't terminate the connection), but this could happen for a variety of other reasons.
I chose to do this rather than SO_KEEPALIVE because the socket interface isn't really exposed through the smtplib module.
Thien
On Fri, 28 Jan 2005 11:01:30 +0100, Brad Knowles <brad@stop.mail-abuse.org> wrote:
At 9:00 PM -0800 2005-01-27, Thien Vu wrote:
The patch I've attached is a simple alarm around the SMTPDirect.py call into smtplib to terminate the connection after a configurable amount of time. Right now I have it set to minutes(10) but it's completely configurable via mm_cfg.py
That's very weird. The MTA should be dropping those connectionsafter five minutes of idle time (I think that's the recommended value). Obviously, in your case the MTA is not doing this, so the client should definitely be protecting itself against being hung indefinitely.
-- Brad Knowles, <brad@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755SAGE member since 1995. See <http://www.sage.org/> for more info.
It seems my attachment didn't make it through the first time. Here's the patch: diff -Naur mailman-2.1.5.orig/Mailman/Defaults.py.in mailman-2.1.5/Mailman/Defaults.py.in --- mailman-2.1.5.orig/Mailman/Defaults.py.in 2004-04-24 19:30:03.000000000 -0700 +++ mailman-2.1.5/Mailman/Defaults.py.in 2005-01-26 13:18:07.000000000 -0800 @@ -348,6 +348,7 @@ # #DELIVERY_MODULE = 'Sendmail' DELIVERY_MODULE = 'SMTPDirect' +SMTP_DELIVERY_TIMEOUT = minutes(10) # MTA should name a module in Mailman/MTA which provides the MTA specific # functionality for creating and removing lists. Some MTAs like Exim can be diff -Naur mailman-2.1.5.orig/Mailman/Handlers/SMTPDirect.py mailman-2.1.5/Mailman/Handlers/SMTPDirect.py --- mailman-2.1.5.orig/Mailman/Handlers/SMTPDirect.py 2004-01-22 15:02:07.000000000 -0800 +++ mailman-2.1.5/Mailman/Handlers/SMTPDirect.py 2005-01-26 13:18:07.000000000 -0800 @@ -67,7 +67,12 @@ if self.__conn is None: self.__connect() try: + def handler (signum, frame): + raise smtplib.SMTPException('SMTP Delivery Timeout exceeded') + signal.signal(signal.SIGALRM, handler) + signal.alarm(mm_cfg.SMTP_DELIVERY_TIMEOUT) results = self.__conn.sendmail(envsender, recips, msgtext) + signal.alarm(0) except smtplib.SMTPException: # For safety, close this connection. The next send attempt will # automatically re-open it. Pass the exception on up. On Fri, 28 Jan 2005 09:18:31 -0800, Thien Vu <thien.vu@gmail.com> wrote:
It should but the MTA we're connecting to is a load balancer, and this is a known issue with our load balancer vendor (the backend goes down but the load balancer doesn't terminate the connection), but this could happen for a variety of other reasons.
I chose to do this rather than SO_KEEPALIVE because the socket interface isn't really exposed through the smtplib module.
Thien
On Fri, 28 Jan 2005 11:01:30 +0100, Brad Knowles <brad@stop.mail-abuse.org> wrote:
At 9:00 PM -0800 2005-01-27, Thien Vu wrote:
The patch I've attached is a simple alarm around the SMTPDirect.py call into smtplib to terminate the connection after a configurable amount of time. Right now I have it set to minutes(10) but it's completely configurable via mm_cfg.py
That's very weird. The MTA should be dropping those connections after five minutes of idle time (I think that's the recommended value). Obviously, in your case the MTA is not doing this, so the client should definitely be protecting itself against being hung indefinitely.
-- Brad Knowles, <brad@stop.mail-abuse.org>
"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755
SAGE member since 1995. See <http://www.sage.org/> for more info.
On Fri, 2005-01-28 at 12:18, Thien Vu wrote:
It should but the MTA we're connecting to is a load balancer, and this is a known issue with our load balancer vendor (the backend goes down but the load balancer doesn't terminate the connection), but this could happen for a variety of other reasons.
I chose to do this rather than SO_KEEPALIVE because the socket interface isn't really exposed through the smtplib module.
I'm not really crazy about adding a sigalarm handler here to fix this problem, especially because it really does appear to be caused by a bug in your smtp server (or load balancer -- but it makes no difference from Mailman's point of view). OTOH, as you say, there's no (public) exposure of the underlying socket object in the SMTP object. Even if there was, in newer Python's you'd have to watch out for SSLFakeSockets which don't expose the real underlying socket.
I'm -0 on this patch.
Aside from that, it's generally a much better idea to use SourceForge for posting patches.
-Barry
On Sat, 29 Jan 2005 17:30:25 -0500, Barry Warsaw <barry@python.org> wrote:
On Fri, 2005-01-28 at 12:18, Thien Vu wrote:
I chose to do this rather than SO_KEEPALIVE because the socket interface isn't really exposed through the smtplib module.
I'm not really crazy about adding a sigalarm handler here to fix this problem, especially because it really does appear to be caused by a bug in your smtp server (or load balancer -- but it makes no difference from Mailman's point of view). OTOH, as you say, there's no (public) exposure of the underlying socket object in the SMTP object. Even if there was, in newer Python's you'd have to watch out for SSLFakeSockets which don't expose the real underlying socket.
I'm -0 on this patch.
I'm not super thrilled about this either, but it's something can potentially cause mailman to fail and may want to be protected against. I suppose generally your SMTPHOST is a host that you control so if it is failing then you may have bigger problems to deal with. The solution seemed to be the least impacting of other systems.
Thien
participants (2)
-
Barry Warsaw -
Thien Vu