Email subaddressing was added in v58 but its behavior is unexpected and caused a regression. All subaddressed emails should go to the inbox. If someone wants them to be in a folder, they can simply create a filter to do that.
On other providers, subaddressed emails go to the inbox. cPanel's behavior of creating a new unsubscribed folder is unexpected and cumbersome. It requires the extra step of logging onto webmail and subscribing to a new folder, but this does not fit with a normal workflow.
Example workflow:
- Sign up to a website using me+website@domain.com
- Create a recurring payment (VPS subscription, for example)
- Receive email about missed payment
- Correct payment information
After v58 it has to work like this:
- Sign up for a website using me+website@domain.com
- Create a recurring payment
- Remember to check your unsubscribed folders every day to see if you have any new ones
- Wait for an email to arrive (because you can't subscribe to a folder that doesn't exist)
- Subscribe to the folder
- Read email about missed payment
- Correct payment information
Before v58, subaddressed emails were recognized as separate accounts. So me@domain.com and me+website@domain.com were though to be different accounts. One could use filters to redirect the subaddressed emails into the main account, but that no longer works. It's good that subaddressed emails are recognized as using the main account, but the current behavior is not.
I like this idea 
Thanks so much for your submission! We had a good amount of internal conversation about this, and this feature, so I wanted to provide some further context here.
The feature, as released, was intentionally designed as the best of all possible options. There currently isn't an RFC or widely agreed upon spec for email sub-addressing, which means that anyone choosing to implement it will do so according to their needs. Unfortunately that definitely means that users might get different behavior, due to those different implementations.
The good news is that, currently if a filter exists for a particular sub-address construction (e.g. ken+cheese@example.com), the filter will be processed before the folder creation can occur. Folder creation will only occur if no filtering occurs. If that's not what you're seeing, please do open a ticket with your license provider or our support department: https://tickets.cpanel.net/
In relation to the discussion of subscription: we opted to go the route of not auto-subscribing the folders to avoid abuse of the system by spammers, similar to what we're currently seeing with iCloud Calendar spamming.
To help further understanding, we're going to improve our communication and education around this feature. This will come in the form of documentation, feature articles, and the like. I'm going to mark this as Not Planned for now, but if you have questions in the meantime please do feel free to email me!
Thanks so much for your submission! We had a good amount of internal conversation about this, and this feature, so I wanted to provide some further context here.
The feature, as released, was intentionally designed as the best of all possible options. There currently isn't an RFC or widely agreed upon spec for email sub-addressing, which means that anyone choosing to implement it will do so according to their needs. Unfortunately that definitely means that users might get different behavior, due to those different implementations.
The good news is that, currently if a filter exists for a particular sub-address construction (e.g. ken+cheese@example.com), the filter will be processed before the folder creation can occur. Folder creation will only occur if no filtering occurs. If that's not what you're seeing, please do open a ticket with your license provider or our support department: https://tickets.cpanel.net/
In relation to the discussion of subscription: we opted to go the route of not auto-subscribing the folders to avoid abuse of the system by spammers, similar to what we're currently seeing with iCloud Calendar spamming.
To help further understanding, we're going to improve our communication and education around this feature. This will come in the form of documentation, feature articles, and the like. I'm going to mark this as Not Planned for now, but if you have questions in the meantime please do feel free to email me!
We were using our cPanel email from bounce processing.
bounce+@domain.com and this change in cPanel is causing us a problem.
We originally polled the main inbox for these messages, so this change has stopped our systems working.
We were using our cPanel email from bounce processing.
bounce+@domain.com and this change in cPanel is causing us a problem.
We originally polled the main inbox for these messages, so this change has stopped our systems working.
I'm back with good news for this request! We are currently working on adding the ability to adjust this behavior to the product. This should be included in cPanel & WHM Version 80, which we expect to have released in the second quarter of this year. The new API calls were included with cPanel & WHM Version 78, but the interface for this feature won't be available until version 80. If you'd like to take a look at the API calls you can check them out here:
Email::enable_mailbox_autocreate
Email::disable_mailbox_autocreate
Email::get_mailbox_autocreate
I'm back with good news for this request! We are currently working on adding the ability to adjust this behavior to the product. This should be included in cPanel & WHM Version 80, which we expect to have released in the second quarter of this year. The new API calls were included with cPanel & WHM Version 78, but the interface for this feature won't be available until version 80. If you'd like to take a look at the API calls you can check them out here:
Email::enable_mailbox_autocreate
Email::disable_mailbox_autocreate
Email::get_mailbox_autocreate
Replies have been locked on this page!