Join Log in
Score:1
SnotMcBooger avatar Server

iRedMail: Domain alias not working with some external mails (diacritics/punycode)

ke flag
SnotMcBooger

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>
227
1 + 2
SnotMcBooger avatar
ke flag
SnotMcBooger
Thanks for the input @anx. I've added the logs from after boot and some further notes. I've enabled the SMTPUTF8 support in postfix, since it wasn't enabled, but unfortunately no change. I've also disabeld the quota features but could notice any difference in behaviour. As stated in the post, it seems like the mails that get throught get sent in punycode, unlike the gmail mails, that actually get sent to the domain that contains the non-ascii char. Maybe there's a way to translate that to punycode before processing it further?
0
Reply
SnotMcBooger avatar
ke flag
SnotMcBooger
Thanks for the hint, I've reverted the SMTPUTF8 setting. I've restarded the server completely multiple times. In fact, I rebooted the server just before extracting the logs I've added to the post. Still rebooted it, same results tho. The timeout only happens with mails sent to "dömain2.ch", any other mail gets through. Even the punycode ones. The timeout happens at the dovecot port, but only when a mail containing an umlaut in the domain is sent, without being transformed to punycode by the sending mailserver, for example google or hotmail. Generally exchange server seems to conv it to puny.
0
Reply
Score:0
anx avatar Server
fr flag
anx

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 -n and postfix -M if 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 SMTPUTF8 disabled 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_level setting (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)

0 + 1
anx avatar
fr flag
anx
I sure hope its *not* another one of those "Unicode, but the wrong one" problems again..
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.