Docker Mailserver
Emails from gmail to an alias of another gmail account bounce #4356
Replies: 4 comments 11 replies
-
|
Case 2 errors are quite clear about DKIM DMARC and SPF failing. As they should since you're trying to send mail as if you are authorized to do so with I'm not sure why case 3 would work, are you using Gmail as an authenticated relay? (did you configure for Gmail as per our docs?) That should allow you to send on behalf of the gmail account (personal account, or multiple when a workspace), otherwise gmail should refuse anyone pretending to be gmail as the sender when mail arrives on their servers at port 25.
Did you create a DMS account (
I think in the forwarding of mail sense, when you are sending from gmail as the client it may allow this kind of relay, but it shouldn't if you sent a mail from DMS with Perhaps using aliases to forward mail is behaving differently in some way, I only know of Postfix resolving the alias to the actual recipient to deliver the mail to, where mail arrives to DMS at a domain you own and potentially resolving it to one you do not own (to permit relaying it, which is normally forbidden for mail arriving on port 25). Aliases also work as a sender address, in that they resolve to their target too IIRC, so sending mail from The logs mention
Case 2 also has this error, which then follows with Postfix relaying a bounce mail from Gmail with ( Case 3 has you flip this around where you send with The quoted error for When mail arrives for a recipient Postfix will ask Dovecot if the address has exceeded it's allowed storage quota and this happens before any alias is resolved. We have a workaround in place for non-external aliases, where we create dummy accounts in Dovecot that point to the alias recipient address (actual mailbox account), and this allows Postfix to correctly verify the quota status, but in this case you have an alias to an external mail domain ( I can't recall if the This is a lot of guess work on my part.. I'm pretty sure you'll find with the The sender address when relaying mail through DMS via the alias address is different AFAIK, but I'm not familiar enough with that feature to explain why. Please ensure that |
Beta Was this translation helpful? Give feedback.
-
That's correct.
I can't say because GMail never receives the email otherwise and this softfail is added by GMail. |
Beta Was this translation helpful? Give feedback.
-
Ignore the alias recipient for now. Just send mail from If the forwarding feature via aliases isn't actually doing anything different to regular mail sending, and only allowing you to relay incoming mail via port 25, then you really shouldn't be having a difference between the two clients. Something must differ in their mail content for one to bypass requiring your DMS server to be authorized to send the mail from Ignore
How are you sending mail via Thunderbird?
I just responded to another users issue where they made this distinction between Thunderbird and MS, but they had customized Postfix via |
Beta Was this translation helpful? Give feedback.
-
|
@polarathene here's a redacted source for mail from thunderbird desktop gmail address to DMS hosted inbox |
Beta Was this translation helpful? Give feedback.
-
|
@polarathene and here's source from a send from GMail web client to the same DMS inbox. |
Beta Was this translation helpful? Give feedback.
-
|
There doesn't appear to be anything that stands out between the two samples. The Gmail one has an I also noticed the Thunderbird one has this: which is related to the system you're sending the mail from going through the Gmail relay AFAIK? Other than that there is the You did say you sent to the same address, but the two samples provided differ by I was kind of expecting ARC headers to be present in at least one of those samples, so I'm at a loss for any difference between the two clients. You said the Thunderbird client was successful with the alias relay/forwarding, could you inspect that raw mail and see if it differs at all? |
Beta Was this translation helpful? Give feedback.
-
|
@polarathene or anyone else: is there a better way to relay incoming email from one or more addresses to a gmail address? Should I not be creating an alias? I don't intend to relay all mail through gmail smtp, I simply wish to redirect incoming mail to some gmail addresses as a destination. Are there env variables I should dig into? At the mention of envelopes above, I'm trying this env change |
Beta Was this translation helpful? Give feedback.
-
We do have relay support that is sender address specific (see our docs on the topic), but in your case you want to focus on the recipient. It's been a while since I looked at relay support, I think that was possible but not something DMS provides support for out of the box. There are other features supported by Postfix like For reference: This discussion comment of mine cites various past reports of users wanting to forward to gmail via alias, although they had different issues/use-cases. My understanding was the alias to external address for forwarding has been working well for many users, but as you've discovered perhaps that is dependent upon a mail client or the third-party mail service 🤷♂️ Regarding the SRS mention (also see our SRS ENV docs), I do remember this feature is intended to workaround such a problem by adjusting the sender address that would be checked to one from DMS so that it can be authorized to send the mail. That rewritten sender address would contain information for DMS to relay the mail back to the original sender address when DMS receives a bounce mail IIRC, and on a mail client the original sender address should appear but the envelope sender address (normally not shown in the client by default) should have the modified SRS address. This is something you'd notice with spam/phishing mails that pretend to be sent from a reputable service. We have this FAQ entry, you'll need to set I do know that PostSRSd has a v2 release, but we're still stuck on v1. I am not sure what the status of the feature is like in DMS today, but we do have some basic tests related to it which are passing. It will likely solve your issue 👍 |
Beta Was this translation helpful? Give feedback.
-
|
FWIW, after reading the discussion of use cases you linked to and manually forcing the inbox + alias, the |
Beta Was this translation helpful? Give feedback.
-
Yes, that does work but so would setting
I need to understand what differs between Thunderbird and Gmail clients when they deliver mail to DMS to assist you there. You should be able to get this working regardless via PostSRSd, we just lack good docs beyond what I linked and explained. I just looked over our tests and it seems we lack proper coverage on the PostSRSd feature: docker-mailserver/test/tests/serial/tests.bats Lines 127 to 145 in 83bfe72 docker-mailserver/test/tests/parallel/set3/mta/smtp_delivery.bats Lines 28 to 34 in 83bfe72 docker-mailserver/test/tests/parallel/set3/mta/smtp_delivery.bats Lines 245 to 247 in 83bfe72 You can try to get that working, or perhaps see how alternatives to DMS handle it. Possible solution - ARCOne other option might be ARC?: https://stalw.art/docs/smtp/authentication/arc When you inspect the mail content delivered from each client, there may be ARC headers involved which AFAIK is a modern solution for the mail forwarding which may allow this to work without the PostSRSd workaround. We had an issue requesting ARC support recently: #3759 That issue cites another one reported about DMS with forwarding mail and the exact same Gmail error you've shown. This appears to be a reasonably recent issue/change, so perhaps it worked fine with Gmail until this point. If so, I will hazard a guess that Thunderbird works if it has no ARC header involved, and when sending from Gmail as the client it instead adds these, so that when the mail arrives back to Gmail to deliver to another From the linked issue:
The end of this comment also describes the behaviour well with DMS forwarding vs sending due to difference in sender address. It does not seem that we have any official ARC support built-in, but I do see that we had these docs added with instructions for enabling it with rspamd? So you could try giving that a go? |
Beta Was this translation helpful? Give feedback.
-
|
From your Case 2 logs with
That Gmail bounce mail message logged directs you to their docs about requirements for sender addresses, which has apparently been in place since Feb 2024. There is a requirement for ARC when forwarding mail: Your rDNS / PTR check is valid since the IP from DMS should match the IP that the PTR record resolves back to, despite the DNS name differing from the one assigned to DMS (non-issue). Additional Gmail docs links: Given that it's trying to verify SPF for the sender gmail address, you likely need ARC signing in place like I pointed out earlier. You already have Rspamd setup, so this should be as simple as adding a file at Adjust the values to valid ones for your config, it should be similar to the DKIM rspamd config. One other consideration is that I have noticed DMS v14 has Rspamd 3.8.4, but newer releases have had some bug fixes regarding ARC, so if this still does not work try with the DMS |
Beta Was this translation helpful? Give feedback.
-
|
@curiousercreative DMS v15 is now out. Did you manage to resolve this? Did configuring Rspamd with ARC help? |
Beta Was this translation helpful? Give feedback.
-
I've created a few aliases for gmail accounts before and not noticed this problem, so perhaps related to DKIM for new domains, hard to verify but also not all messages fail to forward. I've observed three result cases to describe further. In all cases, DMS appears to function the same (at least it relays a message to GMail), but GMail does not always accept (depending on sender it appears). To start, we need some DMS managed aliases
We also need at least one other mock gmail account: [email protected]
Case 1: sender is not gmail account, delivery succeeds (every time I've observed)
When the sender is another DMS mailbox or any other non-Gmail sender, the delivery seems to always succeed. For example, [email protected] as sender will deliver as expected.
Case 2: sender is gmail account, delivery fails (every time I've observed)
When the sender is some specific Gmail account, the delivery seems to always bounce with logs similar to
Case 3: sender is gmail account, delivery succeeds
With another specific gmail account, delivery seems to always succeed with logs similar to:
Beta Was this translation helpful? Give feedback.
All reactions