|
From: SourceForge.net <no...@so...> - 2012-04-09 20:39:37
|
Bugs item #3427541, was opened at 2011-10-23 06:55 Message generated for change (Comment added) made by christian_boltz 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: Christian Boltz (christian_boltz) Date: 2012-04-09 13:39 Message: Implementing this as configurable option was a good idea - it gives you better chances that we will implement it ;-) (I'd call it $CONF['alias_allow_external_goto'], but that's a technical detail.) However, your patch misses some details: - alias domains are not handled - no permission checks - in other words: the check could be abused to find out if an address exists on another domain that is managed in postfixadmin, but the current admin doesn't have access to (even without a log entry if you make sure to always include an invalid address) Besides that, I'm currently rewriting the code to use classes (see SVN trunk). This means checking if an alias exists is quite easy now: $handler = new AliasHandler(0, $admin_username); # includes permission check $address_exists = $handler->init($address); BTW: no need to check the mailbox table - every mailbox has an alias. To get a list of alias domains, use AliasdomainHandler->getList (see list-virtual.php in SVN trunk for a usage example). Then rewrite all aliases to the target domain and check with AliasHandler if they exist. If you want to update your patch: the check needs to go into function _field_goto() in model/AliasHandler.php. ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2011-10-23 13: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 |
