• Plesk Uservoice will be deprecated by October. Moving forward, all product feature requests and improvement suggestions will be managed through our new platform Plesk Productboard.
    To continue sharing your ideas and feedback, please visit features.plesk.com

Question Spam Folder Location

BuzzLightBurger

Basic Pleskian
Server operating system version
Ubuntu 20.04 & Ubunti 24.4
Plesk version and microupdate number
18.0.71 #1
Hi
Quick Q. It was my understanding that Plesk moved the default location of the Spam folder to within the inbox (Inbox.Spam) to make it more compatible with other extensions like SpamAssassin, but after setting up a new Ubuntu 24.04 server running the latest Plesk/Roundcube etc, the Spam folder is at the root level (not within the inbox).

I have another server, running the same version of Plesk/Roundcube, albeit back on Ubuntu 20.04 that also has Plesk Premium Email installed.

Although PPE is only active on one domain, it seems the ActiveSync enhancement is available across every domain's webmail settings in Roundcube so it must be a global implementation.

Anyways, on the older server, the Spam folder exists as Inbox.Spam. This of course means that iPhones for example show both the Inbox/Spam folder as well as its own Junk folder.

iPhones connected to the new server do not have this double Spam/Junk folder annoyance and if the real names are shown (via Roundcube's settings) the Junk folder becomes Spam on the iPhone.

So the question is, is the new server exhibiting a configuration issue as it should have a Spam folder under the Inbox for each account or is the older server incorrectly configured to have a Spam folder within the Inbox?

Does SpamAssassin work with Spam folders located at the root level (as is the case on the new server)..

Which server is correct??

Regards
B
 
[...] It was my understanding that Plesk moved the default location of the Spam folder to within the inbox (Inbox.Spam) to make it more compatible with other extensions like SpamAssassin [...]
Yes, however not because of SpamAssassin but to be compatible with Qmail.

[...] So the question is, is the new server exhibiting a configuration issue as it should have a Spam folder under the Inbox for each account or is the older server incorrectly configured to have a Spam folder within the Inbox? [...]
To my knowledge the default configuration on Plesk is still to have the spam folder inside the inbox (Inbox.Spam). This hasn't changed as far as I am aware (there is no mention of a change in the change log). So I would assume that the fact this is different on your new server is because of a configuration issue.

You could compare the Dovecot namespace configuration on your servers to see if they use a different configuration. You'll find the namespace configuration in the /etc/dovecot/dovecot.conf file. I do want to point out that PPE uses a very different configuration for some mail aspects, not sure if that's the case for Dovecot too. Just in case, this the snippet of the default namespace configuration:

Code:
namespace inbox {
  separator = .
  prefix = INBOX.
  inbox = yes

  mailbox Sent {
    auto = subscribe # autocreate and autosubscribe the Sent mailbox
    special_use = \Sent
  }
  mailbox Spam {
    auto = create # autocreate Spam, but don't autosubscribe
    special_use = \Junk
  }
  mailbox Drafts {
    auto = create
    special_use = \Drafts
  }
  mailbox Trash {
    auto = create
    special_use = \Trash
  }
}

Does SpamAssassin work with Spam folders located at the root level (as is the case on the new server)..
Well, yes, but I suspect you're referring to the spam learning capability. Which probably won't work as intended when the spam folder is located somewhere else.
 
Hi
Both servers have the same contents in the dovecot.conf file, with the namespace matching the code quoted above.

I wasn't specifically referring to the learning, but that too. I was referring to the movement of mail to a spam folder at the server side (rule in the mail accounts)

Regards
 
Both servers have the same contents in the dovecot.conf file, with the namespace matching the code quoted above.
That's odd. Are there any other files in the /etc/dovecot/conf.d/ directory that maybe re-define the namespace configuration? If that's not the case I am not sure where the different behavior is coming from.
 
If you are using Plesk Premium Email, it creates default folders, including a INBOX.Spam folder.
I've just gone through all the files to try and fix the issue...

/etc/dovecot/conf.d/93-kolab-antispam.conf
/etc/dovecot/conf.d/93-kolab.conf

/etc/roundcubemail/config.inc.php
/etc/roundcubemail/kolab_folders.inc.php

Contain the offending configuration.

Having a Spam folder within the Inbox like this is just ugly!
Quite why Plesk thinks it's acceptable to force compatibility with Qmail when I've never used it, and have absolutely no intention of ever using it, is beyond me!
Postfix and Dovecot have been the default mail servers for years, so why! lol!

Sorry for the little rant, but I hope that answers you question.

LD
 
@LRLD

To answer your implicit question, being

Quite why Plesk thinks it's acceptable to force compatibility with Qmail when I've never used it, and have absolutely no intention of ever using it, is beyond me!

it can simply be stated that the current config is not about "compatibility", but it is related to the ability to switch easily from Qmail to Postfix (and back).

Stated differently, not about Qmail playing nicely with Postfix (i.e. compatibility), but more Qmail OR Postfix (i.e. switch from one flavor to another flavor).

Why would that be necessary?!??

Well, your remark

Postfix and Dovecot have been the default mail servers for years, so why!

is true for most scenarios, but not all.

In some scenarios, which are not quite frequently occurring though, there is more value or even a need to use Qmail.

Qmail used to be - in a far away past - better than Postfix, in every sense.

However, Postfix has been more actively developed in the recent past (read: decades) and it has become more and more "plug and play" - customize and add whatever you want, that is the essence of Postfix as it is now.

This also means a penalty on performance, if - for instance - a lot of custom config and "modules" or "functions" are added.

Yes, it is highly stable, but still a penalty on performance.

For that reason (and for many other reasons that are not explained), some users might still prefer Qmail.

As for me personally, I am not sure why one should bother to compare Postfix or Qmail - they are both good enough.

The bottleneck - if any (which is often not the case) - is still to be found in things like Dovecot, proxies, server resources (read: performance penalties should not be relevant when being able to implement proper servers) and so on.


Nevertheless, you are right ...... in a Plesk environment, the Postfix + Dovecot combination should be preferred.


Kind regards...
 
Back
Top