I’m trying to setup a GitLab Server but the current SMTP Configuration is not working. GitLab is able to communicate with the Mailserver (postfix and amavis on a different host), but amavis quarantines the emails due to a Missing Date Header. Does this need to be added manually in the GitLab Config? If so, how?
For debugging purposes, I would whitelist it so that it doesn’t quarantine the bad header for that particular email address, or just allow amavisd to do something else instead of quarantine, eg: mark subject as spam or something for emails with bad headers. Once you get the email delivered to your mailbox, check the headers there and see what it looks like. If the date field is in the headers, then that would suggest the format is fine.
I used to make anti-spam solutions with amavisd, generally it’s great, but it does generate these false-positives sometimes, even when the headers as you see here are correct. Amavisd unfortunately doesn’t always get it right. I always allowed amavisd to pass bad header emails, since it was just being picky, and flagging legitimate emails as spam.
We’ll try that. I’m just not sure as to why amavis would complain about a missing header. Especially the Date Header is one of the only required headers so I’d wonder why GitLab wouldn’t include it by default.
Also wouldn’t Postfix add the missing headers, so that I’d see them in the final email? So I don’t really know if the hader has been added by GitLab or by Postfix.
Postfix accepts the emails, it injects it into amavisd to scan it for spam/viruses, and then returns it back into postfix for delivery usually on port 10024 and 10025 (depending on your server config). Sometimes amavisd gets it wrong, but ideally whitelist it to bypass amavisd and then check the headers yourself. I basically let amavisd deliver emails that it thought had bad headers, and to be honest, legitimate emails can also get flagged incorrectly despite there not being that much wrong with them. But it’s up to you to choose how you deal with such messages. I much prefer a few spam emails getting through than legitimate emails being blocked incorrectly.
I’ve had plenty of problems since 10 - 15 years with amavisd marking emails as spam incorrectly. You may wish to look into rspamd instead, much better solution, and has a graphical web interface also and will learn emails also based on user-input as to what is spam, and what is legitimate (ham).
Okay, we’ve whitelisted the approriate gitlab Emails so that amavis will just pass them on. This kind of works. If I manually send an email using that sender address the mailserver will just send it.
However, gitlab won’t send anything. My Notify.Test_Email will return the same connection timeout error as it did before, but it does not appear as if the gitlab host actually connects to the mailserver since the maillogs are empty.
So you’ll need to check /etc/gitlab/gitlab.rb and make sure it’s configured properly. Because if you aren’t getting anything, then that means it’s not communicating with your mailserver properly due to incorrect settings.
The Config has not changed compared to the last time at which the gitlab host was still available to establish a connection.
But a bit of troubleshooting later reveals that something about the overall configuration was causing the issues, I’m just not yet sure what.
The Mailserver is in DMZ, while the gitlab host is not. Connecting to it using the internal IP worked at first but resulted in the amavis complaints. This is now not working anymore for some reason.
After inserting the Mailserver DMZ IP or rather its Hostname in the gitlab.rb everything works as expected. Mails are delivered immediately and amavis gives them a clean pass instead of complaining about a bad header.