I created a Client, then a Site (testsite.com), then a couple of users under that Site. I tried logging in to https://myispconfig:81/mailuser. Failed with [email protected] (postfix virtusertable), but succeeded with web3_myuser (system account). Why's that? A quick check shows that ISPConfig reads the isp_isp_user table, probably completely ignoring the postfix virtusertable it wrote during user creation. Also, IMAP doesn't work (from SquirrelMail). How does Courier-IMAP tie to Postfix's authentication?
Because you must use the username of the user to whom the email address belongs. In your case it's web3_myuser. Yes, ISPConfig does not read from /etc/postfix/virtusertable. Please post the output of Code: netstat -tap
Erm, I asked "Why's that?" Quick explanation for that strategy? Then why does ISPConfig create that virtusertable file? How does ISPConfig use that, or does it use that? See attached netstat.out.gz
Because ISPConfig creates system users, not virtual users. System users have names like web3_myuser. Postfix uses /etc/postfix/virtusertable, that's why ISPConfig creates it. Can you post the output in plain text here? That makes it easier for us.
But we can't expect mail users to login as web3_myuser, can we? That's odd. Users want to log in as "[email protected]" instead. How does Postfix use it? PAM authentication perhaps? So why doesn't ISPConfig use it as well? A simple extrapolation from "helping Postfix do its job" to "actually integrating with Postfix". The netstat output you requested: Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 localhost:32770 *:* LISTEN 6872/hpiod tcp 0 0 localhost:32771 *:* LISTEN 6882/python tcp 0 0 localhost:mysql *:* LISTEN 7065/mysqld tcp 0 0 *:netbios-ssn *:* LISTEN 7297/smbd tcp 0 0 *:81 *:* LISTEN 7447/ispconfig_http tcp 0 0 *:ftp *:* LISTEN 7638/proftpd: (acce tcp 0 0 webmail.testsite:domain *:* LISTEN 7623/named tcp 0 0 localhost:domain *:* LISTEN 7623/named tcp 0 0 localhost:ipp *:* LISTEN 6838/cupsd tcp 0 0 localhost:953 *:* LISTEN 7623/named tcp 0 0 *:smtp *:* LISTEN 7583/master tcp 0 0 *:microsoft-ds *:* LISTEN 7297/smbd tcp 0 0 localhost:32770 localhost:48040 ESTABLISHED6872/hpiod tcp 0 0 localhost:ipp localhost:38970 ESTABLISHED6838/cupsd tcp 0 0 localhost:48040 localhost:32770 ESTABLISHED6882/python tcp 0 0 localhost:38970 localhost:ipp ESTABLISHED7795/gnome-cups-ico tcp6 0 0 *:imaps *:* LISTEN 6966/couriertcpd tcp6 0 0 *op3s *:* LISTEN 7007/couriertcpd tcp6 0 0 *op3 *:* LISTEN 6984/couriertcpd tcp6 0 0 *:imap2 *:* LISTEN 6943/couriertcpd tcp6 0 0 *:www *:* LISTEN 7484/apache2 tcp6 0 0 ip6-localhost:953 *:* LISTEN 7623/named tcp6 0 0 *:https *:* LISTEN 7484/apache2
Postfix simply reads /etc/postfix/virtusertable (i.e. /etc/postfix/virtusertable.db); it doesn't have to authenticate to read its own files. ISPConfig stores everything in its MySQL database, and ISPConfig's backend then reads from the database and writes everything into the appropriate configuration file.
I see. So Postfix reads the virtusertable to know that an incoming email with "To:" header "[email protected]" should go to inbox of system user say "web3_myuser". Right? Postfix doesn't do any authentication at all? So what does? Courier's POP? Actually, that's part of a problem. ISPConfig stores mailuser info in its backend, but is mostly (always?) oblivous to actual system files that actually denote the system users. In short, ISPConfig replicates much of the system files' info redundantly. This makes it difficult for a system with ISPConfig to work with 'root' user admin work. A typical advice I would issue for ISPConfig users is "try to do everything with ISPConfig (even if some things are not yet possible with it), and don't do any root admin work like adding users manually". A simple analogy. Say I'm a middleman (like ISPConfig) that deals with delivering your letters to addresses. I keep my own database of recipients (with physical addresses). And then there is the government's DEFINITIVE address book that everyone can look up. Still, I use my own database. Therefore, whenever a recipient changes address, and the government address book is modified, my database gets stale. There is no contract between government and me to synchronize our disparate databases, though I do update the government's database whenever I meet a new recipient who just bought a new address through (my other business). Therefore, the only way we can assure agreement between the disparate database is if ALL citizens buy new addresses through me. Same case with ISPConfig, users are advised to create new users (mailusers and system users) through ISPConfig. But that's another discussion altogether. How's my netstat output?
If you're sending from outside (i.e. not from localhost), authentication is done through saslauthd. If you fetch emails (that's different from sending!) than you have to authenticate against your POP3/IMAP daemon. When you open /etc/postfix/virtusertable, you'll see this line at the bottom: Code: #### MAKE MANUAL ENTRIES BELOW THIS LINE! #### You can add your own entries below that line, they won't be overwritten! I guess this solves the problem you have? ISPConfig cannot simply write directly to all configuration files due to permissions. The frontend runs as user admispconfig, not as root. If it ran as root, it would be a security problem... It's ok. Did you enable Maildir in ISPConfig (Management -> Server -> Settings -> Email)?
Seems IMAP works (SquirrelMail) but email login ID not usable Yes, it does allow 'root' user to do manual (and quick) creations of mail users. But wouldn't I also need to tell ISPConfig's backend about it as well? That's my problem, what I do as 'root', ISPConfig ignores and goes back to its own not-so-updated records. True. But the virtusertable was written by 'root' (chmod 644). Perhaps ISPConfig runs a world-executable script to write into virtusertable? I appreciate your effort to make ISPConfig secure. A very important aspect to me. Yes I did enable the Maildir in "Management -> Server -> Settings -> Email". Hmm. It seems that I can login with "web3_myuser", but not "[email protected]". Is this a problem with ISPConfig or with Postfix? The virtusertable file contains the mapping from "[email protected]" to "web3_myuser".
ISPConfig runs a daemon script for the tasks that has to be done as root user. This is independant from the web interface.
As I said ISPConfig reads from its MySQL database so it can't know about your changes. Where do you log in? Which application?
SquirrelMail. Can you confirm that SquirrelMail or Thunderbird or any other mail client WILL NOT be allowed to login as "[email protected]" instead of (or in addtion to) "web3_myuser"? That is, the way ISPConfig manages Postfix and Courier-IMAP, mail users will be forced to login with a system account rather than an email address. I need to make a decision and proceed with some server installation tasks. Thanks!
It s not a question if a program will be alowed to use the email address as username or not. The username is not the email address and @ signs are not allowed in linux systemuser names. For authentication you will have to use the username and password.
ISPConfig creates system users like web1_user1, therefore you must use these usernames in any email application. The only exception is the webmail package from ispconfig.org where you can use the emaiul address, because the email address is then looked up in the ISPConfig database and mapped to the real username.
Till: Actually, it is. A control panel (like ISPConfig) may use a Courier-like virtual mailuser system (userdb.dat format). I am using such a control panel right now (Zervex DSM). In such a case, this control panel works with virtual mailusers, and will allow logins of "[email protected]" rather than (or even IN ADDITION TO) "myuser" (still not a system account, just that default Courier domain is set to "@mydomain.com"). Any intention to support Courier's userdb.dat format for virtual mailusers? ISPConfig is already using Courier-IMAP. No reason it shouldn't support Courier's userdb.dat as well? Falko: Alright. Which means a single machine cannot support more than one email domain. Ie, we can't have "[email protected]" and "[email protected]" on the same machine, since both accounts would want to use system user "myuser". (More on prefix "web1_" below). About the prefix "web1_", can I remove that? Is there a setting in ISPConfig to do this? Falko: You mean UebiMiau Webmail? Falko: Seems a strange "workaround". Courier's userdb (authlib?) is already on the system that comes installed with ISPConfig. That should be where ISPConfig gets its virtual mailuser functionality. By "twisting the arm" of the webmail client to support ISPConfig's very own database structure for virtual mailusers, you're making UebiMiau Webmail work ONLY with ISPConfig. There are possibly hundreds of email clients out there. Seems a very inefficient strategy to get all of them to support ISPConfig's form of "virtual mailusers", when ISPConfig's core Courier already supports virtual mailusers inherently.
In ISPConfig 3. Thats completely wrong. The email address is independant from the username. You can have as many [email protected] in ISPConfig as you have domains. Yes. Management > server > settings on the options tab. 1) You have forgotten that we support a bit more programs then just courier and courier does not come installed with ISPConfig. 2) Every mailclient works fine with ISPConfig. I'am using for example squirrelmail. UebiMiau is the defualt mailclient, bcause it is one of the few clients that work with pop3 as well as with imap and some ISP's wont provide Imap for their customers.
You can remove it, but you should have a look here to learn why it's not a good idea: http://www.howtoforge.com/forums/showthread.php?t=2677
Falko: I read 5 minutes into that thread, but didn't completely understand how it relates to my case. But I'm guessing you're saying I will potentially encounter problems if I have 2 mailusers "[email protected]" and "[email protected]", and both are using the same system account "myuser". Am I right? But then, ISPConfig wouldn't allow me to create 2 accounts with the same system account in the 1st place, so this problem is "checked and prevented". Till: Oh, so the rumors are true. I'm sticking with ISPConfig then. Till: First, consider that the average mailuser would want a login ID of either "[email protected]" or simply "myuser". Courier's userdb format allows this, with the 2nd case possible when you set a default email domain of "@mydomain.com" so that Courier appends that to any login ID missing the "@" sign. Next, consider telling a new mailuser that he has to log in with "web1_andy" instead of "[email protected]" or simply "andy". He asks "why"? Then you say "because someone else has taken "[email protected]". Now, consider the fact that many of us would want to install multiple email domains (at least multiple domains, usually) on a single machine. Why? Cost-effective. With multiple domains "mydomain1.com" to "mydomain100.com", we'd get a high chance of "namespace collision". There could be many "andy"s around. As Falko had pointed out, removing the prefix "web1_" from the system account login ID is not a good idea. The limitation is obvious. Fortunately, I serve a group of people who are willing to bend over backwards for this limitation; they also don't have "namespace collision"... yet. Also, given that you support virtual users (Courier userdb format?) in ISPConfig 3, I'm more than willing to stay with ISPConfig til then. Till: Actually, it's Management > System Config > Settings on the "ISP Manager" tab. Thanks. Till: I know what you're going through as an opensource team. This thread is really more for the benefit of my boss. I'm working on a "somewhat opensource basis" too. We don't always get to hire the best help available. And I often end up overworking on all spectrums of the tasks at hand. Till: Which works with IMAP, me too. The only problem is, I have multiple email domains on one machine. See above for explanation. Till: True that some ISPs won't provide IMAP. I'll definitely keep UebiMiau in mind. Thanks.
