@joseph Received = queued for delivery, whereas saved = delivered to mailbox(es).
Received is therefore the inbound equivalent to the outbound 'queued for delivery'. The problem is that received does not have its own filter label so you cannot show inbound received (queued) messages without also showing outbound mail queued for delivery.
@girish As you have been tagged in this thread, could you perhaps also comment on the filter settings not been saved on page reload?
@d19dotca
I just updated my post because just selecting received does in fact only show saved. You also have to select 'queued' for the received mails. This is rather illogical labeling but makes sense because saved mails have been delivered to the mailbox (incoming) and received mails are still being processed.
@d19dotca You need to select 'queued' to have the received mails show up as well.
On another point, I have noticed that not selecting spam in the filter is disregarded and mails identified as spam are still shown (unless they are denied). Also, the filter settings are not being saved on page reload.
@girish What determines what is shown there and what not. With these botnets it seems always the first connection attempt shows up in the UI, the other 99 do not. So it is one denied connection per IP per x minutes?
In the UI it is possible to filter the display so that denied mails do not show up, but unfortunately this filter is not saved on page reload. That would be a nice possibility to have because during these annoying botnet "campaigns" if several domains are being targeted the UI still shows one entry for each domain per hour.
@girish Is there really any point blocking the IPs in this case? They tend to only be used once and a short time later a different compromised computer will try to connect with a different IP address.
Yes, this is an attempted spam attack from a botnet pointlessly sending mails from compromised computers to non-existent addresses at regular intervals. If you look closely there will be 100 at a time, probably about once an hour to each targeted domain and each time from a different IP. I have no idea what the spammers are trying to achieve here other than maybe trying to find insecure or poorly configured mailservers, but we see it from time to time as well.
There is nothing much you can do about it but apart from annoying entries in the log nothing will happen as the mails will be rejected / the sender blocked and after a while (possibly a few weeks) they will just stop.
I was experiencing the same problem. The solution is to select filter by realm roles. It seems to default to filter by realm clients.
If clearing the cache doesn't help, check to see if the ServiceWorker HumHub automatically installs is still being loaded in the browser.
@nebulon Correct, but I just realised that in copying and pasting I appear to have missed something.
That's embarassing. In any case it has now worked and this is resolved. Thanks for the quick reply.
I am trying to use the terminal to set an admin user as per the instructions in the documentation but don't seem to be able to find the correct place to do so and keep getting "command not found". Do I need to run the command as root and / or from a particular directory? Using the latest version of the app.
I can also recommend the Custom Fields and Workflows modules.
@archos I think you are maybe misunderstanding something here. Users and customers are not the same thing. Users are support staff who log in to Freescout and can reply to tickets. Customers should not have accounts / be able to log in at all as otherwise they will indeed see - and be able to reply to - all conversations in mailboxes they are allocated to.
Customers can access their own tickets if you have the module End User Portal: https://freescout.net/module/end-user-portal/. What they see there is linked to their email address(es) and the respective mailbox in Freescout.
@murgero Many thanks for your help.
@murgero Thank you. Unfortunately it still doesn't work. Now getting
/usr/bin/env: ‘node’: No such file or directory
as a response.
As I understand it npm should be installed and usuable in the LAMP app, bit every time i try to execute the command
npm clean-install
as the www-data user in the public directory I get the error npm: command not found. I've seen a few tips here in the forum relating to problems with npm but nothing that solves this.
Is it maybe possible to change the order in which incoming mails are filtered? With sieve you can tell the server to discard mails that match certain criteria, but that only works for mails that have not already been classified as SPAM. i suspect this is not that trivial though because the sieve filters work at the mailbox level.
@W1LMS See it as two levels of security. Firewall at DC level and at server level is also best practice.
Yes, you have to upload it to the server's file system first.
Is the www subdomain pointing to your Cloudron server in DNS?