When I try to sign up I get an error “Failed to send magic link email” and looking in the log it shows an error.
I host the ghost blog at the subdomain blog.domain.de and want to send from ...@domain.de. I have added the “from” attribute to the config but it does not seem to be respected.
Error from container logs:
[2022-08-06 19:40:33] ERROR Failed to send email. Reason: Can't send mail - all recipients were rejected: 553 5.7.1 <noreply@blog.domain.de>: Sender address rejected: not owned by user noreply@domain.de.
Failed to send email. Reason: Can't send mail - all recipients were rejected: 553 5.7.1 <noreply@blog.domain.de>: Sender address rejected: not owned by user noreply@domain.de.
About the database, I am using the latest mariadb container.
Command output when I execute it inside of the container is: sh: 1: mail: not found
I also actually did not expected the command to work.
The DNS is set up with mx for @domain.de to my mailcow instance which works fine. I could set a mx record for @blog.domain.de and add a mailbox or alias, but I rather prefer it without.
And I still wonder why the “from” parameter is not being respected.
Your host can’t send mail, and the SMTP server is unreachable, so Ghost can’t send email.
Either use direct mail, and setup an MTA on the server, or make sure you can use the SMTP server on port 465, which is depreciated, so switch to 587 and STARTTLS.
Regarding MariaDB, this isn’t officially supported (nor is Docker for that matter), so you should migrate to MySQL 8 to avoid breaking changes in future.
My mail server can SSL port 465 and STARTTLS port 587. But I only found the secure option which I thought is the SSL option. Do I need to leave secure true and only port 587?
Anyways, from what I understood from the error message, noreply@blog.domain.de is rejected, which is how it should be. But why is it not trying noreply@domain.de like in the “from” argument of my configuration?
Inside of the docker container, the output again is: sh: 1: telnet-ssl: not found
But I am sure it can connect, because while configuring the mail conf part I did a typo which resulted to a connection issue. The issue from my point of view is, why is it still trying to send from the default noreply@blog.domain.de and not from noreply@domain.de like it should because of the overwrite param “from”.
I’m not familiar with using Ghost in Docker, but I understand that you shouldn’t edit production.json.conf directly, but pass environment variables instead.
Maybe this is the issue? However, unless you can confirm mail delivery from the host, I wouldn’t rule that out.
# telnet-ssl smtp.mal-noh.de
telnet: could not resolve smtp.mal-noh.de/telnet: Servname not supported for ai_socktype
I don’t know what ai_socktype is. But my server is reachable from ghost, otherwise my mail server would not respond “noreply@blog.domain.de rejected”.
I can use environment variables and I will later try that out when I am back home, but the mail username, password and everything is being used. It just does not care about the given “from” option.
I have opened a topic in “bugs”, which got closed by @Hannah as being a duplicate of this one. Hannah I apologize for posting duplicate issues. I was just trying to bring (what I believe is a bug) to the Ghost team’s attention. I never meant to be annoying. Sorry about that…
Given that my topic in bugs got closed, I assume that this is expected behavior? Yet, the fact that noreply@<domain> is used for subscriber signup emails is not documented anywhere. These docs suggest that setting the from field in the mail config would apply to all email sent from Ghost and that noreply@<domain> is simply the default if not supplied.
I guess that I’m missing something here? Any help or suggestions would be greatly appreciated. Thank you :)
This is unsurprising, since @aronmal’s issue is a misconfiguration, which is evident from the error messages, and output from the console, i.e., the mail server is unreachable.
If you believe there is a bug, you should demonstrate this with evidence, not a hunch.
From your post it is unclear what issue you have. Moreover, you haven’t shared anything about your hosting or email services, the error messages you’ve received etc.
If you still think you have the same issue, then post here, otherwise, a new thread is likely better.
@aronmal, you’ve not provided further updates. Have you followed up on the messages from Telnet? This could point to a permissions issue, e.g., /etc/services, since the hostname cannot be resolved, which is why the mail server is unreliable.
Thanks for your comment. It does seem to me too that @aronmal’s issue is indeed some sort of misconfiguration. This is also the reason why I created a separate thread from this one, as I believe that what I am running into is a bug. But as I said, this got closed as being a duplicate of this one, which is why I am replying under this thread now.
I explained what I am running into in detail in the post that was closed here.
If there is still information missing, I’d love to elaborate. Thank you so much.
The issue is that you opened a thread in #bugs, rather than #help:self-hosting. Moreover, your config.production.conf uses the format "'XXX' <XXX@XXX.com>" whereas "XXX@XXX.com" is all you need; Ghost will add the site name to the From field.
I’d try changing this first.
Incidently, I use Mailgun for transactional email, and all email is delivered with support@mydomain, which is set in config.production.conf.
How do you know this for sure? Did you check the mail server logs?
The messages you posted included:
ERROR Failed to send email. Reason: Can't send mail - all recipients were rejected...
telnet: could not resolve smtp.mal-noh.de/telnet: Servname not supported for ai_socktype
Both of these messages are on the client, i.e., it can’t communicate with the mail server. These words tell me something is wrong with your config: Failed to send email and could not resolve smtp.mal-noh.de.
I also asked you to test the server using mail, but you didn’t pursue this, simply because the binary isn’t installed on your system, which may also indicate that you haven’t set up an MTA.
I’m a community member, too, and trying to help, but all I can do is point you in the right direction.
As @mjw mentioned, try using port 587 instead. Port 465 shouldn’t really be used anymore. Also, turn the secure option off. As per docs, only use it if you really need it. It didn’t work for me when I tried using it and don’t see a reason so far why I’d need it. All my mail gets delivered fine (only Outlook tends to put them into spam but I’m not sure if secure would change that).
@aronmal Perhaps you are running into the same issue as me? Does your mail config, including the from field work when inviting a new staff member?
In my case, the from field is used here, but for the email that is sent to someone subscribing it is not. Here the default noreply@<domain> is used (as if the from field is not supplied), resulting in the mail server to reject it if this noreply@<domain> email address is not configured.
I did that, because I do believe this to be a bug. The issue I created in #bugs also includes 2 Github issues of other people running into the same thing.
The format I used in the from field is explicitly mentioned in the Ghost docs here.
I also want to emphasize again, that the from field is used when inviting a new staff member, but it is not when someone subscribes. Given that these are both transactional email, I would expect them to both use the from field.
08/16/2022, 09:24:18 AM info lost connection after RCPT from server.domain.de[censored_IP]
08/16/2022, 09:24:18 AM info NOQUEUE: reject: RCPT from server.domain.de[censored_IP]: 553 5.7.1 <noreply@blog.domain.de>: Sender address rejected: not owned by user noreply@domain.de; from=<noreply@blog.domain.de> to=<aron@domain.de> proto=ESMTP helo=<[127.0.0.1]>
08/16/2022, 09:24:18 AM info Anonymous TLS connection established from server.domain.de[censored_IP]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
08/16/2022, 09:24:18 AM info connect from server.domain.de[censored_IP]