close
Comments you submit will be routed for moderation. If you have an account, please log in first.

Changes between Initial Version and Version 1 of Ticket #530, comment 68


Ignore:
Timestamp:
Jun 13, 2014, 9:36:38 AM (6 months ago)
Author:
damato
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #530, comment 68

    initial v1  
    6060
    6161'''So who is to blame?'''
    62 Well, that's pretty clear. The mail server of GMX and web.de (aka Nemesis) is dropping connections way too fast compared to other mail server implementation. While one could argue that only slow systems might be affected by this even faster systems could run into the same problem if (for some reason) the system itself is under higher load (due to parallel computations) and it reaches this 8 seconds limit before it could finalize the SSL_connect(). In addition, right after a `STARTTLS` command being send SSL connections are usually initialized by also loading the SSL certificate chain via `SSL_CTX_load_verify_locations()` which could easily take several seconds depending on how large a certificate chain file is and then starting the SSL negotiations afterwards via SSL_connect(). So in principle any system (even non-amiga systems) could be affected as 8 - 10 seconds are really way to short  due to the native a SSL connection is being setup.
     62Well, that's pretty clear. The mail server of GMX and web.de (aka Nemesis) is dropping connections way too fast compared to other mail server implementation. While one could argue that only slow systems might be affected by this even faster systems could run into the same problem if (for some reason) the system itself is under higher load (due to parallel computations) and it reaches this 8 seconds limit before it could finalize the SSL_connect(). In addition, right after a `STARTTLS` command being send SSL connections are usually initialized by also loading the SSL certificate chain via `SSL_CTX_load_verify_locations()` which could easily take several seconds depending on how large a certificate chain file is and then starting the SSL negotiations afterwards via `SSL_connect()`. So in principle any system (even non-amiga systems) could be affected as 8 - 10 seconds are really way to short  due to the native a SSL connection is being setup.
    6363
    6464'''What to do about it?'''
    65 Well, apart from reporting this shortcoming in the Nemesis mail server software of GMX, web.de and 1und1 there is unfortunatly only little we can do about it. Thore has already stated above that limiting the allowed encryption ciphers by excluding AES might help due to the fact that then SSL_connect() itself will be faster due to less computational time required to initiate the SSL negotiations. This, however, is clearly just a work around since the timeout could in principle also happen if your system is also simply busy with other stuff at the time you try to connect to the mail server easily approaching the 8 seconds limit. Of course, best would be to move away from GMX, web.de or 1und1 since changes are probably pretty low that they will adapt their mail server (its closed source and very proprietary) to the needs of their users. Having understood the root cause of the problem we will also see if we can optimize the way SSL connections are currently initiated in YAM so that there is as less delay as possible between the `STARTTLS`or similar commands and the actual call to `SSL_connect()`. However, please understand that this is also just a workaround for the real problem: GMX, web.de and 1und1 are using too strict timeout values for SSL negotiations.
     65Well, apart from reporting this shortcoming in the Nemesis mail server software of GMX, web.de and 1und1 there is unfortunatly only little we can do about it. Thore has already stated above that limiting the allowed encryption ciphers by excluding AES might help due to the fact that then `SSL_connect()` itself will be faster due to less computational time required to initiate the SSL negotiations. This, however, is clearly just a work around since the timeout could in principle also happen if your system is also simply busy with other stuff at the time you try to connect to the mail server easily approaching the 8 seconds limit. Of course, best would be to move away from GMX, web.de or 1und1 since changes are probably pretty low that they will adapt their mail server (its closed source and very proprietary) to the needs of their users. Having understood the root cause of the problem we will also see if we can optimize the way SSL connections are currently initiated in YAM so that there is as less delay as possible between the `STARTTLS`or similar commands and the actual call to `SSL_connect()`. However, please understand that this is also just a workaround for the real problem: GMX, web.de and 1und1 are using too strict timeout values for SSL negotiations.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Owner, Subscriber

  • Andreas Barth(Subscriber, Participant)
  • chzigotzky@…(Subscriber, Participant)
  • Frank Weber(Subscriber, Participant)
  • Joseph Duchâtelet(Subscriber, Participant)
  • Stellan Pistoor(Reporter, Participant)