==== REQUIRED BASIC INFO OF YOUR IREDMAIL SERVER ====
- iRedMail version (check /etc/iredmail-release): 1.7.4 MARIADB edition
- Deployed with iRedMail Easy or the downloadable installer?  The installer
- Linux/BSD distribution name and version: Debian Trixie
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): MySQL
- Web server (Apache or Nginx): Apache (but not even used)
- Manage mail accounts with iRedAdmin-Pro?  Nope.
- [IMPORTANT] Related original log or error message is required if you're experiencing an issue.
====

This is just super fun.  I do b'leev I've found a bug in the Amavis configuration.  We've been using iRedMail for a few years now, have SPF and DKIM and all that good stuff working, but are walking away from the previous distribution because reasons.  A brand new box was built with Trixie as the base, DKIM keys were just copied over into Amavis, and everything seemed good.  All the legacy devices  we've got sending mail were sending mail, and then while testing sending authenticated mail from a new internal host that I was spinning up, I started seeing signature failures.  WTF.

Mind you this program worked just fine from the old host and nine or ten others (going through the server running a much older version of iRedMail), and it's literally just a shell script so it's not like I could really have screwed up scp-ing it over, and it just hands the mail to sendmail (which I've been doing for like 20+ years) so... not fancy.  As I started digging into the issue I noticed something in the headers that caught my eye.  The "Date:" header showed -0000 as the timezone which won the stink-eye because the test program just calls $(date) which produces something not quite RFC-compliant ("Wed Apr  8 02:51:27 PM CDT 2026") but it's close enough for testing...or so I thought.  I thought there really should have been a CDT there or something to indicate the time zone wasn't UTC (because I hate converting those in my head).

It turns out that if Amavis doesn't like your date string, it will apparently replace it with a form that is RFC-compliant.  It didn't seem to care at all about my message ID that I forgot to wrap in angle-brackets and just passed that on through but whatevs...

Relevant information: h=message-id:subject:date:from:to;

The kicker is that this configuration apparently "corrects" the date string after it has generated the DKIM signature (which kinda breaks it).  Changing my date generator to using $(date +'%a, %d %b %Y %H:%M:%S %z') made the mails start passing DKIM checks.  That one change.  <<sigh>>

The other "clues" (blatantly fishing for Google with this on behalf of future admins) would be seeing Tests: [ALL_TRUSTED=-1,INVALID_DATE=0.432,INVALID_MSGID=1.167] showing up in the logs.  Again, it won't bother changing the message ID (most MTAs will just generate their own if you didn't specify one) to include <>'s, but it does replace your Date: string.  Heck, until today I didn't even know postfix or Amavis would bother altering the date string.