Re: [Slackbuilds-users] UID/GID for another Dovecot case
On 02/15/2015 04:29 PM, Slacker wrote: On 02/14/2015 08:55 PM, Thomas Szteliga wrote: and please let us know when Your article is published :-) For better or worse, I am out of time for the next week, so here it is, warts and all: http://docs.slackware.com/howtos:network_services:postfix_dovecot_mysql I appreciate all previous comments and will continue to appreciate helpful comments, suggestions and corrections via the list or my own email as appropriate. It still has a few shortcomings I hope to correct as time permits - but I think this a pretty good first edition. Thanks, Robert ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On 02/15/2015 12:45 PM, Rob McGee wrote: On Sat, Feb 14, 2015 at 05:47:09PM -0700, Slacker wrote: On 02/14/2015 05:42 PM, Willy Sudiarto Raharjo wrote: So, please consider this a request for either discussion or simply for an assigned uid/gid for a vmail user. please use 303 for vmail On further discussion Willy and I have decided to revert this change. Thanks for the suggestion, and to all posters for their comments. We're sorry for any inconvenience regarding your howto. Not an inconvenience! Part of my continuing education! Thanks for all comments and replies! Robert ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On 02/14/2015 11:35 PM, Thomas Morper wrote: On Sun, 15 Feb 2015, Willy Sudiarto Raharjo wrote: So, please consider this a request for either discussion or simply for an assigned uid/gid for a vmail user. please use 303 for vmail 303 is a bad choice for the vmail uid because then you'll need further adjustments in the Dovecot config to work around a security feature to prevent users from ever logging in as daemons (i.e. with uids < 500). AH! One answer to a question I just posted in another reply! So this is a good reason not to use the lower numbers at least! A vmail user is not required at build time and not necessarily at runtime. When it is, the choice depends on the environment and on what one is trying to achieve. A static entry in the list of recommended UIDs/GIDs doesn't look sensible to me. Yes, and my thought was to provide a static choice when it is required, as it is not an "unusual" requirement. Thanks ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On 02/14/2015 09:08 PM, Thomas Szteliga wrote: On 02/15/2015 03:36 AM, Rob McGee wrote: I never have understood why so many small-time users want to have "virtual mail accounts." What is the appeal? "Gee whiz, all I do when I add a domain is enter it in mysql." Well, uh, how often do you add domains? I can see it if you're a large scale hosting provider. Why is that so good if you're not? In the small-timer case, delivery to system accounts is far more powerful and flexible. You can keep all your mail in your $HOME; you're able to run commands on certain incoming mail; you have many more options for storing and sorting mail. I was running multiple Dovecot/Postfix instances for years, and I had the biggest problems with upgrading/migration etc. with system accounts. With virtual vmail accounts moving configs with e-mail storage among servers is much easier, so now I'm using vmail everywhere. I have not run these myself before, but the migration and future management requirements were what led me to it. Furthermore, it's considerably less secure to have all mail under a single UID/GID, as most of these virtual/mysql howtos seem to advocate. A compromise of that user means all mail is at risk. With system users, each recipient has her own UID, and compromises are limited. Yes, but You already said "small-time users", so probably one-two domains, one owner, a single company etc. You can use multiple vmail users/groups (vmail1, vmail2) to separate customers. And when we're already in the subject of security, I would not give users access to their home dirs on an MTA. I would run an MTA in a separated vmachine instead of running multiple services on the same machine. And that's what I'm doing :-) Yes, that is very close to my own case - access to the machine will be strictly limited. (Actually that can be done with virtual also; both Postfix and Dovecot support map lookups for the UID & GID. But few howtos -- if any? I don't think I have seen one -- show how this is done.) So my concern here is twofold: one, it promotes "virtual mail" to users who should not be using it; and two, it promotes the less secure means of doing it, under a single UID/GID. As I already stated in this thread, I don't think that defining a vmail user/group in http://slackbuilds.org/uid_gid.txt is a good idea. IMO it's a bad idea and an unnecessary step :-) And uid 303 is really bad, because almost all howtos suggest 5000. OK, I realize the lower uid/gids are generally reserved for daemon processes, and there are a limited number of them... but really, it is still just a number - there isn't actually anything "special" about numbers in that range is there? I am not arguing it, I want to understand it better - why is it such a really bad idea? Thanks ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/ ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On 02/14/2015 08:55 PM, Thomas Szteliga wrote: On 02/14/2015 10:21 PM, Slacker wrote: I am writing a Slackdocs article for setting up a virtual mail server using Postfix, Dovecot and MySQL. In this use case we require a separate non-priv user/group for which the Dovecot documents suggest "vmail" ( http://wiki.dovecot.org/VirtualUsers ), and which I have used in my own implementation. This is purely a configuration option and is not required to build the Dovecot package. But it seems to me it is a common enough use case and that having an SBo assigned uid/gid for "vmail" would dovetail nicely with the dovecot docs and simplify virtual mail setup for those building with SBo scripts. It would also simplify my Slackdocs article. So, please consider this a request for either discussion or simply for an assigned uid/gid for a vmail user. Hello Slacker, please consider using the default uid 5000 http://wiki2.dovecot.org/HowTo/VirtualUserFlatFilesPostfix https://wiki.archlinux.org/index.php/Virtual_user_mail_system http://www.stefan-seelmann.de/wiki/mailserver-postfix-dovecot and please let us know when Your article is published :-) I will, on both counts! It is a work in progress! Robert ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/ ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On 02/14/2015 08:49 PM, Thomas Szteliga wrote: On 02/15/2015 01:42 AM, Willy Sudiarto Raharjo wrote: please use 303 for vmail I'm not sure if this (303) is a good idea? Everywhere I look I see uid 5000. I'm running Dovecot + Postfix on multiple machines, and I'm always using vmail/5000. http://wiki2.dovecot.org/HowTo/VirtualUserFlatFilesPostfix https://workaround.org/book/export/html/60 https://workaround.org/ispmail/squeeze/setting-up-dovecot http://www.openchange.org/cookbook/backends/sogo/dovecot.html https://www.linode.com/docs/email/postfix/email-with-postfix-dovecot-and-mysql-on-centos-5 And as Slacker stated, this is not required for building packages, so I don't think this should be defined in http://slackbuilds.org/uid_gid.txt The vmail user/group is not required for packaging and fully optional during dovecot usage. Slackbuilds do not create users/groups so the vmail group should not be defined there. For example, on some machines I'm using separate vmail groups for separate customers, starting with vmail/5000, vmail2/5001, vmail3/5002... I did see a number of references to uid 5000 for vmail, but never had the sense that it was pseudo-standard. In fact, it was the common use of "vmail" as the user/group name (I think because dovecot docs use it) but no compelling reason for any uid/gid that led to my question here. Thanks for the links too - I had seen some but not others. In the end my own approach resulted mostly from re-reading the dovecot and postfix docs after getting a general direction from other sources. Robert ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/ ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On 02/14/2015 08:39 PM, Mario Preksavec wrote: On 02/15/2015 03:36 AM, Rob McGee wrote: On Sat, Feb 14, 2015 at 02:21:26PM -0700, Slacker wrote: I am writing a Slackdocs article for setting up a virtual mail server using Postfix, Dovecot and MySQL. In this use case we require a separate non-priv user/group for which the Dovecot documents suggest "vmail" ( http://wiki.dovecot.org/VirtualUsers ), and which I have used in my own implementation. This is purely a configuration option and is not required to build the Dovecot package. But it seems to me it is a common enough use case and that having an SBo assigned uid/gid for "vmail" would dovetail nicely with the dovecot docs and simplify virtual mail setup for those building with SBo scripts. It would also simplify my Slackdocs article. So, please consider this a request for either discussion or simply for an assigned uid/gid for a vmail user. I never have understood why so many small-time users want to have "virtual mail accounts." What is the appeal? "Gee whiz, all I do when I add a domain is enter it in mysql." Well, uh, how often do you add domains? I can see it if you're a large scale hosting provider. Why is that so good if you're not? In the small-timer case, delivery to system accounts is far more powerful and flexible. You can keep all your mail in your $HOME; you're able to run commands on certain incoming mail; you have many more options for storing and sorting mail. Furthermore, it's considerably less secure to have all mail under a single UID/GID, as most of these virtual/mysql howtos seem to advocate. A compromise of that user means all mail is at risk. With system users, each recipient has her own UID, and compromises are limited. (Actually that can be done with virtual also; both Postfix and Dovecot support map lookups for the UID & GID. But few howtos -- if any? I don't think I have seen one -- show how this is done.) So my concern here is twofold: one, it promotes "virtual mail" to users who should not be using it; and two, it promotes the less secure means of doing it, under a single UID/GID. Very well said. I would like to think that vmail *example* group was intentionally left out from uid_gid.txt to let user take a chunk of uid/gid mappings and do it properly. I also think that Slackdocs shouldn't be another copy/paste with a few minor changes; in fact, if done right it could fill that gap Rob is talking about :-) Well, I can't speak for anyone else, but my own Slackdocs article (my first there too by the way) is certainly not copy/paste. I am trying to make it a genuine "how to" which will liberally include the "why to" - something I could not find anywhere when I started this exercise! But I will certainly want to consider some changes and additions based on comments in replies to my question here - thanks to all! Robert ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On 02/14/2015 07:36 PM, Rob McGee wrote: On Sat, Feb 14, 2015 at 02:21:26PM -0700, Slacker wrote: I am writing a Slackdocs article for setting up a virtual mail server using Postfix, Dovecot and MySQL. In this use case we require a separate non-priv user/group for which the Dovecot documents suggest "vmail" ( http://wiki.dovecot.org/VirtualUsers ), and which I have used in my own implementation. This is purely a configuration option and is not required to build the Dovecot package. But it seems to me it is a common enough use case and that having an SBo assigned uid/gid for "vmail" would dovetail nicely with the dovecot docs and simplify virtual mail setup for those building with SBo scripts. It would also simplify my Slackdocs article. So, please consider this a request for either discussion or simply for an assigned uid/gid for a vmail user. So discussion it shall be! I never have understood why so many small-time users want to have "virtual mail accounts." What is the appeal? "Gee whiz, all I do when I add a domain is enter it in mysql." Well, uh, how often do you add domains? I can see it if you're a large scale hosting provider. Why is that so good if you're not? My own use case is that I am consolidating some services for a customer, from multiple scattered hosting platforms into a VPS environment that they can manage. One big part of that is that they have dozens of email addresses across multiple domains that need to continue working when those existing hosts are changed or dropped. These "users" are email only and have no other presence on the host. This is really my first time out with setting up a a mail server, but virtual mail seemed the way to go, and has worked out well so far. In the small-timer case, delivery to system accounts is far more powerful and flexible. You can keep all your mail in your $HOME; you're able to run commands on certain incoming mail; you have many more options for storing and sorting mail. Furthermore, it's considerably less secure to have all mail under a single UID/GID, as most of these virtual/mysql howtos seem to advocate. A compromise of that user means all mail is at risk. With system users, each recipient has her own UID, and compromises are limited. (Actually that can be done with virtual also; both Postfix and Dovecot support map lookups for the UID & GID. But few howtos -- if any? I don't think I have seen one -- show how this is done.) So my concern here is twofold: one, it promotes "virtual mail" to users who should not be using it; and two, it promotes the less secure means of doing it, under a single UID/GID. These concerns had not really crossed my own radar, thanks for the thoughts! Robert ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On Sat, Feb 14, 2015 at 05:47:09PM -0700, Slacker wrote: > On 02/14/2015 05:42 PM, Willy Sudiarto Raharjo wrote: > >>So, please consider this a request for either discussion > >>or simply for an assigned uid/gid for a vmail user. > > > >please use 303 for vmail On further discussion Willy and I have decided to revert this change. Thanks for the suggestion, and to all posters for their comments. We're sorry for any inconvenience regarding your howto. -- Rob McGee - /dev/rob0 - r...@slackbuilds.org ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On Sun, 15 Feb 2015, Willy Sudiarto Raharjo wrote: > > So, please consider this a request for either discussion or simply > > for an assigned uid/gid for a vmail user. > please use 303 for vmail 303 is a bad choice for the vmail uid because then you'll need further adjustments in the Dovecot config to work around a security feature to prevent users from ever logging in as daemons (i.e. with uids < 500). A vmail user is not required at build time and not necessarily at runtime. When it is, the choice depends on the environment and on what one is trying to achieve. A static entry in the list of recommended UIDs/GIDs doesn't look sensible to me. -- ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On 02/15/2015 03:36 AM, Rob McGee wrote: > I never have understood why so many small-time users want to have > "virtual mail accounts." What is the appeal? "Gee whiz, all I do > when I add a domain is enter it in mysql." Well, uh, how often do > you add domains? I can see it if you're a large scale hosting > provider. Why is that so good if you're not? > In the small-timer case, delivery to system accounts is far more > powerful and flexible. You can keep all your mail in your $HOME; > you're able to run commands on certain incoming mail; you have many > more options for storing and sorting mail. I was running multiple Dovecot/Postfix instances for years, and I had the biggest problems with upgrading/migration etc. with system accounts. With virtual vmail accounts moving configs with e-mail storage among servers is much easier, so now I'm using vmail everywhere. > Furthermore, it's considerably less secure to have all mail under a > single UID/GID, as most of these virtual/mysql howtos seem to > advocate. A compromise of that user means all mail is at risk. > With system users, each recipient has her own UID, and compromises > are limited. Yes, but You already said "small-time users", so probably one-two domains, one owner, a single company etc. You can use multiple vmail users/groups (vmail1, vmail2) to separate customers. And when we're already in the subject of security, I would not give users access to their home dirs on an MTA. I would run an MTA in a separated vmachine instead of running multiple services on the same machine. And that's what I'm doing :-) > (Actually that can be done with virtual also; both Postfix and > Dovecot support map lookups for the UID & GID. But few howtos -- if > any? I don't think I have seen one -- show how this is done.) > So my concern here is twofold: one, it promotes "virtual mail" to > users who should not be using it; and two, it promotes the less > secure means of doing it, under a single UID/GID. As I already stated in this thread, I don't think that defining a vmail user/group in http://slackbuilds.org/uid_gid.txt is a good idea. IMO it's a bad idea and an unnecessary step :-) And uid 303 is really bad, because almost all howtos suggest 5000. -- Thomas Szteliga smime.p7s Description: S/MIME Cryptographic Signature ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On 02/14/2015 10:21 PM, Slacker wrote: > I am writing a Slackdocs article for setting up a virtual mail server > using Postfix, Dovecot and MySQL. > In this use case we require a separate non-priv user/group for which the > Dovecot documents suggest "vmail" ( http://wiki.dovecot.org/VirtualUsers > ), and which I have used in my own implementation. > This is purely a configuration option and is not required to build the > Dovecot package. But it seems to me it is a common enough use case and > that having an SBo assigned uid/gid for "vmail" would dovetail nicely > with the dovecot docs and simplify virtual mail setup for those building > with SBo scripts. It would also simplify my Slackdocs article. > So, please consider this a request for either discussion or simply for > an assigned uid/gid for a vmail user. Hello Slacker, please consider using the default uid 5000 http://wiki2.dovecot.org/HowTo/VirtualUserFlatFilesPostfix https://wiki.archlinux.org/index.php/Virtual_user_mail_system http://www.stefan-seelmann.de/wiki/mailserver-postfix-dovecot and please let us know when Your article is published :-) -- Thomas Szteliga smime.p7s Description: S/MIME Cryptographic Signature ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On 02/15/2015 01:42 AM, Willy Sudiarto Raharjo wrote: > please use 303 for vmail I'm not sure if this (303) is a good idea? Everywhere I look I see uid 5000. I'm running Dovecot + Postfix on multiple machines, and I'm always using vmail/5000. http://wiki2.dovecot.org/HowTo/VirtualUserFlatFilesPostfix https://workaround.org/book/export/html/60 https://workaround.org/ispmail/squeeze/setting-up-dovecot http://www.openchange.org/cookbook/backends/sogo/dovecot.html https://www.linode.com/docs/email/postfix/email-with-postfix-dovecot-and-mysql-on-centos-5 And as Slacker stated, this is not required for building packages, so I don't think this should be defined in http://slackbuilds.org/uid_gid.txt The vmail user/group is not required for packaging and fully optional during dovecot usage. Slackbuilds do not create users/groups so the vmail group should not be defined there. For example, on some machines I'm using separate vmail groups for separate customers, starting with vmail/5000, vmail2/5001, vmail3/5002... -- Thomas Szteliga smime.p7s Description: S/MIME Cryptographic Signature ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On 02/15/2015 03:36 AM, Rob McGee wrote: On Sat, Feb 14, 2015 at 02:21:26PM -0700, Slacker wrote: I am writing a Slackdocs article for setting up a virtual mail server using Postfix, Dovecot and MySQL. In this use case we require a separate non-priv user/group for which the Dovecot documents suggest "vmail" ( http://wiki.dovecot.org/VirtualUsers ), and which I have used in my own implementation. This is purely a configuration option and is not required to build the Dovecot package. But it seems to me it is a common enough use case and that having an SBo assigned uid/gid for "vmail" would dovetail nicely with the dovecot docs and simplify virtual mail setup for those building with SBo scripts. It would also simplify my Slackdocs article. So, please consider this a request for either discussion or simply for an assigned uid/gid for a vmail user. I never have understood why so many small-time users want to have "virtual mail accounts." What is the appeal? "Gee whiz, all I do when I add a domain is enter it in mysql." Well, uh, how often do you add domains? I can see it if you're a large scale hosting provider. Why is that so good if you're not? In the small-timer case, delivery to system accounts is far more powerful and flexible. You can keep all your mail in your $HOME; you're able to run commands on certain incoming mail; you have many more options for storing and sorting mail. Furthermore, it's considerably less secure to have all mail under a single UID/GID, as most of these virtual/mysql howtos seem to advocate. A compromise of that user means all mail is at risk. With system users, each recipient has her own UID, and compromises are limited. (Actually that can be done with virtual also; both Postfix and Dovecot support map lookups for the UID & GID. But few howtos -- if any? I don't think I have seen one -- show how this is done.) So my concern here is twofold: one, it promotes "virtual mail" to users who should not be using it; and two, it promotes the less secure means of doing it, under a single UID/GID. Very well said. I would like to think that vmail *example* group was intentionally left out from uid_gid.txt to let user take a chunk of uid/gid mappings and do it properly. I also think that Slackdocs shouldn't be another copy/paste with a few minor changes; in fact, if done right it could fill that gap Rob is talking about :-) -- Mario ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On Sat, Feb 14, 2015 at 02:21:26PM -0700, Slacker wrote: > I am writing a Slackdocs article for setting up a virtual mail > server using Postfix, Dovecot and MySQL. > > In this use case we require a separate non-priv user/group > for which the Dovecot documents suggest "vmail" ( > http://wiki.dovecot.org/VirtualUsers ), and which I have used > in my own implementation. > > This is purely a configuration option and is not required to build > the Dovecot package. But it seems to me it is a common enough use > case and that having an SBo assigned uid/gid for "vmail" would > dovetail nicely with the dovecot docs and simplify virtual mail > setup for those building with SBo scripts. It would also simplify > my Slackdocs article. > > So, please consider this a request for either discussion or simply > for an assigned uid/gid for a vmail user. I never have understood why so many small-time users want to have "virtual mail accounts." What is the appeal? "Gee whiz, all I do when I add a domain is enter it in mysql." Well, uh, how often do you add domains? I can see it if you're a large scale hosting provider. Why is that so good if you're not? In the small-timer case, delivery to system accounts is far more powerful and flexible. You can keep all your mail in your $HOME; you're able to run commands on certain incoming mail; you have many more options for storing and sorting mail. Furthermore, it's considerably less secure to have all mail under a single UID/GID, as most of these virtual/mysql howtos seem to advocate. A compromise of that user means all mail is at risk. With system users, each recipient has her own UID, and compromises are limited. (Actually that can be done with virtual also; both Postfix and Dovecot support map lookups for the UID & GID. But few howtos -- if any? I don't think I have seen one -- show how this is done.) So my concern here is twofold: one, it promotes "virtual mail" to users who should not be using it; and two, it promotes the less secure means of doing it, under a single UID/GID. -- Rob McGee - /dev/rob0 - r...@slackbuilds.org ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
On 02/14/2015 05:42 PM, Willy Sudiarto Raharjo wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So, please consider this a request for either discussion or simply for an assigned uid/gid for a vmail user. please use 303 for vmail Thanks! ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
Re: [Slackbuilds-users] UID/GID for another Dovecot case
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > So, please consider this a request for either discussion or simply > for an assigned uid/gid for a vmail user. please use 303 for vmail - -- Willy Sudiarto Raharjo -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlTf628ACgkQiHuDdNczM4EQLACfRzJaQM5YZlt5gHDmgRDtiGaf HM4An0oDoN4VoRhvfY153/+GNkkK+NyI =zxOh -END PGP SIGNATURE- ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
[Slackbuilds-users] UID/GID for another Dovecot case
I am writing a Slackdocs article for setting up a virtual mail server using Postfix, Dovecot and MySQL. In this use case we require a separate non-priv user/group for which the Dovecot documents suggest "vmail" ( http://wiki.dovecot.org/VirtualUsers ), and which I have used in my own implementation. This is purely a configuration option and is not required to build the Dovecot package. But it seems to me it is a common enough use case and that having an SBo assigned uid/gid for "vmail" would dovetail nicely with the dovecot docs and simplify virtual mail setup for those building with SBo scripts. It would also simplify my Slackdocs article. So, please consider this a request for either discussion or simply for an assigned uid/gid for a vmail user. Thanks! Robert ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
