Hi, We have a problem with domain containing local characters ( cvetličarna.com ) - web site - no problem - email domain : domain is created, but cannot create DKIM / DMARC record, error is "Invalid domain or selector", cannot select spamfilter - email mailbox : can create email, but cannot use somemail@cvetličarna.com as username. "This login is not allowed. Please enter a different login or use the mail address as login." Even when use "somemail@abc" as login, this is not allowed. Btw, it is allowed on any other mailbox. Allowed is only username without @ Still using version 3.1.9. Will upgrade have some effect ? Regards
Update ISPConfig and test it again, your version is about 2 years old. I use IDN domains on my servers and have no issues with ISPConfig.
Hi, Finally updated to the last version, but unfortunately this solves only the first issue. DKIM is created, but I still can't use login name with local chars (for example somemail@cvetličarna.com, admin@računovodstvo.net)
Today I updated to the latest version 3.1.15, but username with local chars is still not supported. Is there even a chance this will be supported in the nearest future ?
Username or domain name? Using an email domain name with foreign chars works fine here, I have several of such domains which contain ä or ü on my server. Maybe you missed installing PHP intl extension on your server which is required to convert the domain name to IDN?
Ok, but that's not related to the start topic of this thread. The login field is not meant to add an email address there, it is just for usernames, you receive that error because you added an email address and not because you added a foreign char. Remove the add and you will see that you can save the mailbox settings.
Hi, Unfortunately you are not correct : we are using email as login name for all other clients for very long time and it works just fine. Except when there's "č" in email address...
Of course, you can login by email address as well as that's the default way to authenticate for a mailbox. The login name is an optional additional login which may not contain an email address. And before you tell me that I'm not correct, unlike you, I tested it in 3.1.15 before I posted. Login to your ISPConfig panel, remove the @ from the login field and press save. You will see that you can save it then. And regarding domain names with foreign chars in general, it might be that the mail client that you use is not capable of using IDN domains in logins. A domain is IDN encoded and your mail client must be able to encode the username as well before it sends it as auth name, if it is not capable of doing that, then you must enter the email address in IDN format in your mail client.
Don't get me wrong - I know it works the way you stated, after all you are developer... But the thing is that we have same login principle for quite few years and I really don't want to change it. That's why my issue is still "why I cannot use admin@cvetličarna.com as username ?" Because it works just fine if I use "[email protected]", but then again I cannot tell users anymore "use your email as username". Sorry for complicating...
As a temporary workaround, you might try the following: 1. change /usr/local/ispconfig/interface/web/mail/form/mail_user.tform.php and remove the IDNTOASCII and IDNTOUTF8 filters (ONLY for "login" field). Remember to change the index for TOLOWER to 0 afterwards 2. change /usr/local/ispconfig/interface/web/mail/mail_user_edit.php and in line 259 change Code: elseif(strpos($_POST["login"], '@') !== false && $_POST["login"] != $this->dataRecord["email"]) $app->tform->errorMessage .= $app->tform->lng("error_login_email_txt")."<br>"; to Code: elseif(strpos($_POST["login"], '@') !== false && $app->functions->idn_encode($_POST["login"]) != $this->dataRecord["email"]) $app->tform->errorMessage .= $app->tform->lng("error_login_email_txt")."<br>"; I have not tested this, but it _should_ do the trick for now.
This (almost) did the trick I had to change also regex for field login (quick and dirty, added čšž) 'regex' => '/^[_a-z0-9][\w\č\š\ž\.\-_\+@]{1,63}$/' Everything fine now. Now it is on me to not forget to correct this after update. Thanks for your support.
That change is most likely neccessary due to the removed IDN filters which had removed the special chars previously. We'll see how we can work around such issues in one of the next updates.
One more (hopefully the last one) question : everything working fine until I tried to enable Letsencrypt. in /usr/local/ispconfig/server/letsencrypt.log I found File "/usr/lib/python2.7/dist-packages/letsencrypt/le_util.py", line 308, in enforce_domain_sanity "Punycode domains are not presently supported: {0}".format(domain)) I found a bunch of solutions saying "update certbot", but I cannot find certbot under any suggested name. Any hint is appreciated.
I guess you are missing the php-intl extension on the server and so maybe your domains are stored in the database unencoded.
Or you are using a really old version of certbot. You can get the latest certbot version here: https://certbot.eff.org/
Just to confirm that certbot/letsencrypt was the one to blame. Updated letsencrypt to latest version, now everything working as it should. Thanks.
