Transactional mail works partially: Magic links do not work, but stuff invites do work

Developer help Self-hosting
1

Hi everyone,

I have set up a 2 Ghost sites with docker compose. I am using Caddy as a reverse proxy for the SSL certificates. I configured AWS SES for transactional mails.
The configuration in docker-compose.yml file is identical for both sites (including the SES credentials).

For the first site, everything related to transactional mail works fantastic, for all kinds of transactional mail.

Unfortunately for the second site, whenever I want to sign up as a member, or for a newsletter, it fails with the error: Failed to send magic link
But when I create a staff, and ghost sends the invite, it works and the email gets sent via SES.

There are no error messages in the error log.

Here you can find the config for the ghost sites:

services:

  web1:
    image: ghost:latest
    container_name: web1
    restart: always

    environment:
      url: https://www.web1.com
      database__client: mysql
      database__connection__host: XXXXXXXXXX.eu-central-1.rds.amazonaws.com
      database__connection__user: XXXXXX
      database__connection__password: XXXXXXXX
      database__connection__database: web1
      mail__transport: SMTP
      mail__options__host: email-smtp.eu-central-1.amazonaws.com
      mail__options__auth__user: XXXXXXXXXX
      mail__options__auth__pass: XXXXXXXXXXXXXXX
      mail__options__port: 2465
      mail__options_Secure: true
      mail__options__service: SES
      mail__options__from: noreply@web1.com

    volumes:
      - /mnt/efs/ghost/web1:/var/lib/ghost/content
2

Just to clarify: newsletters don’t go out through transactional email. They go out only through mailgun, which needs separate configuration.

To fix actual transactional mail (member signups, staff invites), here are a couple things to investigate:

  1. Is there any error in the browser’s console log (f12 then click the console tab) when you attempt to sign up a new user?
  2. When you attempt to sign up a new user, is there anything at all in the Ghost log showing that the request is being received? You said no errors, but does the request actually get there?
  3. Is there anything at SES? If there are logs available there, look through them for evidence the request is getting there, and any diagnostic error messages.
3

Thanks for the reply.

Yeah, I just mean pure transactional mails, in the case of the newsletter, I meant the registration to receive the newsletter (where a confirmation mail gets sent).

No issues / error. I just get the banner “Failed to send magic link email”

There are no logs written (neither in error.log or .log) when I click on sign up… I am using the theme Casper for testing (if that is relevant)

There is no email rejected or bounced in SES.

4

Using SES myself, this sounds like an unverified identity. But that’s just a guess without the logs :smiley:

SES actually sends back pretty detailed error messages, so getting the logs is essential – especially if the messages don’t even reach SES.

How are you running the Docker compose stacks? Just with the CLI? In that case, run docker compose logs in the directory you have the file in and it will show you the Ghost logs.

5

Link your site? I’m betting on a console error.

6

Hi, great work on magicages! Keep it up und LG
The identity has been verified (otherwise, emails would not get sent when inviting stuff).
Also in SES it appears as verified.

bicitalks  | [2024-08-01 06:21:56] INFO "GET /" 200 82ms
bicitalks  | [2024-08-01 06:21:56] INFO "GET /members/api/member/" 204 1ms
bicitalks  | [2024-08-01 06:21:56] INFO "GET /members/api/comments/counts/?ids=XXXXXXX" 304 7ms
bicitalks  | [2024-08-01 06:21:56] INFO "GET /ghost/api/content/newsletters/?key=XXXXXXXXX&limit=all" 304 29ms
bicitalks  | [2024-08-01 06:21:56] INFO "GET /ghost/api/content/settings/?key=XXXXXXXX&limit=all" 304 17ms
bicitalks  | [2024-08-01 06:21:56] INFO "GET /ghost/api/content/tiers/?key=XXXXXXX&limit=all&include=monthly_price,yearly_price,benefits" 304 14ms

Unfortunately no POST request… but what if POST requests are being blocked at CloudFront level (CDN)? This would explain why it does not appear in the logs… I think I did not mention I was using it…

SOLUTION
The issue was in the behavior configured in CloudFront for the path /members* which was only allowing GET and HEAD requests… argggg. After allowing POST and invalidating the cache, it worked!

Thanks for leading me towards the solution @jannis and @Cathy_Sarisky !

2 Likes