Limit alias destinations to local domains #338
Conversation
Adds optional parameter to limit the alias destinations to local domains. An additional check makes sure that the domain is in the list of postfix domain names.
|
If you're trying to avoid DMARC issues, you could configure your server to use SRS ? (eg. https://github.com/roehling/postsrsd ) |
|
The PR is an important feature in a modern-email world should a provider not wish to forward mail to remote servers. It could also be used for additional security in a company which may not want a user to forward mail to their public mail account. Your comment isn’t a solution to the feature, but I really do appreciate it nevertheless. I’ve used PostSRSd and have it set up for certain cases. Inevitably some spam (or just email formatted in a way a provider doesn’t like) will always slip through and then the server is taking credit for it under your hosts main domain. SRS does work around DMARC issues, but doesn’t fix that some users get huge quantities of mail of various quality and forwarding it to big providers causes them to judge you for it. Those providers then delay or reject certain mail. While we have a good track record, for the handful of folks who want to forward to gmail, we advise them to pull from gmail instead of mail forwarding it to help keep that reputation intact. The difference for deliverability of other e-mail in our tests is measurable. |
|
Is it possible someone would want to allow non-local forwards for some domains, and not all ? |
It's certainly possible. Some may way to allow only certain domains (ie: a parent company, or gmail) or even disallow certain domains (ie: free mail providers). A hook could be added on the failure of this function to allow someone to make exceptions. I'm happy to program that into the PR if you think it's appropriate. That said, it's probably more likely that it's an all-or-nothing (remote-vs-local) scenario, which is what this PR currently does. |
|
Yes - I was thinking your changes would be better if they were moved out into some sort of hook - where the admin-type decides what rules they want. We have other instances in the config file where a hook/callable can be specified and that's called by the code-base. It'd also allow someone to do a token SMTP/DNS check or whatever on the goto portion (if that doesn't happen already). |
| list(/*NULL*/, $domain) = explode('@', $domain); | ||
|
|
||
| // get all domains managed on this system by postfixadmin | ||
| $domains = list_domains(); |
There was a problem hiding this comment.
Would it make sense to limit this to domains visible to the currently logged in admin?
list_domains_for_admin($username) does that.
Background: By allowing all domains, this could leak information if a domain is hosted in the same PostfixAdmin instance (by trying various alias targets), even if an admin doesn't have permissions for this domain.
Sidenote: Since this function is only used by AliasHandler, I'd recommend to have it there instead of making functions.inc.php even bigger.
There was a problem hiding this comment.
I think that could easily be configurable even:
$domains = ( (Config::bool(‘emailcheck_localaliasownedonly’)) ? list_domains_for_admin($username) : list_domains() );
My end goal was more to prevent forwards to hotmail/gmail (in favour of pulling such data instead of pushing it via SMTP), but your point that this could leak data is certainly valid.
I’d think that’s appropriate to use list_domains_for_admin(), so I’ll agree with you.
There was a problem hiding this comment.
This could leak information if a domain is hosted in the same PostfixAdmin instance
I don't think such leak is really critical, because these details could be easily explored from DNS.
This is manual application of PR github.com/postfixadmin/pull/338 to the PostfixAdmin 3.2.4 release.
|
I'll first add to this conversation, because this is already going somewhat into the directions that are important for me. We are currently having issues with domain postmaster creating aliases with lots of external goto addresses. While the DMARC problem can and should be solved with postsrsd, having too many goto addresses still poses a problem because it amplifies spam. Our spam filter is catching some, but not all spam mails. Sometimes still dozens of mails still get forwarded, which can really hurt the mail server reputation. Therefore I think it should be possible to impose some sort of limitations for aliases. Currently, I'm thinking about adding a setting that simply limits the number of gotos for one alias. I think a limit of 10 is pretty reasonable. In all cases where there were more recipients, the alias function was basically a mailing list replacement / abuse. And my thoughts about limiting gotos to local domains: I don't think this is necessary. This needs to be solved by rewriting the sender address with postsrsd. |
|
This hasn't moved since 2020 and is an increasingly important feature (to not get flagged as a spammer by major providers where mail could be forwarded) with minimal additional code (only a few lines). The patch applies cleanly to the current codebase. While I know the long-term solution appears to be discussion of hooks, there doesn't appear to be much done on implementing this. In the meantime, can we please merge this feature? It can always be replaced with hooks at a later time. Can we please see this merged @DavidGoodwin ? |
…ocal domains) and #796 (mailbox.smtp_active / controlling outbound mail etc)
Adds optional parameter to limit the alias destinations to local domains. An additional check makes sure that the domain is in the list of postfix domain names. Forwarding to a remote server can forward Spam (hurting a server's reputation) and does not work in a DMARC-world where major senders limit who can send mail on their behalf. To avoid this, an optional parameter that allows for local aliases (such as to another mailbox in the current domain or to another domain on the same server), but will prevent remote aliases (such as to gmail or yahoo) from being created. This does not impact existing aliases.