Gebemsea

I just upgraded to the November release and had this exact problem. I did find a root cause IN MY SETUP. Sharing in case it helps.

Setup:

• Mailcow DNS with forwarding domain to high-powered Pfsense box sitting next to mailcow (no need for two unbounds here).
• PFSense configured with NAT to redirect all LAN DNS requests to itself
• PFSense running PFBlocker to block outbound DNS-over-HTTP (DOH) and DNS-Over-TCP queries

Issue:

• PFBlocker, by default, blocks trafic of ALL Protocols types to the addresses in it’s DOH block lists
• Block lists include 1.1.1.1, 8.8.8.8, 9.9.9.9 which Mailcow uses to check the health of Unbound

Solution:

• Edit the DOH rule to only block TCP & UDP protocols, thereby allowing ICMP to pass
• I can imagin this can occur with other firewall softwares
• In PFSense, to do this: PFBlocker -> IP -> IPv4 -> DoH_IP -> Advanced Outbound Firewall Rule Settings ->Custom Protocol -> TCP/UDP

Vielen Dank an verschiedene Leute, die die Nachrichten und Warnungen hier veröffentlichen. Ich baute Sicherheit, Überwachung und Familienkommunikation um den Ejabberd der Kuh herum auf. Ich bin traurig, es gehen zu sehen, aber vielleicht war es eine Sache zu viel für ein kleines Team, um es zu unterstützen und zu entwickeln. Jetzt kann ich mailcow erst aktualisieren, wenn ich meinen eigenen xmpp-Server erstellt und herausgefunden habe, wie ich haproxy auf meiner Firewall richtig konfiguriert habe.

Hi,

With a catchall alias correctly configured, email for all usernames should be accepted. I think you still need to add the catchall alias:

Mailcow -> Configuration -> Mail Setup -> Alias -> Add Alias:

Alias Address: @domain
Goto Address: catchall@domain

Hi, ilsaul, I have worked in the way you suggest since my first self-hosted mail server in 1995. Being able to do what you want was one of my key requirements before switching to the Mailcow. I’ve had it set up working really well in Mailcow for over a year. I use an extension of Dan’s suggestion, like this:

Share email addresses with third parties using the format prefix.label@example.com, where label is different for different ‘suppliers’, e.g. Mailcow, facebook, etc. and prefix is ‘user’ or some other unique string the user want’s to use (actually, I allow any of . or - or _ as the separator; don’t use +).

1. Create a dummy user to receive catchall mail, e.g. catchall@example.com
2. As Dan says, create a catchall alias, but direct it to the dummy user account created in #1
3. In Mailcow admin -> Configuration -> Mail Setup -> Filters, add a pre-filter (owner = catchall@example.com), like this.
   require "regex";
if anyof ( address :regex ["to", "cc"] "^prefix[._-]") {
redirect "user@example.com";
}

Once you get started with this, you can be even more imaginative with your filter.

If you implement this, you should also consider the following:

1. This does not work with the user in BCC, so check the catchall mailbox from time to time. Add an alias if important email is sent to bcc. There might be a way of improving the filter to handle bcc, but I never got round to making that work.
2. If you want to reply as one of the addresses, prefix.label@example.com, you need to add an alias.
3. Set up spam aliases for persistent email getting to catchall that you don’t want.

I have a number of simple and wildcard host-names in my ADDITIONAL_SAN setting, e.g.
ADDITIONAL_SAN=hass.mydomain.tld,imap.*,smtp.*,docker.mydomain.tld,wine.mydomain.tld,stratus.mydomain.tld
ACME was getting certs fine.
I updated my Mailcow a week ago, and regularly since ; this pulled in the XMPP additions
Since then I needed new certs ans ACME failed to pull new certs with errors like:
acme-mailcow_1 | Verifying imap.mydomain.tld...
acme-mailcow_1 | Traceback (most recent call last):
acme-mailcow_1 | File "/usr/bin/acme-tiny", line 8, in <module>
acme-mailcow_1 | sys.exit(main())
acme-mailcow_1 | File "/usr/lib/python3.8/site-packages/acme_tiny.py", line 194, in main
acme-mailcow_1 | signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, log=LOGGER, CA=args.ca, disable_check=args.disable_check, directory_url=args.directory_url, contact=args.contact)
acme-mailcow_1 | File "/usr/lib/python3.8/site-packages/acme_tiny.py", line 149, in get_crt
acme-mailcow_1 | raise ValueError("Challenge did not pass for {0}: {1}".format(domain, authorization))
acme-mailcow_1 | ValueError: Challenge did not pass for imap.mydomain.tld: {'identifier': {'type': 'dns', 'value': 'imap.mydomain.tld'}, 'status': 'invalid', 'expires': '2021-02-23T19:55:39Z', 'challenges': [{'type': 'http-01', 'status': 'invalid', 'error': {'type': 'urn:ietf:params:acme:error:unauthorized', 'detail': 'Invalid response from http://imap.mydomain.tld/.well-known/acme-challenge/xEg4JcgSGfI4QBzEJ3BB99wJwKjk9QYZ7CHYY-AjGSU [86.20.75.195]: 404', 'status': 403}, 'url': 'https://acme-v02.api.letsencrypt.org/acme/chall-v3/10924494549/kLiurg', 'token': 'xEg4JcgSGfI4QBzEJ3BB99wJwKjk9QYZ7CHYY-AjGSU', 'validationRecord': [{'url': 'http://imap.mydomain.tld/.well-known/acme-challenge/xEg4JcgSGfI4QBzEJ3BB99wJwKjk9QYZ7CHYY-AjGSU', 'hostname': 'imap.mydomain.tld', 'port': '80', 'addressesResolved': ['86.20.75.195'], 'addressUsed': '86.20.75.195'}]}]}
acme-mailcow_1 | Sun Feb 21 05:54:27 GMT 2021 - Failed to obtain certificate /var/lib/acme/mailcw.mydomain.tld/cert.pem for domains 'mailcw.mydomain.tld autoconfig.mydomain.tld autoconfig.myotherdomain.tld autodiscover.mydomain.tld autodiscover.myotherdomain.tld imap.mydomain.tld''
Emergency workaround
I made ADDITIONAL_SAN a null string, and mailcow-acme got the basic certs ok - phew!
Current Workaround
After lots of trial and error (and messing with my DNS and network - just in case), I found I can get certs for additional SANs if I add explicit names to ADDITIONAL_SERVER_NAMES , e.g.
ADDITIONAL_SAN=hass.mydomain.tld,imap.mydomain.tld,smtp.mydomain.tld
ADDITIONAL_SERVER_NAMES=hass.mydomain.tld,imap.mydomain.tld,smtp.mydomain.tld

Does anyone know if it is now a requirement to add all additional sans to additional server names? What about wildcard SANs?

Happy to raise an issue in github, just wanted to check I’m not missing something first. Anyone got any thoughts?

I removed Outlook some time ago, so cannot test this for you. However, I remember there is a setting in Outlook to control how the Comma is treated in Outlook address fields. Perhaps you can try to check this setting. Perhaps it is ON and should be OFF?

I think the following explains it well, and says what what to do to test Mailcow’s RSpamd (!!on a non-production system!!).

GTUBE-like test patterns

Rspamd - rapid spam filtering system.

GTUBE-like test patterns

Rspamd is an advanced spam filtering system and email processing framework that allows evaluation of messages by a number of rules including regular expressions, statistical analysis and custom services such as URL black lists.

Hallo,

First you should check that your Ubuntu machine’s postfix is configured to send encrypted mail on port 587 with STARTTLS to Mailcow. You also need to authenticate with Mailcow using a good username and password.

A little off topic (just inb case it is useful), I use sSMTP instead of Postfix in the simple case where I am forwarding logs and notifications. This is easy to set up, and may be a good way for you to test the relaying. A working sSMTP configuration with Mailcow looks like this:

#
# Config file for sSMTP sendmail
#
# The person who gets all mail for userids < 1000
# Make this empty to disable rewriting.
root=postmaster

# The place where the mail goes. The actual machine name is required no
# MX records are consulted. Commonly mailhosts are named mail.domain.com
mailhub=wonderfulmailcow.mydomain.org:587

AuthUser=me@mydomain.tld
AuthPass=#MyWonderfulPassword#
UseTLS=YES
UseSTARTTLS=YES

# Where will the mail seem to come from?
rewriteDomain=mydomain.tld

# The full hostname
hostname=myhost.mydomain.tld

# Are users allowed to set their own From: address?
# YES - Allow the user to specify their own From: address
# NO - Use the system generated From: address
#FromLineOverride=YES

We make good use of shared email folders as well as personal ones. I like to use SoGo in which shared folders appear in the folder list as “Other Users” for me. There are two annoyances we see:

1. “Other Users” appears between “Sen…” and “Sho…” - so I assume “Other Users” is being sorted as though it were called “Shared…” You can see this in the picture below. This can confuse a user! Is this mis-ordering something that can be fixed in Mailcow (in Dovecot perhaps)? …or do I need to report it to Inverse as a SoGo issue?

2. My mailbox started life in 1993 and has many folders; it would be good if the virtual-folder containing the shared folders came at or close to the top. Could it be made in to a “Special” folder that appears at the top with “Inbox”, “Sent”, etc.? If not, perhaps a simple way would be to have it indexed properly and change the name to “Additional Users” so it is very close to the top of the list; is this practical?
   

Any ideas?

Fabulous! Mailcow updated and tested - works great

Vielen Dank!

Shadow - I can reassure you that Method A for using an external DNS can work. I used these instructions on day one of my evaluation of Mailcow over a year ago, and it has been running like that in production for nearly 9 months. FYI, I have unbound running on physical pfSense box at the edge of my network and just added three lines to the top of Mailcow’s unbound.conf in /opt/mailcow-dockerized/data/conf/unbound as shown in the picture below.

Considering your other issue as well, the experts in this, @diekuh and @pkernstock, are right: there seems to be a hiccough somewhere in your setup and it would take much more information for the community to help.

tbrummell - no problem, great to be able to share
diekuh - bug report raised: https://github.com/mailcow/mailcow-dockerized/issues/3833

• G

Hi diekuh,

Thanks for your reply. I should say that 192.168 isn’t a good test because there are no devices with that network, my network is 10.0.0.0/8, so testing something like “10.88” (with a dot) finds nothing, whereas “10 88” (with a space) finds lots of internal devices.

Will raise a bug report today.

– G

A number of unwanted servers are knocking on the Postfix door from 141.98.10.???
To investigate I tried to search in MailCow->[System Information]->[Configuration]->[Logs]->[Postfix]

Search term “141” -> Too many results (as expected)
Search term “141.98.10” -> No results (but I can see them in the full list)
Search term "141.98.10 -> No results
Search term “141 98 10” -> Perfect set of answers

Having a dot in the search term seems to break the search. Is this by design, or a defect in the search box? Do I miss some clever syntax?

I think it is most efficient to be able to paste an IP address in the search box and get good answers, but happy to adapt myself to a different syntax of there is a good reason.

Thanks