After successfully setting up an iRedMail server for my main domain, I tried to add my secondary domain as an alias by following the steps on here: https://docs.iredmail.org/sql.add.alias.domain.html
This didn't do the trick just yet, so I additionally added the secondary domain into the /etc/postfix/main.cf:
virtual_alias_domains = domain2.tld
virtual_alias_maps = hash:/etc/postfix/virtual
Note: I didn't remove any of the existing mysql entries under virtual_alias_maps.
And entered the mapping into /etc/postfix/virtual and executed "postmap /etc/postfix/virtual" afterwards:
@domain2.tld @domain1.tld
This is working internally on the server. [email protected] can send to [email protected] and user2 will receive the mail in his mailbox. External emails also still arrive when sent to [email protected].
Unfortunately it doesn't function with external mails to the secondary domain. In my /var/logs/mail.log I find the following lines:
postfix/smtpd[5541]: NOQUEUE: reject: RCPT from mail-oi1-x231.google.com[2607:f8b0:4864:20::231]: 451 4.3.5 <[email protected]>: Recipient address rejected: Server configuration problem; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail-oi1-x231.google.com>
And:
postfix/smtpd[5644]: warning: problem talking to server 127.0.0.1:12340: Connection timed out
On port 12340 dovecot is listening:
dovecot 513 root 67u IPv4 17087 0t0 TCP 127.0.0.1:12340 (LISTEN)
In my dovecot log I find the following line repeatedly:
dovecot: quota-status: Error: quota-status: Client sent invalid recipient address: Invalid character in path
After some further testing with different external mail hosters, I realized that 2 out of 4 mails arrived when sent to the secondary domain. GMail and Hotmail didn't, my company's exchange and some other web provider came through.
And that's where I'm stuck. I suspect one of two things: Either I simply missed a necessary configuration, which seems highly likely, since I've never set up a mail server on Debian before, or the dovecot error is caused by my secondary domain. The secondary domain contains an umlaut (ä/ö/ü), which I'm well aware can cause some issues. Therefore I also own the domain in it's punycode formatted variant. So, whenever I added my secondary domain with it's umlaut to a configuration, I also added the punnycode version of it, assuming it would solve any issues in that regard.
iRedMail/postfix/dovecot/whateverelseisinvolved seem to be working fine with punnycode/umlauts per se, it just seems to depend on the sender, since only half the mails go lost (sender won't get an error). Any guess as to why or what logs I could check to dig deeper into this? Did I simply miss to configure something obvious?
Any push into the right direction is highly appreciated.
Regards, Snot
==== Basic Info ====
- iRedMail version: 1.4.0 MARIADB edition
- Linux/BSD distribution name and version: Debian GNU/Linux 10 (buster) - 10.10
- Used DB: MySQL (MariaDB)
- Web server: Nginx
==== Edit ====
As far as the base setup; After a clean Debian 10 installation I've followed the steps in this guide https://www.linuxbabe.com/mail-server/debian-10-buster-iredmail-email-server
Any specific config that alters from the guide has been mentioned in the post. I've additionally issued a certificate which includes the main domain and the secondary domain in punnycode.
Here the various logs on boot:
/var/log/mail.log:
Aug 14 14:24:36 s postfix/postfix-script[1637]: warning: symlink leaves directory: /etc/postfix/./makedefs.out
Aug 14 14:24:37 s amavis[573]: starting. /usr/sbin/amavisd-new at host.domain1.tld amavisd-new-2.11.0 (20160426), Unicode aware, LC_ALL="C", LANG="en_US.UTF-8"
Aug 14 14:24:37 s postfix/postfix-script[1819]: starting the Postfix mail system
Aug 14 14:24:37 s postfix/master[1821]: daemon started -- version 3.4.14, configuration /etc/postfix
Aug 14 14:24:39 s amavis[1915]: Net::Server: Group Not Defined. Defaulting to EGID '121 121'
Aug 14 14:24:39 s amavis[1915]: Net::Server: User Not Defined. Defaulting to EUID '113'
Aug 14 14:24:39 s amavis[1915]: No ext program for .F, tried: unfreeze, freeze -d, melt, fcat
Aug 14 14:24:39 s amavis[1915]: No ext program for .zoo, tried: zoo, unzoo
Aug 14 14:24:39 s amavis[1915]: No decoder for .F
Aug 14 14:24:39 s amavis[1915]: No decoder for .zoo
Aug 14 14:24:39 s amavis[1915]: Using primary internal av scanner code for clamav-socket
Aug 14 14:24:39 s amavis[1915]: Found secondary av scanner clamav-clamscan at /usr/bin/clamscan
/var/log/dovecot/dovecot.log:
Aug 14 14:24:26 s dovecot: master: Dovecot v2.3.4.1 (f79e8e7e4) starting up for pop3, imap, sieve, lmtp (core dumps disabled)
Aug 14 14:24:43 s dovecot: stats: Error: (stats-reader): didn't reply with a valid VERSION line: EXPORT#011global
Aug 14 14:24:43 s dovecot: stats: Error: (stats-reader): didn't reply with a valid VERSION line: EXPORT#011global
grep postfix /var/log/syslog:
Aug 14 14:24:36 s postfix/postfix-script[1637]: warning: symlink leaves directory: /etc/postfix/./makedefs.out
Aug 14 14:24:37 s postfix/postfix-script[1819]: starting the Postfix mail system
Aug 14 14:24:37 s postfix/master[1821]: daemon started -- version 3.4.14, configuration /etc/postfix
I've disabled thequota features and enabled SMTPUTF8 in my postfix main.cf, no notable change except from an additional line on boot in the mail.log:
Aug 14 14:59:46 s amavis[571]: starting. /usr/sbin/amavisd-new at host.domain1.tld amavisd-new-2.11.0 (20160426), Unicode aware, LC_ALL="C", LANG="en_US.UTF-8"
The behaviour is still the same unfortunately. After further analyzing the logs I realized that it seems as if the mails from the providers that come through get sent via punycode (even if I specifically sent it to the domain with the umlaut/non-ASCII-char). GMail on the other hand actually sends the mail to the domain that contains the umlaut (Non-punycode, even if I specifically use the punycode format in the recipient mail adress). So, I'll either need to teach my server to handle the non-ASCII-chars or I need to teach Google to send via punycode. Or teach my server to translate umlauts to punycode. Option 2 is obviously not really on option, so 1 or 3 it is.
mail.log entry from non-GMail hoster mail:
postfix/amavis/smtp[2300]: 4Gn0zh0z4FzLnSJ: to=<[email protected]>, orig_to=<[email protected]>, relay=127.0.0.1[127.0.0.1]:10024, delay=4, delays=0.1/0/0.01/3.9, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 4Gn0zm04JHzLxc0)
mail.log entry from GMail mail:
Aug 14 15:06:44 s postfix/smtpd[2281]: warning: problem talking to server 127.0.0.1:12340: Connection timed out
Aug 14 15:06:44 s postfix/smtpd[2281]: NOQUEUE: reject: RCPT from mail-ot1-x32b.google.com[2607:f8b0:4864:20::32b]: 451 4.3.5 <user@dömain2.tld>: Recipient address rejected: Server configuration problem; from=<[email protected]> to=<user@dömain2.tld> proto=ESMTP helo=<mail-ot1-x32b.google.com>
As I still cannot see a full solution (address rewriting in Postfix might work, but would be a sad end of this story), I am collecting my diagnostics steps in an answer:
Acquire the effective configuration, such as dumped by the commands
postfix -nandpostfix -Mif the mail server to ensure a clear understanding of the way the different services (amavis, primarily) are integrated.Individually test non-ASCII in localpart, in non-address headers, and in domain names (there as A-Label encoded via Punycode to start like
xn--, and as Unicode directly containing the non-ASCII letters)Keep
SMTPUTF8disabled in Postfix - Dovecot does not yet fully support handling mail that could be received that way, and its neither required nor necessarily helpful in resolving problems in amavis.amavis has a
$log_levelsetting (in Debian, presumably in/etc/amavis/conf.d/) that may be zeroed as part of your iRedMail distribution.If you have the option to switch that, running amavis as a before-queue milter (instead of as a post-queue smtp filter) may or may not reveal a more useful error or behaviour.
amavis fixed some mariadb-specific SQL+Unicode issues after the version 2.11 you are using, a useful error might be in the database log - or could be ruled out by comparing the same stack configured with a functionally identical postgres backend (postgres does not share the Unicode features/bugs of MySQL&MariaDB)