Search  Rules  Login
TheBat English » The Bat! - Configuring the E-mail Client
Pages: 1
RSS
[B]WARNING[/B] Expensive bug in The Bat!
 
#1
0  
I've just found a bug in The Bat! which can cost you money.

If you send a large email (mine had a 8 MB attachment) and the message takes longer than the "server timeout" to transmit, you get an error message, but the email is sent OK. But because The Bat! thinks there was an error, it is sent again. And again. And again. Until you stop it manually.

I was unaware of this, and sent it 9 times before I'd realised what was happening. And am being charged for excessive use by my ISP. :cry:

This is an obvious bug - the timer should be reset every time a packet is sent, not just at the beginning of the transmission. But Ritlabs don't seem to understand this.

There's an obvious workaround - increase the server timeout. Before you send a long message.
Edited: Peter Toye - 11 October 2009 14:48:18
Peter
 
 
 
#2
0  
This is standard for every email client I have ever used. If the SMTP server does not acknowledge successful receipt of a message, the RFC actually states that the message has to be resent.

Sorry. It may not seem the right thing, but I assure you, it's not a bug.
iviarck
 
 
 
#3
0  
I would say it's a serious bug.
Very serious, because it may not only be expensive, but have other undesired effects as well - by resending a large mail many times you may cause the disk space quota of the recipient to be exceeded and subsequent messages lost, may get you blacklisted etc.

It's OK to resend if there is no acknowledgment of receipt.
But it's not normal to expect the server to acknowledge successful receipt while the message is still being transmitted, as there is no way this to happen.
Edited: bigg one - 12 October 2009 07:50:04
 
 
 
#4
0  
Okay - here's the thing. That's not what I think is happening. The server fails to respond in the specified timeout period, most likely because the data is still in a buffer somewhere waiting to be processed. I have sent many a large email using TB and it will always wait for a server response until the timeout expiry before assuming that none is coming and queueing a resend. Do you have a log snippet that shows otherwise?

This is something TB has done right since before V1, which is how long I have used it.

If you are 100% adamant you have uncovered a new bug in the code, I recommend that you join TBBETA and assist in the testing of new versions there. Plenty of technically savvy folks there will be able to assist in testing this feature - it's not so easy for me now since I am connected to my SMTP server via LAN and all responses are next to instant.

See the TBUDLInfo page for information about how to sign up for TBBETA
iviarck
 
 
 
#5
0  
What do you mean by "respond in the specified timeout"? A TCP ACK? Or a 250 (or similar) SMTP-level response.
Because for a large message there won't be a 250 until the message has finished. And as the messages were forwarded by the server I can only assume that it responded with a 250.

And if there's an error at the receiver end it should (as I read RFC 2821) still wait for transmission to finish with the CRLF.CRLF sequence until giving a suitable error.

I'd like to try this out with a trace, but I can't afford it. I've already spent far too much money on the continual retransmissions which TB! said had errored but which hadn't. :cry:
Peter
 
 
 
Pages: 1