[EMAIL PROTECTED] - [Freitag, 30. Januar 2004, 18:24:10]: >> I should add that I found out that said error doesn't occur with >> "very short" messages, i.e. when I just put a few words into Subject >> and Body. > Do you notice any special characters in the emails, like a . appearing > on it's own line?
No, regular text. You're thinking of the email providing an EOF or something like that? > Do you know if it happens past a certain number of > lines? It does happen after about 1024 bytes, 1019 bytes pass, anything above that fails. The number of lines do not seem to be an issue. > Have you tried testing from another client to see if the same > behaviour is exhibited? I have tested it with OE. Worked perfectly. I also have tried stunnel now. When I do a telnet through stunnel I can send messages of any size without problems. When I use TheBat through stunnel, 1024 is the limit again. To put it in a nutshell, anything from TheBat to port 465 over SSL must not be larger than about 1024 bytes to be transmitted. I also tried to simulate what was happening through the Bat. I thought that maybe TheBat just failed to transmit the EOF (.), so I logged on to the server waiting for a timeout, which didn't occur (at least not as fast as it does when using TB). I then simply closed the connection hoping that the server would still transmit the message (assuming the Bat would simply cut the connection). But the message didn't get sent. So where we get stuck here is past the EOF and for some reason TB assumes the message couldn't be sent while it did get transmitted. Anybody know what TB needs to assume a message has been transmitted successfully? One can also look at this from a different point of view, but I have avoided this as I don't know enough about it. ;) I had exactly the same problem a while ago with regular SMTP while being connected to the net through a software router (Winroute). Setting the MTU to 1300 fixed the problem, somebody just recommended this to me and I never pondered why the MTU wasn't supposed to be larger. But this is happening on a direct connection now. Nothing in between. Still, it might point to the underlying reason for the problem. However, that's yet out of my league. As I have come to understand it, some routers will simply drop packets that are above a certain limit. Now if I lower the MTU, the packets do not exceed the allowed size and do pass. But packets are packets, whether they are encrypted or not, idependent of the port they're transmitted over. So I really don't see how the MTU problem and the SMTPS issue could be other than that they bring up the exact same error message. I'm somewhat confused. Thanks for following my train of thought. ;) Cheers, Oliver -- PGP welcome. Click [ http://www.oliverwolfram.de/pgp.txt ] for my public key. 같같같같같같 Fingerprint: 0294 8249 8EE6 D4C0 DFB2 F3A2 ED5F AD45 C90B 6C05 ________________________________________________________ Current beta is 2.03 Beta/47 | "Using TBBETA" information: http://www.silverstones.com/thebat/TBUDLInfo.html IMPORTANT: To register as a Beta tester, use this link first - http://www.ritlabs.com/en/partners/testers/
