In[A HRef=http://www.Virtualmin.com/bug-tracker/bug?bug%5fnumber=371">Bug #371</A>, it is reported that Virtualmin ignores system-wide aliases such as "info".
My question is, how does this present a delivery problem? Any aliases created in Virtualmin, such as "info@example.com" will over-ride the system-wide alias for that domain. So, I don't see the issue here. Further, I would argue against removing these system-wide aliases, since they still serve a purpose.
A better example might be the "postmaster" or "webmaster" system-wide alias, or even "root". Each domain can have their own "postmaster@example.com" going to that domain owner, but the system should still have its own system-wide alias for system-specific (non-virtual-domain) issues.
Hey Alan,
Yeah, that's what I thought too.
But, note that I'm not talking about aliases in the domains...I'm talking about an actual email account, which apparently does not override the system aliases (because on a customer system I spent a good ten minutes scratching my head and thinking, "No .forward, no user .procmailrc, why the heck is mail being forwarded to the administrator of the server?").
I agree that system-wide aliases shouldn't go away. We just want email addresses that users create within their domains to actually work. I was just brainstorming a bit on how to solve the issue in my comment about removing system-wide aliases during installation (note that all new domains get the RFC recommended aliases setup automatically--but "info" is not one of them, as far as I know, it's just some random crud that's in the aliases file by default).
I need to spend some more time with this issue, but at first glance, it really looks like we need to address it (no pun intended)--I don't think there is a way to make real accounts over-ride aliases, and even if there were, I don't know that we'd like to deal with the consequences.
--
Check out the forum guidelines!
Hey Alan,
Yeah, that's what I thought too.
But, note that I'm not talking about aliases in the domains...I'm talking about an actual email account, which apparently does not override the system aliases (because on a customer system I spent a good ten minutes scratching my head and thinking, "No .forward, no user .procmailrc, why the heck is mail being forwarded to the administrator of the server?").
I agree that system-wide aliases shouldn't go away. We just want email addresses that users create within their domains to actually work. I was just brainstorming a bit on how to solve the issue in my comment about removing system-wide aliases during installation (note that all new domains get the RFC recommended aliases setup automatically--but "info" is not one of them, as far as I know, it's just some random crud that's in the aliases file by default).
I need to spend some more time with this issue, but at first glance, it really looks like we need to address it (no pun intended)--I don't think there is a way to make real accounts over-ride aliases, and even if there were, I don't know that we'd like to deal with the consequences.
--
Check out the forum guidelines!
Maybe I still don't understand the problem, so hopefully an example will help.
If I create a regular user e-mail account called info in one of my domains, Virtualmin automatically adds that e-mail address to the postfix virtual table, i.e.:
info@example.com info.example.com
Actually, this happens exactly the same way, regardless if the info address is a real user or just an alias. In either case, this overrides the system-wide "info" alias, which is defined separately in the /etc/aliases file, not in /etc/postfix/virtual, so there is no problem here at all.
I think I just figured out what you're referring to though. The reason this is not a problem for me is because I have Virtualmin configured to always append the full domain name to my accounts, specifically to avoid conflicts like this. If the system you're referring to isn't doing that, then I suppose you can wind up with a mapping like this:
info@example.com info
... which, in fact, would result in the problem you described. However, I would argue that the real problem is that Virtualmin shouldn't be creating unqualified accounts like "info" into a system-wide shared namespace. My solution would be to either append the domain name (as I am already doing on my systems) or to have Virtualmin report an error, such as "The username info is already in use on this system, please select another username."
How does Virtualmin currently deal with this problem for existing real user accounts, i.e. if the username "joe" already exists on the system and you attempt to create another username "joe" in Virtualmin? I would expect it to deal with your alias example in the same way.
Hey Alan,
Yeah, that's what I thought too.
But, note that I'm not talking about aliases in the domains...I'm talking about an actual email account, which apparently does not override the system aliases (because on a customer system I spent a good ten minutes scratching my head and thinking, "No .forward, no user .procmailrc, why the heck is mail being forwarded to the administrator of the server?").
I agree that system-wide aliases shouldn't go away. We just want email addresses that users create within their domains to actually work. I was just brainstorming a bit on how to solve the issue in my comment about removing system-wide aliases during installation (note that all new domains get the RFC recommended aliases setup automatically--but "info" is not one of them, as far as I know, it's just some random crud that's in the aliases file by default).
I need to spend some more time with this issue, but at first glance, it really looks like we need to address it (no pun intended)--I don't think there is a way to make real accounts over-ride aliases, and even if there were, I don't know that we'd like to deal with the consequences.
--
Check out the forum guidelines!
Maybe I still don't understand the problem, so hopefully an example will help.
If I create a regular user e-mail account called info in one of my domains, Virtualmin automatically adds that e-mail address to the postfix virtual table, i.e.:
info@example.com info.example.com
Actually, this happens exactly the same way, regardless if the info address is a real user or just an alias. In either case, this overrides the system-wide "info" alias, which is defined separately in the /etc/aliases file, not in /etc/postfix/virtual, so there is no problem here at all.
I think I just figured out what you're referring to though. The reason this is not a problem for me is because I have Virtualmin configured to always append the full domain name to my accounts, specifically to avoid conflicts like this. If the system you're referring to isn't doing that, then I suppose you can wind up with a mapping like this:
info@example.com info
... which, in fact, would result in the problem you described. However, I would argue that the real problem is that Virtualmin shouldn't be creating unqualified accounts like "info" into a system-wide shared namespace. My solution would be to either append the domain name (as I am already doing on my systems) or to have Virtualmin report an error, such as "The username info is already in use on this system, please select another username."
How does Virtualmin currently deal with this problem for existing real user accounts, i.e. if the username "joe" already exists on the system and you attempt to create another username "joe" in Virtualmin? I would expect it to deal with your alias example in the same way.
Hey Alan,
You've pretty much summed up the thought process that went into my error report...and the eventual solution will probably match what you're suggesting. ;-)
In short, username->username conflicts are prevented by Virtualmin but username->alias conflicts are not, and they should be in some way. (Your configuration of appending the domain suffix does solve the problem in a very clean way...but not everyone wants to go that route--I prefer it for consistency...but I'm not the only one we have to please!)
--
Check out the forum guidelines!
Hey Alan,
Yeah, that's what I thought too.
But, note that I'm not talking about aliases in the domains...I'm talking about an actual email account, which apparently does not override the system aliases (because on a customer system I spent a good ten minutes scratching my head and thinking, "No .forward, no user .procmailrc, why the heck is mail being forwarded to the administrator of the server?").
I agree that system-wide aliases shouldn't go away. We just want email addresses that users create within their domains to actually work. I was just brainstorming a bit on how to solve the issue in my comment about removing system-wide aliases during installation (note that all new domains get the RFC recommended aliases setup automatically--but "info" is not one of them, as far as I know, it's just some random crud that's in the aliases file by default).
I need to spend some more time with this issue, but at first glance, it really looks like we need to address it (no pun intended)--I don't think there is a way to make real accounts over-ride aliases, and even if there were, I don't know that we'd like to deal with the consequences.
--
Check out the forum guidelines!
Maybe I still don't understand the problem, so hopefully an example will help.
If I create a regular user e-mail account called info in one of my domains, Virtualmin automatically adds that e-mail address to the postfix virtual table, i.e.:
info@example.com info.example.com
Actually, this happens exactly the same way, regardless if the info address is a real user or just an alias. In either case, this overrides the system-wide "info" alias, which is defined separately in the /etc/aliases file, not in /etc/postfix/virtual, so there is no problem here at all.
I think I just figured out what you're referring to though. The reason this is not a problem for me is because I have Virtualmin configured to always append the full domain name to my accounts, specifically to avoid conflicts like this. If the system you're referring to isn't doing that, then I suppose you can wind up with a mapping like this:
info@example.com info
... which, in fact, would result in the problem you described. However, I would argue that the real problem is that Virtualmin shouldn't be creating unqualified accounts like "info" into a system-wide shared namespace. My solution would be to either append the domain name (as I am already doing on my systems) or to have Virtualmin report an error, such as "The username info is already in use on this system, please select another username."
How does Virtualmin currently deal with this problem for existing real user accounts, i.e. if the username "joe" already exists on the system and you attempt to create another username "joe" in Virtualmin? I would expect it to deal with your alias example in the same way.
Hey Alan,
You've pretty much summed up the thought process that went into my error report...and the eventual solution will probably match what you're suggesting. ;-)
In short, username->username conflicts are prevented by Virtualmin but username->alias conflicts are not, and they should be in some way. (Your configuration of appending the domain suffix does solve the problem in a very clean way...but not everyone wants to go that route--I prefer it for consistency...but I'm not the only one we have to please!)
--
Check out the forum guidelines!
Okay, then thanks for bearing with me while I figured out what you were talkinging about! :-)
I understand that everyone likes to have configuration options to fit their needs, as I am the same way. However, I can't imagine supporting a virtual hosting system where all of the domains are sharing a single namespace by default. That just doesn't seem very scalable or easy to manage, unless maybe there are a very limited number of domains on the server or they are all for the same client.
Part of the reason I responded to your error report in the first place is because I have been experiencing a problem on one of my Virtualmin GPL installations where occasionally my system-wide postmaster alias will simply disappear from the /etc/aliases file! I have not figured out yet what is causing this problem, whether it is due to Webmin/Virtualmin updates or something else. So it occurred to me when I saw your error report that I'd prefer for Virtualmin to not change existing system-wide aliases unless absolutely necessary.
Hey Alan,
Yeah, that's what I thought too.
But, note that I'm not talking about aliases in the domains...I'm talking about an actual email account, which apparently does not override the system aliases (because on a customer system I spent a good ten minutes scratching my head and thinking, "No .forward, no user .procmailrc, why the heck is mail being forwarded to the administrator of the server?").
I agree that system-wide aliases shouldn't go away. We just want email addresses that users create within their domains to actually work. I was just brainstorming a bit on how to solve the issue in my comment about removing system-wide aliases during installation (note that all new domains get the RFC recommended aliases setup automatically--but "info" is not one of them, as far as I know, it's just some random crud that's in the aliases file by default).
I need to spend some more time with this issue, but at first glance, it really looks like we need to address it (no pun intended)--I don't think there is a way to make real accounts over-ride aliases, and even if there were, I don't know that we'd like to deal with the consequences.
--
Check out the forum guidelines!
Maybe I still don't understand the problem, so hopefully an example will help.
If I create a regular user e-mail account called info in one of my domains, Virtualmin automatically adds that e-mail address to the postfix virtual table, i.e.:
info@example.com info.example.com
Actually, this happens exactly the same way, regardless if the info address is a real user or just an alias. In either case, this overrides the system-wide "info" alias, which is defined separately in the /etc/aliases file, not in /etc/postfix/virtual, so there is no problem here at all.
I think I just figured out what you're referring to though. The reason this is not a problem for me is because I have Virtualmin configured to always append the full domain name to my accounts, specifically to avoid conflicts like this. If the system you're referring to isn't doing that, then I suppose you can wind up with a mapping like this:
info@example.com info
... which, in fact, would result in the problem you described. However, I would argue that the real problem is that Virtualmin shouldn't be creating unqualified accounts like "info" into a system-wide shared namespace. My solution would be to either append the domain name (as I am already doing on my systems) or to have Virtualmin report an error, such as "The username info is already in use on this system, please select another username."
How does Virtualmin currently deal with this problem for existing real user accounts, i.e. if the username "joe" already exists on the system and you attempt to create another username "joe" in Virtualmin? I would expect it to deal with your alias example in the same way.
Hey Alan,
You've pretty much summed up the thought process that went into my error report...and the eventual solution will probably match what you're suggesting. ;-)
In short, username->username conflicts are prevented by Virtualmin but username->alias conflicts are not, and they should be in some way. (Your configuration of appending the domain suffix does solve the problem in a very clean way...but not everyone wants to go that route--I prefer it for consistency...but I'm not the only one we have to please!)
--
Check out the forum guidelines!
Okay, then thanks for bearing with me while I figured out what you were talkinging about! :-)
I understand that everyone likes to have configuration options to fit their needs, as I am the same way. However, I can't imagine supporting a virtual hosting system where all of the domains are sharing a single namespace by default. That just doesn't seem very scalable or easy to manage, unless maybe there are a very limited number of domains on the server or they are all for the same client.
Part of the reason I responded to your error report in the first place is because I have been experiencing a problem on one of my Virtualmin GPL installations where occasionally my system-wide postmaster alias will simply disappear from the /etc/aliases file! I have not figured out yet what is causing this problem, whether it is due to Webmin/Virtualmin updates or something else. So it occurred to me when I saw your error report that I'd prefer for Virtualmin to not change existing system-wide aliases unless absolutely necessary.
Hey Alan,
If it is Virtualmin or Webmin that's eating your aliases, then it's a bug. At this point it's not supposed to happen. And if I were to modify system-wide aliases, it would happen during installation and only happen once and with some notification (that's just too serious a change to be sneaky about). As I mentioned, I don't think that's the right direction to go from where I'm sitting right now...but you never know what might come up in the future.
--
Check out the forum guidelines!