| SYSTEM INFORMATION | |
|---|---|
| OS type and version | AlmaLinux release 9.1 (Lime Lynx) |
| Virtualmin version | 7.5 |
| Postfix version | 3.5.9 |
| Roundcube version | 1.6.0 |
It was a bit overdue. I’ve finally moved my virtualmin system running on centos to almalinux. During the move, I made some different configuration decisions from my old system.
One of those decisions is now giving me a headache.
On the previous system, account names were created as “USER.DOMAIN”. Because it was so confusing for my elderly parents to remember, I changed it to “USER@DOMAIN” on the new server. This way they only had to remember their e-mail address to login.
In preliminary testing after moving a couple of domains, I noticed I could not log in to roundcube, the webmail client we’re using. Username was correct, password was correct. Logging in through a different mail client (K9 on android, IMAPS + SMTP) works just fine.
So I tailed the maillog to see what error was being thrown. I got this:
Jan 22 07:54:53 SERVER dovecot[69792]: imap-login: Disconnected: Connection closed (auth failed, 1 attempts in 2 secs): user=<USER\@DOMAIN>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured, session=<C99bwtTymqp/AAAB>
I notice the @ is being escaped when attempting to login with imap. That can’t be right I thought. I checked the login form, sure enough. No escaping of the @ there.
I reviewed the roundcube configuration file and noticed the postfix virtual map is linked in there, so I go and have a look at the virtual map of postfix (/etc/postfix/virtual).
There I notice that for each user which has “Additional email addresses” (Virtualmin => edit users => user => E-mail settings => Additional email addresses), the destination (second field on the line) has an escaped @. All other accounts, who have only a single address, are fine.
so, of course, first thing I do is do a sed replace of all those escape chars and save the file, run “postmap /etc/postfix/virtual” and be over with it.
After this, I manage to log into roundcube. other imap clients were also fine. Sending mail to mail-tester gave splendid results. All seemed fine with the world.
So I continued and migrated all the remaining DNS and called it a day.
What I also did that day was copy some of the custom configuration I’d have made in postfix over the years over to the new postfix config. This included the following:
DISCLAIMER: DO NOT USE THIS, IT DOESN’T WORK!
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_invalid_hostname,
reject_unauth_pipelining,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_rbl_client relays.ordb.org,
reject_rbl_client blackholes.easynet.nl,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client proxies.blackholes.wirehub.net,
reject_rbl_client bl.spamcop.net,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client opm.blitzed.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client b.barracudacentral.org,
reject_rbl_client dnsbl.njabl.org,
reject_rbl_client list.dsbl.org,
reject_rbl_client multihop.dsbl.org,
check_policy_service unix:/var/spool/postfix/postgrey/socket
What I did not test until the next early morning was “receiving e-mails, does that work?”. I woke up to an empty mailbox. No spam. Strange, Perhaps the new server has better anti-spam (it does)? But no daily newsletters, no status mails. Something must be wrong.
I try to send myself an e-mail. Doesn’t arrive. Great.
Looking at the logs, first thing I notice is that all incoming mails are rejected. Mails from google and microsoft inclusive. I was puzzled. This seemed like an upside-down world.
Jan 21 06:16:18 SERVER postfix/smtpd[371935]: NOQUEUE: reject: RCPT from mail-ua1-f44.google.com[IP]: 554 5.7.1 Service unavailable; Client host [IP] blocked using sbl.spamhaus.org; Error: open resolver; https://www.spamhaus.org/returnc/pub/2400:cb00:114:1024::ac44:31d3; from=<USER@gmail.com>
to=<USER@DOMAIN> proto=ESMTP helo=<mail-ua1-f44.google.com>
I commented out the rbl rejects in the configuration to avoid these kind of errors.
It did solve the rejects, but now I was presented with a whole new exciting error message:
Jan 21 08:29:44 SERVER postfix/error[381424]: 817D54021515: to=<USER@DOMAIN>, relay=none, delay=13, delays=13/0.01/0/0.01, dsn=5.1.1, status=bounced (User unknown in virtual alias table)
Splendid. User unknown in virtual alias table. I did grep for that particular username and can tell you, I got a positive return. Anyway, I had a feeling deep down that most of the changes I made to the postfix configuration could have broken things.
So I went back to the /etc/postfix/virtual file and looked at it again. No clue how to identify the accounts that need an escaped @ and the ones that don’t.
What I ended up doing is going in Virtualmin to all the accounts that had additional e-mail addresses and I added another bogus one for each account. This overrode the current file and all the escaped @s were back where they are supposed to be.
Looking at the logs, mails do now seem to find their way into the mailbox like they are supposed to. This unfortunately leaves me again with my original problem: I can’t log into roundcube.
I’d like to understand what’s happening. Why have some accounts their @ escaped in postfix virtual map and why do others not?
I have already figured out that roundcube is using the virtual map to select the account name for an e-mail account. Removing the virtual map references from the roundcube configuration resolves this, but also removes some of roundcube features. I’d prefer they would stay linked for identities.
I have just tried it and it worked for me with