Re: Bug #371: Virtualmin doesn't notice when an existing alias will prevent delivery

16 posts / 0 new
Last post
#1 Wed, 04/26/2006 - 07:36
ADobkin

Re: Bug #371: Virtualmin doesn't notice when an existing alias will prevent delivery

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.

Sun, 06/07/2009 - 06:59
Joe
Joe's picture

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, &quot;No .forward, no user .procmailrc, why the heck is mail being forwarded to the administrator of the server?&quot;).

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 &quot;info&quot; 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!

Sun, 06/07/2009 - 06:59
Joe
Joe's picture

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, &quot;No .forward, no user .procmailrc, why the heck is mail being forwarded to the administrator of the server?&quot;).

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 &quot;info&quot; 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!

Sun, 06/07/2009 - 06:59
ADobkin

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 &quot;info&quot; 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 &quot;info&quot; 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 &quot;The username info is already in use on this system, please select another username.&quot;

How does Virtualmin currently deal with this problem for existing real user accounts, i.e. if the username &quot;joe&quot; already exists on the system and you attempt to create another username &quot;joe&quot; in Virtualmin? I would expect it to deal with your alias example in the same way.

Sun, 06/07/2009 - 06:59
Joe
Joe's picture

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, &quot;No .forward, no user .procmailrc, why the heck is mail being forwarded to the administrator of the server?&quot;).

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 &quot;info&quot; 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!

Sun, 06/07/2009 - 06:59
ADobkin

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 &quot;info&quot; 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 &quot;info&quot; 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 &quot;The username info is already in use on this system, please select another username.&quot;

How does Virtualmin currently deal with this problem for existing real user accounts, i.e. if the username &quot;joe&quot; already exists on the system and you attempt to create another username &quot;joe&quot; in Virtualmin? I would expect it to deal with your alias example in the same way.

Sun, 06/07/2009 - 06:59
Joe
Joe's picture

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-&gt;username conflicts are prevented by Virtualmin but username-&gt;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!

Sun, 06/07/2009 - 06:59
Joe
Joe's picture

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, &quot;No .forward, no user .procmailrc, why the heck is mail being forwarded to the administrator of the server?&quot;).

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 &quot;info&quot; 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!

Sun, 06/07/2009 - 06:59
ADobkin

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 &quot;info&quot; 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 &quot;info&quot; 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 &quot;The username info is already in use on this system, please select another username.&quot;

How does Virtualmin currently deal with this problem for existing real user accounts, i.e. if the username &quot;joe&quot; already exists on the system and you attempt to create another username &quot;joe&quot; in Virtualmin? I would expect it to deal with your alias example in the same way.

Sun, 06/07/2009 - 06:59
Joe
Joe's picture

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-&gt;username conflicts are prevented by Virtualmin but username-&gt;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!

Sun, 06/07/2009 - 06:59
ADobkin

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.

Sun, 06/07/2009 - 06:59
Joe
Joe's picture

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, &quot;No .forward, no user .procmailrc, why the heck is mail being forwarded to the administrator of the server?&quot;).

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 &quot;info&quot; 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!

Sun, 06/07/2009 - 06:59
ADobkin

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 &quot;info&quot; 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 &quot;info&quot; 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 &quot;The username info is already in use on this system, please select another username.&quot;

How does Virtualmin currently deal with this problem for existing real user accounts, i.e. if the username &quot;joe&quot; already exists on the system and you attempt to create another username &quot;joe&quot; in Virtualmin? I would expect it to deal with your alias example in the same way.

Sun, 06/07/2009 - 06:59
Joe
Joe's picture

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-&gt;username conflicts are prevented by Virtualmin but username-&gt;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!

Sun, 06/07/2009 - 06:59
ADobkin

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.

Sun, 06/07/2009 - 06:59
Joe
Joe's picture

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!

Topic locked