Remote IMAP SSL setting is not inherited by discovered folders, causing port 143 connections
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- perl
- Domain
- backend, networking
Research direction
Start in mailbox/mailbox-lib.pl, tracing the Inbox object and the folder hashes created from IMAP LIST, then inspect the paths that create missing Sent, Drafts, and Trash folders. Verify that discovered and auto-created folders retain the remote account’s SSL connection settings, validate the Perl syntax, and confirm those folders connect through the configured IMAPS endpoint.
Written by the indexing model from the issue text.
Description
Summary
When Usermin is configured to use a remote IMAP server with SSL enabled, the Inbox connects correctly over IMAPS, but IMAP folders discovered with LIST do not inherit the Inbox SSL setting. Opening folders such as Sent or Drafts then attempts a connection to port 143 instead of 993.
Observed on Usermin 2.550. The current master branch still appears to have the same behavior in mailbox/mailbox-lib.pl.
Reproduction
- Configure Read Mail to use a remote IMAP server.
- Enable SSL for that remote IMAP server.
- Use an IMAP server that exposes IMAPS on port 993 and does not expose plaintext IMAP on port 143.
- Log in to Usermin.
- Open Inbox — it works.
- Open a folder discovered from the IMAP server, such as Sent or Drafts.
Actual result
Inbox works, but discovered folders fail with an error equivalent to:
0 Failed to IPv6 connect to <imap-host>:143 : Connection refused
This is not an IPv6-specific problem. The discovered folder is trying the non-SSL IMAP port.
Expected result
All folders belonging to the configured remote IMAP account should inherit the account's SSL/TLS connection settings, so they connect the same way as Inbox.
Cause
In mailbox/mailbox-lib.pl, the Inbox object includes:
'ssl' => $config{'pop3_ssl'},
The folder objects created from IMAP LIST inherit server, username, password, etc., but do not inherit ssl:
push(@rv,
{ 'name' => &decode_utf7($fn),
'id' => $fn,
'type' => 4,
'server' => $imapserver,
'user' => $rv[0]->{'user'},
'pass' => $rv[0]->{'pass'},
'autouser' => $rv[0]->{'autouser'},
...
});
As a result, later IMAP logins for those folder objects fall back to the non-SSL port.
Verified workaround / test
Adding the following property to the discovered-folder object fixes the problem:
'ssl' => $rv[0]->{'ssl'},
After applying that one-line test patch and validating the Perl syntax, Sent and Drafts both opened normally over the same SSL-enabled remote IMAP account.
Related paths to check
The code paths that create missing Sent, Drafts, and Trash IMAP folder objects also appear to construct new folder hashes without explicitly inheriting the Inbox SSL setting. Those paths may need the same treatment.
If Usermin supports an explicit remote IMAP port in addition to the SSL flag, it may be safer for all auto-created/discovered folders to inherit the complete connection settings from the Inbox/account object rather than only the server/user/password fields.
There does not appear to be a practical UI workaround for the automatically managed special folders, so this affects remote-IMAP configurations where plaintext port 143 is intentionally disabled.
- Dominant language
- Perl
- Stars
- 153
- Forks
- 57
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from webmin/usermin
-
Needs Triage
Difficulty 4/5 3-5 days Newbie friendliness 38/100
-
Needs Triage
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
Needs Triage
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
Needs Triage
Difficulty 3/5 1-2 days Newbie friendliness 45/100
-
Needs Triage
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 87/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
objectionary/eolang.sty#184 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
linux-test-project/lcov#542 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
1.severity: security
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day