Locked Domains - Mail Passwords will not be set to original

  • I use 1.2.9 on a Debian wheezy Root with some Customers / Customer-Domains.
    Every year the point at the expirience day the customer give feedback, that no mail is possible.
    Then I activate the domain and in the past all went fine, but suddenly the mailpasswords are changed and no user on an expired and new activatet domain can send or receive mails.
    Whats the reason? And is this behavior also in 1.2.11?
    It took about one hour to find the reason, why the mailaccounts on a newly activated domain does not run - only on a look into the database and mailtable I did found the reason.
    Is this a feature or a bug?

  • Do you really think that we can understand you?

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • mhm - let me try to explain:
    If the expiration date of a domain is set in imscp (pic1), then the accessibility of this domain will be deactivatet after this date is reached (loo pic2)
    Then if that deactivatet domain will be activatet and a new expiration date in the future has been set manually (in the date field pic1) the domain is reachable per http and https, but the mailaccounts not.
    Custumers can not acces their mailaccounts as before the deactivation of the domain. Because this occured every time, if a account was deactivatet, searched and found, that every password on every mailaccount of the former deactivatet domain where changed. And they where not changed back to its former value after the manual reactivation of the domain. Thats the reason, because no user can login at his mailaccount nor a client nor with webmail.
    Is this a feature or a bug? - because it is not jokey to search, why mailaccounts dont went well....

    Files

    • pic1.PNG

      (16.41 kB, downloaded 8 times, last: )
    • pic2.PNG

      (21.63 kB, downloaded 10 times, last: )
  • @hempelr


    Ok so the problem is : When a domain (a customer account) is being re-activated, the passwords for mail accounts that belong to that customer are no longer valid. I'll check the behavior and provide a fix in version 1.2.12 if needed.


    Thank you for your report.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • @hempelr


    Problem confirmed. It will be fixed in version 1.2.12. This is due to the fact that when an account is being deactivated by the /var/www/imscp/engine/tools/imscp-disable-accounts script (cron tasks), the mail passwords are prefixed with a random string. The problem is that when we reactivate the account through the FrontEnd, the prefix is not removed... Well, anyway, that prefix is no longer needed because we have now a specific field which allows to deactivate IMAP/POP access.


    Bellow you can find a patch against the v1.2.11 for the /var/www/imscp/engine/tools/imscp-disable-accounts script . Will be part of v1.2.12