postfixadmin-tracker Mailing List for PostfixAdmin (Page 8)
Brought to you by:
christian_boltz,
gingerdog
Menu
▾
▴
postfixadmin-tracker — Postfix Admin tracker notification - READ ONLY!
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(67) |
Nov
(83) |
Dec
(47) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(57) |
Feb
(15) |
Mar
(21) |
Apr
(38) |
May
(27) |
Jun
(38) |
Jul
(35) |
Aug
(50) |
Sep
(8) |
Oct
(9) |
Nov
(59) |
Dec
(59) |
| 2009 |
Jan
(27) |
Feb
(42) |
Mar
(63) |
Apr
(46) |
May
(26) |
Jun
(25) |
Jul
(40) |
Aug
(19) |
Sep
(17) |
Oct
(35) |
Nov
(26) |
Dec
(21) |
| 2010 |
Jan
(11) |
Feb
(19) |
Mar
(40) |
Apr
(25) |
May
(23) |
Jun
(17) |
Jul
(10) |
Aug
(18) |
Sep
(21) |
Oct
(12) |
Nov
(10) |
Dec
(22) |
| 2011 |
Jan
(30) |
Feb
(23) |
Mar
(23) |
Apr
(38) |
May
(32) |
Jun
(19) |
Jul
(20) |
Aug
(36) |
Sep
(11) |
Oct
(28) |
Nov
(4) |
Dec
(4) |
| 2012 |
Jan
(6) |
Feb
(3) |
Mar
(16) |
Apr
(28) |
May
(29) |
Jun
(10) |
Jul
(2) |
Aug
(3) |
Sep
|
Oct
(13) |
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(11) |
Feb
(7) |
Mar
(29) |
Apr
(2) |
May
(3) |
Jun
(15) |
Jul
(8) |
Aug
(5) |
Sep
(5) |
Oct
(4) |
Nov
(27) |
Dec
(81) |
| 2014 |
Jan
(12) |
Feb
(13) |
Mar
(5) |
Apr
|
May
(41) |
Jun
(16) |
Jul
(7) |
Aug
(10) |
Sep
(24) |
Oct
(50) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(5) |
Feb
(2) |
Mar
(7) |
Apr
(20) |
May
(1) |
Jun
(3) |
Jul
(12) |
Aug
(1) |
Sep
(17) |
Oct
(5) |
Nov
(20) |
Dec
(10) |
| 2016 |
Jan
(10) |
Feb
(11) |
Mar
(22) |
Apr
(30) |
May
(33) |
Jun
(3) |
Jul
|
Aug
(12) |
Sep
(20) |
Oct
(11) |
Nov
(15) |
Dec
(8) |
| 2017 |
Jan
(1) |
Feb
(11) |
Mar
(10) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
(3) |
| 2018 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(4) |
Jun
(2) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2011-10-26 23:55:48
|
Feature Requests item #3006020, was opened at 2010-05-23 16:53 Message generated for change (Comment added) made by valkum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3006020&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Valkum (valkum) Assigned to: Nobody/Anonymous (nobody) Summary: Advanced Config and Lang Initial Comment: I think about use an extended version of Config and Lang variables. In my CLI I use a simple class, cloned from Joomla!. I think this should be implemented in functions.inc.php. With this class you can read even lang and conf option in classes. This is not working with globals. ---------------------------------------------------------------------- >Comment By: Valkum (valkum) Date: 2011-10-27 01:55 Message: What about changing the whole Lang object to use a helper function t("string") t("string") looks in Conf for language and include_once the matching language file when it is not already included. then t() returns the matching string ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2011-10-26 01:14 Message: (I'm also not sure how the Lang class will actually behave, especially under PHP5.2 where there isn't late static binding. I have a feeling calling Lang::getInstance() may actually return a Config object. If Lang has no functionality over/above a Config object, is it worth having having - why not just store the stuff in Config? ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2011-10-26 01:12 Message: <2p> To be argumentative - Changing the configuration to be in an object which is a singleton and silently used everywhere isn't really any different to using a global array - it's still "a magic thing" which the callee/user has no direct control over. The code has a high coupling to Config (the class) just in the same way as it had a high coupling to the $CONF array. Really the model classes should support injection of the Config/Lang objects so they can be (if necessary) swapped for something else to aid testing and reuse. </2p> ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-10-26 01:02 Message: In the meantime I moved your classes to model/ and removed duplicate code - the "Lang" class shrunk to class Lang extends Config { # exactly the same code, just another name ;-) } ;-) Some functions already use Lang::read and Config::read, the others will follow sooner or later. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3006020&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-25 23:14:26
|
Feature Requests item #3006020, was opened at 2010-05-23 14:53 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3006020&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Valkum (valkum) Assigned to: Nobody/Anonymous (nobody) Summary: Advanced Config and Lang Initial Comment: I think about use an extended version of Config and Lang variables. In my CLI I use a simple class, cloned from Joomla!. I think this should be implemented in functions.inc.php. With this class you can read even lang and conf option in classes. This is not working with globals. ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2011-10-25 23:14 Message: (I'm also not sure how the Lang class will actually behave, especially under PHP5.2 where there isn't late static binding. I have a feeling calling Lang::getInstance() may actually return a Config object. If Lang has no functionality over/above a Config object, is it worth having having - why not just store the stuff in Config? ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2011-10-25 23:12 Message: <2p> To be argumentative - Changing the configuration to be in an object which is a singleton and silently used everywhere isn't really any different to using a global array - it's still "a magic thing" which the callee/user has no direct control over. The code has a high coupling to Config (the class) just in the same way as it had a high coupling to the $CONF array. Really the model classes should support injection of the Config/Lang objects so they can be (if necessary) swapped for something else to aid testing and reuse. </2p> ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-10-25 23:02 Message: In the meantime I moved your classes to model/ and removed duplicate code - the "Lang" class shrunk to class Lang extends Config { # exactly the same code, just another name ;-) } ;-) Some functions already use Lang::read and Config::read, the others will follow sooner or later. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3006020&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-25 23:12:36
|
Feature Requests item #3006020, was opened at 2010-05-23 14:53 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3006020&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Valkum (valkum) Assigned to: Nobody/Anonymous (nobody) Summary: Advanced Config and Lang Initial Comment: I think about use an extended version of Config and Lang variables. In my CLI I use a simple class, cloned from Joomla!. I think this should be implemented in functions.inc.php. With this class you can read even lang and conf option in classes. This is not working with globals. ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2011-10-25 23:12 Message: <2p> To be argumentative - Changing the configuration to be in an object which is a singleton and silently used everywhere isn't really any different to using a global array - it's still "a magic thing" which the callee/user has no direct control over. The code has a high coupling to Config (the class) just in the same way as it had a high coupling to the $CONF array. Really the model classes should support injection of the Config/Lang objects so they can be (if necessary) swapped for something else to aid testing and reuse. </2p> ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-10-25 23:02 Message: In the meantime I moved your classes to model/ and removed duplicate code - the "Lang" class shrunk to class Lang extends Config { # exactly the same code, just another name ;-) } ;-) Some functions already use Lang::read and Config::read, the others will follow sooner or later. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3006020&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-25 23:02:55
|
Feature Requests item #3006020, was opened at 2010-05-23 16:53 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3006020&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Valkum (valkum) Assigned to: Nobody/Anonymous (nobody) Summary: Advanced Config and Lang Initial Comment: I think about use an extended version of Config and Lang variables. In my CLI I use a simple class, cloned from Joomla!. I think this should be implemented in functions.inc.php. With this class you can read even lang and conf option in classes. This is not working with globals. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-10-26 01:02 Message: In the meantime I moved your classes to model/ and removed duplicate code - the "Lang" class shrunk to class Lang extends Config { # exactly the same code, just another name ;-) } ;-) Some functions already use Lang::read and Config::read, the others will follow sooner or later. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3006020&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-25 22:43:11
|
Feature Requests item #3103847, was opened at 2010-11-05 21:59 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3103847&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Database Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Darek M (fafaforza) Assigned to: Nobody/Anonymous (nobody) >Summary: make mailbox quota non-editable Initial Comment: For an ISP type environment, it would be great if there was a way of setting a default quota for a domain, and any time a domain admin added a user, that quota would be applied to that specific user, but without the domain quota being able to set the per user quota when adding a new account. The last part could be easily configurable. The current domain quota appears to set the limit for all users combined, and if a user is added where the domain quota is exceeded, the new user addition is blocked. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-10-26 00:43 Message: The current code (2.3.x and SVN trunk) has two quota settings: - a quota per mailbox - a total quota for the domain (sum of all mailboxes) - (and a limit on the number of mailboxes per domain) If one of these is exceeded, user creation will be blocked. The only missing thing is hiding the input field for the quota when creating or editing a mailbox - but this shouldn't cause problems for ISP setups because it's only possible to enter a _lower_ quota than allowed. If you really want, replacing the input field for the quota with a hidden field is the easiest solution for now. I won't add a config option to hide the quota input field (we already have enough config options ;-) - but in future versions (not implemented yet) you'll be able to do this with a hook function that modifies $struct of MailboxHandler. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-04-10 19:33 Message: > The current domain quota appears to set the limit for all users combined, and if a user is added where the domain quota is exceeded, the new user addition is blocked. No, the current quota is per mailbox. New user addition is only blocked if you reach the number of allowed mailboxes for this domain. (However a patch to define a total quota for all mailboxes in a domain is available in the patches tracker, but not yet integrated.) > Required altering the 'domain' table to add a 'defquota' field of the same type as maxquota. maxquota contains exactly what you need, therefore the additional field shouldn't be necessary. > Please let me know if I should post a diff (using 2.3.2) I can't promise that we integrate your changes in the official code. But even if not, there might be people who need exactly the behaviour you have now and can use your patch. So: yes, please post the diff ;-) ---------------------------------------------------------------------- Comment By: Darek M (fafaforza) Date: 2010-11-12 21:24 Message: So I went ahead and hacked the code a bit to make it to my liking. Worked out very well. Per user quota for a domain is set at domain creation. Domain admins can see what the quota for new accounts will be but can't edit it. Required altering the 'domain' table to add a 'defquota' field of the same type as maxquota. Didn't want to mess with the existing domain quota stuff. Please let me know if I should post a diff (using 2.3.2) ---------------------------------------------------------------------- Comment By: Darek M (fafaforza) Date: 2010-11-05 22:02 Message: Spelling correction: "but without the domain quota being able to set the per user quota " should be "but without the domain admin being able to set the per user quota " Basically setting a limit in accounts and per account quota without a customer being able to change those limits. Only a super admin would. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3103847&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-25 21:56:11
|
Patches item #3428382, was opened at 2011-10-25 22:22 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=3428382&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Languages Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Pavel Usischev (pusischev) Assigned to: Nobody/Anonymous (nobody) Summary: Updated ru.lang Initial Comment: Attached is ru.lang updated according to svn rev. 1243 ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-10-25 23:56 Message: Thanks! Commited to SVN trunk r1245. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=3428382&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-25 20:22:58
|
Patches item #3428382, was opened at 2011-10-26 00:22 Message generated for change (Tracker Item Submitted) made by pusischev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=3428382&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Languages Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Pavel Usischev (pusischev) Assigned to: Nobody/Anonymous (nobody) Summary: Updated ru.lang Initial Comment: Attached is ru.lang updated according to svn rev. 1243 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=3428382&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-24 00:15:33
|
Patches item #3427631, was opened at 2011-10-24 01:41 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=3427631&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Languages Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Jordi Llonch (llonchj) Assigned to: Nobody/Anonymous (nobody) Summary: pCreate_mailbox_mail Initial Comment: The tag pCreate_mailbox_mail has a wrong spanish translation which is "Send welcome mail" not "create mailbox" ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-10-24 02:15 Message: Thanks for the patch! I just commited it to SVN r1233. BTW: The spanish translation file needs some more translations - about 50 lines are not translated yet. If you want to help, - download the latest version from SVN: http://postfixadmin.svn.sourceforge.net/viewvc/postfixadmin/trunk/languages/es.lang - translate all lines marked with "# XXX" and remove the "# XXX" marker (no need to translate lines marked with "obsolete") - send another patch ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=3427631&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-23 23:41:30
|
Patches item #3427631, was opened at 2011-10-24 10:41 Message generated for change (Tracker Item Submitted) made by llonchj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=3427631&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Languages Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jordi Llonch (llonchj) Assigned to: Nobody/Anonymous (nobody) Summary: pCreate_mailbox_mail Initial Comment: The tag pCreate_mailbox_mail has a wrong spanish translation which is "Send welcome mail" not "create mailbox" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=3427631&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-23 20:59:00
|
Bugs item #3427541, was opened at 2011-10-23 13:55 Message generated for change (Settings changed) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3427541&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: v2.3.4 Status: Open >Resolution: Works For Me Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Cannot restrict alias creation to managed domains. Initial Comment: I cannot find a configuration option which allows me to set a rule which says that you cannot create an alias to domains which your server does not manage. An example of what someone who doesn't understand mail may do is, let's say they own the domain example.com. They use postfix.admin to setup for the domain example.com and then they create a alias for joh...@ex... which redirects to joh...@gm.... IMHO postfix.admin is designed for people who don't know how to configure postfix through postfix itself and hence it's also more likely that these same people may also not understand email concepts as well as a seasoned postfix administrator (I had to install it for these types of people). While once upon a time, creating an alias like this would have worked, it has never been condoned and with todays modern mail servers it often causes a lot of mail to be rejected when sent from the server you set the alias up on to the final or intermediate MTA for a server you don't administer. The reason behind this is many domains, and this number is constantly rising, but many domains have an SPF (sender policy framework) . An SPF is a DNS record which typically states who can and cannot send mail on behalf of a domain. Most modern mail servers, when they receive mail, they will check the DNS of an envelope senders domain to see if a SPF exists. If they find an SPF then they will parse the SPF and compare it against the server which has sent the mail. Since an alias exists to an outside domain which the server doesn't manage, that means that the mail server you run which postfix.admin manages will receive email from all sorts of outside addresses and re-send them to the aliased email on a third party server. The third party server will look up an SPF for the envelope sender which is the original sending domain and will see which hosts are allowed to send for it. It will see that the mail server you run is not on that list and then depending on the configuration of the original SPF and the configuration of the final MTA, it will either drop or bounce the message and will also count towards email backscatter or possibly consider it a more severe type of spam which can lead to having your mail server listed DNS blacklist sites like spamhaus, etc. I'm sure there are probably more ways to configure this for most people but there are two types of rules I would like to create. For all users including super admins, I would like to have a restriction which says a alias cannot send to domains we don't manage which I can do through a SQL query. For regular users / non-superusers, I would like to say that they cannot create an alias to any other domain then the domains they manage in the server, for example if normal-user manages example.com then they can only create aliases to example.com and they cannot even create aliases to other domains that we do manage if they have not been selected as a user for that domain though I'm sure many people would probably want the option of only limiting it to domains they manage for normal users too so I think that should be an option for normal users to either limit it them to all domains the server manages or to just domains that they have rights on. ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2011-10-23 20:57 Message: I modified postfix.admin v2.3.4 to now have an option in the config which, when enabled will error alias creation or editing when a alias is crated or edited to point a email address that is not defined in mailbox or alias tables. The patch itself doesn't cause this to happen immediately but it adds the option $CONF['limit_unknown_domain_alias'] to config.inc.php which is set to "NO" in the patch. Changing this option to "YES" will cause it to only allow an alias to point to a already known address. Disclaimer: I almost never code in PHP and I learned it about a decade ago but the change is simple and the code looks clean. I'm sure if this option is incorporated then the maintainers may tidy it a little, rename aspects, etc etc but everything seems clean and running. Seems safe but use at your own risk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3427541&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-23 20:57:30
|
Bugs item #3427541, was opened at 2011-10-23 13:55 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3427541&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: v2.3.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Cannot restrict alias creation to managed domains. Initial Comment: I cannot find a configuration option which allows me to set a rule which says that you cannot create an alias to domains which your server does not manage. An example of what someone who doesn't understand mail may do is, let's say they own the domain example.com. They use postfix.admin to setup for the domain example.com and then they create a alias for joh...@ex... which redirects to joh...@gm.... IMHO postfix.admin is designed for people who don't know how to configure postfix through postfix itself and hence it's also more likely that these same people may also not understand email concepts as well as a seasoned postfix administrator (I had to install it for these types of people). While once upon a time, creating an alias like this would have worked, it has never been condoned and with todays modern mail servers it often causes a lot of mail to be rejected when sent from the server you set the alias up on to the final or intermediate MTA for a server you don't administer. The reason behind this is many domains, and this number is constantly rising, but many domains have an SPF (sender policy framework) . An SPF is a DNS record which typically states who can and cannot send mail on behalf of a domain. Most modern mail servers, when they receive mail, they will check the DNS of an envelope senders domain to see if a SPF exists. If they find an SPF then they will parse the SPF and compare it against the server which has sent the mail. Since an alias exists to an outside domain which the server doesn't manage, that means that the mail server you run which postfix.admin manages will receive email from all sorts of outside addresses and re-send them to the aliased email on a third party server. The third party server will look up an SPF for the envelope sender which is the original sending domain and will see which hosts are allowed to send for it. It will see that the mail server you run is not on that list and then depending on the configuration of the original SPF and the configuration of the final MTA, it will either drop or bounce the message and will also count towards email backscatter or possibly consider it a more severe type of spam which can lead to having your mail server listed DNS blacklist sites like spamhaus, etc. I'm sure there are probably more ways to configure this for most people but there are two types of rules I would like to create. For all users including super admins, I would like to have a restriction which says a alias cannot send to domains we don't manage which I can do through a SQL query. For regular users / non-superusers, I would like to say that they cannot create an alias to any other domain then the domains they manage in the server, for example if normal-user manages example.com then they can only create aliases to example.com and they cannot even create aliases to other domains that we do manage if they have not been selected as a user for that domain though I'm sure many people would probably want the option of only limiting it to domains they manage for normal users too so I think that should be an option for normal users to either limit it them to all domains the server manages or to just domains that they have rights on. ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2011-10-23 20:57 Message: I modified postfix.admin v2.3.4 to now have an option in the config which, when enabled will error alias creation or editing when a alias is crated or edited to point a email address that is not defined in mailbox or alias tables. The patch itself doesn't cause this to happen immediately but it adds the option $CONF['limit_unknown_domain_alias'] to config.inc.php which is set to "NO" in the patch. Changing this option to "YES" will cause it to only allow an alias to point to a already known address. Disclaimer: I almost never code in PHP and I learned it about a decade ago but the change is simple and the code looks clean. I'm sure if this option is incorporated then the maintainers may tidy it a little, rename aspects, etc etc but everything seems clean and running. Seems safe but use at your own risk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3427541&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-23 14:10:27
|
Bugs item #3427498, was opened at 2011-10-23 12:44 Message generated for change (Settings changed) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3427498&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Error in mailbox path creation Initial Comment: With $CONF['domain_path'] = 'NO' and $CONF['domain_in_mailbox'] = 'NO' in config.php mailbox path generated like $CONF['domain_path'] = 'NO' and $CONF['domain_in_mailbox'] = 'YES'. Change $maildir = $fUsername . "/"; in create_mailbox.php at string 179 to $maildir = escape_string (strtolower($_POST['fUsername'])) . "/"; resolve the problem. Thnks. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-10-23 16:10 Message: You mean something like this? (for use...@ex...): you expect: "username/" actual result: "use...@ex.../" This is intentional behaviour - if the maildir path would be just "username/", we would risk conflicts if you create a mailbox "use...@fo...r", the maildir would also be "username/" and the mails for use...@ex... and use...@fo...r would be mixed up in the same maildir. This is also documented in config.inc.php: // Note: If $CONF['domain_path'] is set to NO, this setting will be forced to YES. $CONF['domain_in_mailbox'] = 'YES'; I added a comment to the code (MailboxHandler.php) to avoid future confusion about this. If you really want to have only "username/" as name for the maildir (I don't recommend it, and you have been warned!), you can use a function for $CONF[maildir_name_hook]. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3427498&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-23 13:55:32
|
Bugs item #3427541, was opened at 2011-10-23 13:55 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3427541&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: v2.3.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Cannot restrict alias creation to managed domains. Initial Comment: I cannot find a configuration option which allows me to set a rule which says that you cannot create an alias to domains which your server does not manage. An example of what someone who doesn't understand mail may do is, let's say they own the domain example.com. They use postfix.admin to setup for the domain example.com and then they create a alias for joh...@ex... which redirects to joh...@gm.... IMHO postfix.admin is designed for people who don't know how to configure postfix through postfix itself and hence it's also more likely that these same people may also not understand email concepts as well as a seasoned postfix administrator (I had to install it for these types of people). While once upon a time, creating an alias like this would have worked, it has never been condoned and with todays modern mail servers it often causes a lot of mail to be rejected when sent from the server you set the alias up on to the final or intermediate MTA for a server you don't administer. The reason behind this is many domains, and this number is constantly rising, but many domains have an SPF (sender policy framework) . An SPF is a DNS record which typically states who can and cannot send mail on behalf of a domain. Most modern mail servers, when they receive mail, they will check the DNS of an envelope senders domain to see if a SPF exists. If they find an SPF then they will parse the SPF and compare it against the server which has sent the mail. Since an alias exists to an outside domain which the server doesn't manage, that means that the mail server you run which postfix.admin manages will receive email from all sorts of outside addresses and re-send them to the aliased email on a third party server. The third party server will look up an SPF for the envelope sender which is the original sending domain and will see which hosts are allowed to send for it. It will see that the mail server you run is not on that list and then depending on the configuration of the original SPF and the configuration of the final MTA, it will either drop or bounce the message and will also count towards email backscatter or possibly consider it a more severe type of spam which can lead to having your mail server listed DNS blacklist sites like spamhaus, etc. I'm sure there are probably more ways to configure this for most people but there are two types of rules I would like to create. For all users including super admins, I would like to have a restriction which says a alias cannot send to domains we don't manage which I can do through a SQL query. For regular users / non-superusers, I would like to say that they cannot create an alias to any other domain then the domains they manage in the server, for example if normal-user manages example.com then they can only create aliases to example.com and they cannot even create aliases to other domains that we do manage if they have not been selected as a user for that domain though I'm sure many people would probably want the option of only limiting it to domains they manage for normal users too so I think that should be an option for normal users to either limit it them to all domains the server manages or to just domains that they have rights on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3427541&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-23 10:44:37
|
Bugs item #3427498, was opened at 2011-10-23 17:44 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3427498&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Error in mailbox path creation Initial Comment: With $CONF['domain_path'] = 'NO' and $CONF['domain_in_mailbox'] = 'NO' in config.php mailbox path generated like $CONF['domain_path'] = 'NO' and $CONF['domain_in_mailbox'] = 'YES'. Change $maildir = $fUsername . "/"; in create_mailbox.php at string 179 to $maildir = escape_string (strtolower($_POST['fUsername'])) . "/"; resolve the problem. Thnks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3427498&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-11 12:38:41
|
Bugs item #3421296, was opened at 2011-10-10 16:22 Message generated for change (Comment added) made by lnxus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3421296&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface (example) Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dale Blount (lnxus) Assigned to: Nobody/Anonymous (nobody) Summary: patch for sf: 1861812 Initial Comment: Since I can't seem to figure out how to attach this to ID 1861812, I'll attach it here. This adds allowed_quota() calls around every $tQuota in create-mailbox.php Tested a number of cases and it appears to behave fine for me. ---------------------------------------------------------------------- >Comment By: Dale Blount (lnxus) Date: 2011-10-11 08:38 Message: Christian, I agree with your changes. Adjusted patch attached. Dale ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-10-10 18:08 Message: Since you didn't respond on #postfixadmin, I'll paste my questions/feedback here: [23:23] <cboltz> supa_user: I'm just reading your patch [23:23] <cboltz> and found something that looks like a bug to me [23:24] <cboltz> you should probably use = allowed_quota($fDomain, 0) everywhere [23:24] <cboltz> because a not-yet created mailbox does not use any quota yet ;-) [23:27] <cboltz> I also think you should not change the "$tQuota = $fQuota" in line 139 [23:27] <cboltz> because that line is meant to give the user the values he entered so he can correct them [23:28] <cboltz> IMHO it shouldn't be changed magically [23:29] <cboltz> (we also don't change other fields if they contain invalid values) [23:30] <cboltz> do you agree or did I overlook something? ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3421296&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-11 08:58:40
|
Feature Requests item #3417951, was opened at 2011-10-03 17:12 Message generated for change (Comment added) made by darkweaver87 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3417951&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: Rémi BUISSON (darkweaver87) Assigned to: Nobody/Anonymous (nobody) Summary: Alias listing in fetchmail -- Feature request Initial Comment: Hi all, It would be interesting to have also aliases listed in fetchmail rules. That way, we could fetch email from one account and dispatch to mutliple mailboxes. Thanks. Regards, Rémi ---------------------------------------------------------------------- Comment By: Rémi BUISSON (darkweaver87) Date: 2011-10-11 10:58 Message: Hi Christian, Thanks for your reply. I think my setup looks like your workaround. In my case I have this kind of setup: - ro...@my...d - su...@my...d - bo...@my...d which is an alias to robert + susan where mydomain.tld is my local postfix. So here, the alias is done for local delivery but I understand your point if the domain would have been anotherdomain.tld. By the way, I found a workaround which is to insert manually bo...@my...d in the fetchmail table. But it's still less practical than selecting bo...@my...d in "Fetch email -> New entry -> Mail box" ;-) Rémi ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2011-10-10 21:42 Message: Let me think about this a bit - even if I understand your request, it is a call for trouble (like using an alias as target that sends the mail back to the external address, where it must be fetched again). Only offering mailboxes as targets mostly avoids this problem. However there is a workaround - every mailbox has an alias. If you edit this alias, you can add more than one target address and get the behaviour you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3417951&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-10 22:08:51
|
Bugs item #3421296, was opened at 2011-10-10 22:22 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3421296&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface (example) Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dale Blount (lnxus) Assigned to: Nobody/Anonymous (nobody) Summary: patch for sf: 1861812 Initial Comment: Since I can't seem to figure out how to attach this to ID 1861812, I'll attach it here. This adds allowed_quota() calls around every $tQuota in create-mailbox.php Tested a number of cases and it appears to behave fine for me. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-10-11 00:08 Message: Since you didn't respond on #postfixadmin, I'll paste my questions/feedback here: [23:23] <cboltz> supa_user: I'm just reading your patch [23:23] <cboltz> and found something that looks like a bug to me [23:24] <cboltz> you should probably use = allowed_quota($fDomain, 0) everywhere [23:24] <cboltz> because a not-yet created mailbox does not use any quota yet ;-) [23:27] <cboltz> I also think you should not change the "$tQuota = $fQuota" in line 139 [23:27] <cboltz> because that line is meant to give the user the values he entered so he can correct them [23:28] <cboltz> IMHO it shouldn't be changed magically [23:29] <cboltz> (we also don't change other fields if they contain invalid values) [23:30] <cboltz> do you agree or did I overlook something? ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3421296&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-10 21:34:12
|
Bugs item #1861812, was opened at 2008-01-01 21:59 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1861812&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 3 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox creation: wrong default quota for next mailbox Initial Comment: How to reproduce: - create a domain with a maxquota different from $COMD['maxquota'] - go to create-mailbox.php?domain=domain_just_created - create a mailbox, it gets the domain default quota (as expected) - notice that the form proposes $CONF['maxquota'] instead of the domain maxquota To fix this, the line $tQuota = $CONF['maxquota']; probably has to be replaced with some database query (see GET part of the file, which should probably be moved down to avoid code duplication.) [minor, not release critical] ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-10-10 23:34 Message: Thanks, that makes this bugreport a duplicate :-) ---------------------------------------------------------------------- Comment By: Dale Blount (lnxus) Date: 2011-10-10 22:23 Message: Patch attached here: https://sourceforge.net/tracker/?func=detail&aid=3421296&group_id=191583&atid=937964 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1861812&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-10 20:23:10
|
Bugs item #1861812, was opened at 2008-01-01 15:59 Message generated for change (Comment added) made by lnxus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1861812&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 3 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox creation: wrong default quota for next mailbox Initial Comment: How to reproduce: - create a domain with a maxquota different from $COMD['maxquota'] - go to create-mailbox.php?domain=domain_just_created - create a mailbox, it gets the domain default quota (as expected) - notice that the form proposes $CONF['maxquota'] instead of the domain maxquota To fix this, the line $tQuota = $CONF['maxquota']; probably has to be replaced with some database query (see GET part of the file, which should probably be moved down to avoid code duplication.) [minor, not release critical] ---------------------------------------------------------------------- Comment By: Dale Blount (lnxus) Date: 2011-10-10 16:23 Message: Patch attached here: https://sourceforge.net/tracker/?func=detail&aid=3421296&group_id=191583&atid=937964 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=1861812&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-10 20:22:39
|
Bugs item #3421296, was opened at 2011-10-10 16:22 Message generated for change (Tracker Item Submitted) made by lnxus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3421296&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface (example) Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dale Blount (lnxus) Assigned to: Nobody/Anonymous (nobody) Summary: patch for sf: 1861812 Initial Comment: Since I can't seem to figure out how to attach this to ID 1861812, I'll attach it here. This adds allowed_quota() calls around every $tQuota in create-mailbox.php Tested a number of cases and it appears to behave fine for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3421296&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-10 20:03:33
|
Feature Requests item #3421289, was opened at 2011-10-10 16:03 Message generated for change (Tracker Item Submitted) made by libertytrek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3421289&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface Improvements (example) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Charles (libertytrek) Assigned to: Nobody/Anonymous (nobody) Summary: Add a 'Show only Active Vacations' filter Initial Comment: What the subject says... this could fit easily on the same line where the a...z letter filters are displayed... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3421289&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-10 19:58:23
|
Feature Requests item #3150300, was opened at 2011-01-03 07:13 Message generated for change (Comment added) made by libertytrek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3150300&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Charles (libertytrek) Assigned to: Nobody/Anonymous (nobody) Summary: Move config.local.php location to /etc/postfixadmin Initial Comment: For consistencies sake... ---------------------------------------------------------------------- >Comment By: Charles (libertytrek) Date: 2011-10-10 15:58 Message: Anybody else think this is a good idea (keep all local customizations together)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3150300&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-10 19:55:51
|
Feature Requests item #2813224, was opened at 2009-06-27 08:49 Message generated for change (Comment added) made by libertytrek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2813224&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Vacation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Charles (libertytrek) Assigned to: Nobody/Anonymous (nobody) Summary: End user customization of header strings Initial Comment: Hi all, I've been meaning to post this FR for a while... How hard would it be to provide the ability to configure the header strings that the vacation.pl script uses to determine when NOT to send a vacation auto-response? For example, in ASSP (also a perl script), in the GUI interface, it has options that have a textbox that can take either a reference to a file - ie, file:filename, where each line in the file would be a different string, or just a comma separated list of strings... (see attached for an example of how this looks in the ASSP GUI) This way, non-programmers like myself would have the ability to adjust these values, and add to (or subtract from) them, without having to resort to trying to edit the actual vacation.pl script. ---------------------------------------------------------------------- >Comment By: Charles (libertytrek) Date: 2011-10-10 15:55 Message: Here is an example of an email that our system sent a vacation response to this morning that should not have been sent: mailhost : Fri Oct 07, 15:52:48 : ~ # grep 7403988D6AC /var/log/messages Oct 10 06:59:37 mailhost postfix/smtpd[13273]: 7403988D6AC: client=sv4-mta-52a.emailfiltering.com[208.87.136.233] Oct 10 06:59:37 mailhost postfix/cleanup[13278]: 7403988D6AC: message-id=<000...@em...> Oct 10 06:59:37 mailhost postfix/qmgr[10236]: 7403988D6AC: from=<000...@em...>, size=11814, nrcpt=2 (queue active) Oct 10 06:59:37 mailhost postfix/virtual[13280]: 7403988D6AC: to=<us...@me...>, relay=virtual, delay=0.43, delays=0.42/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to maildir) Oct 10 06:59:38 mailhost postfix/pipe[13279]: 7403988D6AC: to=<user#med...@au...>, orig_to=<us...@me...>, relay=vacation, delay=0.81, delays=0.42/0.01/0/0.39, dsn=2.0.0, status=sent (delivered via vacation service) Oct 10 06:59:38 mailhost postfix/qmgr[10236]: 7403988D6AC: removed mailhost : Mon Oct 10, 07:07:14 : ~ If I could easily add 'email-bounces' string to a list of - call them 'veto strings' - used to determine when not to send a vacation message, this would be easily handled, but alas, it isn't... Any ideas anyone on how to do this? I don't even mind a way to do it manually by directly adding a new line to the vacation.pl script, but my earlier attempts at doing that failed... Ultimately though, I really think there should be a simple way to do this via the GUI... ---------------------------------------------------------------------- Comment By: Charles (libertytrek) Date: 2009-06-29 08:59 Message: Me neither... ;) thats why I included the link to the assp projects example gui page... I was hoping someone could use the assp.pl script as an example of how to do it... ASSP project download page is: https://sourceforge.net/projects/assp/ ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-06-29 04:02 Message: it's probably not difficult to do, although i'm not sure I know a good way to do it in perl.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2813224&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-10 19:42:19
|
Feature Requests item #3417951, was opened at 2011-10-03 17:12 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3417951&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Core >Group: None Status: Open Resolution: None >Priority: 3 Private: No Submitted By: Rémi BUISSON (darkweaver87) Assigned to: Nobody/Anonymous (nobody) Summary: Alias listing in fetchmail -- Feature request Initial Comment: Hi all, It would be interesting to have also aliases listed in fetchmail rules. That way, we could fetch email from one account and dispatch to mutliple mailboxes. Thanks. Regards, Rémi ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-10-10 21:42 Message: Let me think about this a bit - even if I understand your request, it is a call for trouble (like using an alias as target that sends the mail back to the external address, where it must be fetched again). Only offering mailboxes as targets mostly avoids this problem. However there is a workaround - every mailbox has an alias. If you edit this alias, you can add more than one target address and get the behaviour you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=3417951&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2011-10-07 22:59:05
|
Bugs item #3420440, was opened at 2011-10-07 23:06 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3420440&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: SVN (please specify revision!) >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: gen_show_status POP/IMAP check broken - recipient_delimiter Initial Comment: from #postfixadmin [22:14] <stderr1> cboltz: I think I found a bug in functions.php:gen_show_status() [22:15] <cboltz> details please ;-) [22:15] <stderr1> cboltz: haven't traced it but from reading the code I'm quite sure the POP/IMAP check incorrectly cuts the part after the recipient delimiter [22:15] <cboltz> 2.3.x or trunk? [22:16] <stderr1> In the deliverable check it's correct because it works on one address at a time, but in the pop/imap one the preg_replace works on the whole comma separated list [22:16] <stderr1> 2.3.5 if I'm not mistaken, wait... [22:16] <stderr1> no, 2.3.3 [22:17] <stderr1> so fo...@ba...,blurb@some.where would be cut to foo@some.where [22:19] <cboltz> indeed, this gives me "forward only" [22:19] <cboltz> same in trunk ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2011-10-08 00:59 Message: It turned out that it's not a bug in gen_show_status(), but in list-virtual. list-virtual has its own check to test if the target is the mailbox, and this check did not honor the recipient delimiter. Fixed in SVN r1198 (trunk) and 1199 (2.3 branch). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=3420440&group_id=191583 |
700 messages has been excluded from this view by a project administrator.
