Mailcow logs viewer: A faster, cool way to monitor your emails

shlomi · 2025-12-25T18:47:39+00:00

Hi everyone, While mailcow is an amazing suite, I often found the built-in log viewing options a bit clunky when I needed to debug something quickly (its ev...

esackbauer

Does that modification survive a mailcow update?

Kevo

The only issue I’ve noticed is that unbound seems to not like the linked network being in use during update, so I bring down the mail log viewer before running update and then it doesn’t complain.

I’ve thought about just switching it over to ip, but it hasn’t bothered me enough to do it yet.

Angus_MacGyver

As far as I got it from timbers posting the example settings are:

resolver 127.0.0.11 valid=10s ipv6=off;

server {
listen 443 ssl;
listen [::]:443 ssl;
http2 on;
server_name maillogs.xyz.com;

ssl_certificate /etc/ssl/mail/cert.pem;
ssl_certificate_key /etc/ssl/mail/key.pem;

location / {
    set $upstream http://mailcow-logs-app:8080;
    proxy_pass $upstream;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

}

I’m not quite sure if this fits for me: I’m hosting mailcow on a Public-VPS @ netcup.
resolver 127.0.0.11 valid=10s ipv6=off; somehow seems strange for me.

Angus_MacGyver

Seems that I got it working!

Using the standard-template mentioned in the Docs with “reverse proxy configuration”:

server {
  ssl_certificate /etc/ssl/mail/cert.pem;
  ssl_certificate_key /etc/ssl/mail/key.pem;
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_prefer_server_ciphers on;
  ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
  ssl_ecdh_curve X25519:X448:secp384r1:secp256k1;
  ssl_session_cache shared:SSL:50m;
  ssl_session_timeout 1d;
  ssl_session_tickets off;
  index index.php index.html;
  client_max_body_size 0;
  root /web;
  include /etc/nginx/conf.d/listen_plain.active;
  include /etc/nginx/conf.d/listen_ssl.active;
  server_name logs.mailcow.email;
  server_tokens off;

  location ^~ /.well-known/acme-challenge/ {
    allow all;
    default_type "text/plain";
  }

  if ($scheme = http) {
    return 301 https://$host$request_uri;
  }

  location / {
    proxy_pass http://[IP-Adress]:8080/;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    client_max_body_size 0;
  }
}

I changed server_name to my desired domain for the Logs Viewer and proxy_pass to the IP-Adress and Port 8080 of my Server. Additionally I added the desired domain to ADDITIONAL_SAN= in mailcow.conf.

CK_beats

I have a suggestion for a new small feature, should you @shlomi happen to be making changes again:
An option in the “Quarantine” section to “learn as spam and delete” all selected items would be great.
Similar to the Mailcow admin interface.

Perhaps other users would appreciate this “button” as well.

Angus_MacGyver

CK_beats
I would also suggest / request some “search / filter”-functionality for that “Quarantine”-Section ;-)
For the suggested “ALL-Options” also the Option to just “delete”.

chrisXmz

I can still reproduce this issue with mailcow Logs Viewer 2.7.0 and TZ=Europe/Berlin.

The fix introduced in 2.7.0 does correctly set the application PostgreSQL session to UTC, but the Dashboard → Recent Activity timestamps are still two hours ahead in my setup during CEST.

Environment

mailcow Logs Viewer: 2.7.0
TZ: Europe/Berlin
Host local time: CEST / UTC+2

Container and Python time are correct:

Host local:       2026-08-19 15:13 CEST
Host UTC:         2026-08-19 13:13 UTC

datetime.now():    2026-08-19 15:13
datetime.utcnow(): 2026-08-19 13:13

The SQLAlchemy connection used by the application is also correctly pinned to UTC:

timezone       : UTC
now()          : 2026-08-19 13:13:28+00:00
localtimestamp : 2026-08-19 13:13:28

So the SET TIME ZONE 'UTC' fix from #19 is definitely active.

Reproducible example

For one message, PostgreSQL contained:

first_seen : 2026-08-19 16:35:11
last_seen  : 2026-08-19 14:36:30.167601
created_at : 2026-08-19 12:36:30.167867
updated_at : 2026-08-19 12:36:30.167868

At that time, the Dashboard displayed:

16:36:30

The correct local time was approximately:

14:36:30 CEST

Netfilter timestamps are displayed correctly. The problem only affects the Dashboard Recent Activity messages.

Current code

The current 2.7.0 code, and also the current main branch, still use last_seen in backend/app/routers/stats.py:

recent = db.query(MessageCorrelation).order_by(
    MessageCorrelation.last_seen.desc()
).limit(limit).all()

and:

"time": format_datetime_utc(msg.last_seen),

This means that a value such as:

14:36:30

is serialized as UTC and the browser then converts it to Europe/Berlin:

14:36:30Z
    -> +02:00
16:36:30 CEST

Working workaround

For testing, I changed only the Recent Activity endpoint from last_seen to created_at:

recent = db.query(MessageCorrelation).order_by(
    MessageCorrelation.created_at.desc()
).limit(limit).all()

and:

"time": format_datetime_utc(msg.created_at),

After restarting the container, this removes the +2 hour offset in the Dashboard.

For the example above:

created_at = 12:36 UTC
browser Europe/Berlin = 14:36 CEST

which matches the actual time.

I understand that created_at is probably not the ideal long-term timestamp because it represents when the Logs Viewer processed/created the correlation rather than necessarily the exact mail event time.

There was also a discussion in the mailcow community about using the Rspamd timestamp as a more reliable source-of-truth timestamp for messages:

https://community.mailcow.email/d/5704-mailcow-logs-viewer-a-faster-cool-way-to-monitor-your-emails?page=19

Could you please re-check #19 specifically for the /stats/recent-activity endpoint?

It looks like the PostgreSQL session timezone fix itself is working, but the Dashboard still uses a last_seen value which can result in the local timezone being applied a second time.

The local created_at change is only a workaround; an upstream solution using a consistently normalized event timestamp would obviously be preferable.

lthiry

Hello,
is there a way to access the log viewer with https ? I am accessing it throught http://xxx.com:8080 at the moment
Thanks

Kevo

You can set up a custom proxy site in nginx and let it proxy the site. Check the custom sites page under nginx in the docs. I might have needed to look at the advanced ssl page as well when I set mine up, but I don’t remember for sure. You will need to add the site name in the mailcow conf file under additional sni, IIRC, in order to get it to pull a cert for the additional site name. HTH

lthiry

Thanks, I did a reverse proxy thing, but I was looking for a more native solution.

« Previous Page