Relay with AWS SES works partially

[christoph-kluge]

Hello everybody,

for a norrmal mailbox the relayhost works but somehow it does not work when setting up forwarders. I have 3 Scenarios which I am testing right now:

a) [Mailbox] Send a norrmal mail - works and send through SES

This works flawlessly. I can send E-Mails, I see they are sent through SES, they are not in spam. Everything is fine 🥇

b) [Mailbox] Setup E-Mail Forwarding inside a Mailbox - does not work

As soon as I setup an E-Mail-Forwarding on this mailbox then the forwading gets bounced by AWS SES already.

Example:

Mailbox: [email protected] forwards to [email protected].
Now I took a different account on gmail [email protected] and send a mail to [email protected].

<[email protected]>: host
email-smtp.eu-west-1.amazonaws.com[52.48.248.62] said: 554 Message
rejected: Email address is not verified. The following identities failed
the check in region EU-WEST-1: Christoph Kluge <[email protected]> (in
reply to end of DATA command)

If course [email protected] is not verified in SES because I don't know who will send mails to my mailbox. Perhaps I'm missing some configuration here so would really love to hear about some hints. In the past I discovered this also with ISPConfig and did not found a solution for it. So it's pretty obvious that I'm missing something here.

I remember that I read some posts/articles saying that the From-Header needs to be rewritten to the mailbox-address and a proper Reply-To header should be appended. To be honest.. this did sound somehow like a hack.

c) [Forwading] No Mailbox - Just an Alias/forwarder - mail gets bounced by gmail

I did setup an Alias from [email protected] to [email protected]. The forward itself works flawlessly but it is not relayed through SES so it gets bounced by GoogleMail because I just have EC2 public ip. Anyways this public ip should not be relevant because it should go through SES, right?

<[email protected]> (expanded from <[email protected]>): host
    aspmx.l.google.com[74.125.133.26] said: 550-5.7.1 [x.x.x.x      18]
    Our system has detected that this message is 550-5.7.1 likely suspicious
    due to the very low reputation of the sending IP 550-5.7.1 address. To best
    protect our users from spam, the message has been 550-5.7.1 blocked. Please
    visit 550 5.7.1  https://support.google.com/mail/answer/188131 for more
    information. r13si181618wrl.294 - gsmtp (in reply to end of DATA command)

[andryyy]

Hi, can you show us how you setup the relay?

[christoph-kluge]

Hi @andryyy, sure! Thank you for your support. I have attached some screenshots. In case you need database entries or some other screens - please let me know.

Relay

Domain

Mailbox

Forward

[christoph-kluge]

Hi @andryyy, where you able to reproduce this behavior? Do you need more details from my side?

After checking this issue again I realized that b) and c) are separate issues? Should I split them?

TL;DR I see those issues (unless I'm have a configuration error)

b) Rewrite the headers in smart way for mailbox forwarders
c) Aliases/Forwarders are not going through a configured relay

I guess I will start some deeper debugging EOW or beginning of next week 👍

[andryyy]

No, and I am not working on it. PRs are welcome.

You might be able to change the forwarded mail with sieve_redirect_envelope_from, but it is already set to recipient. I don't see why it would forward from another address. Perhaps AWS also reads the "To" header, I don't know.

If you find a solution for your problem, feel free to explain it in the docs or create a PR. :)

[andryyy]

Ah, you can also try a sieve rule like described in https://blog.sys4.de/email-forward-mit-sieve-ohne-spf-dmarc-und-dkim-konflikte-de.html

require ["fileinto", "editheader", "variables", "regex", "envelope"];
if address "From" "MAILER-DAEMON@mailcow_hostname" {
fileinto "INBOX"; stop; }
if true {
 deleteheader "Reply-To";
 if envelope :matches "From" "*" {
 addheader "Reply-To" "${1}";
 deleteheader "From";
 deleteheader "To";
 deleteheader "DKIM-Signature";
 deleteheader "DomainKey-Signature";
 deleteheader "X-DKIM";
 deleteheader "X-DomainKeys";
 addheader "From" "[email protected]";
 addheader "To" "[email protected]";
 redirect "[email protected]";
}
}

I really think it is the To field.

[christoph-kluge]

Hi @andryyy, this looks promising! I test this during this/next week and will update my both threads and probably contribute to the documentation :-)

[tissieres]

Hi @christoph-kluge, were you able to fix this issue? I've got the same problem after updating mailcow recently.

[andryyy]

No update changed that behavior.

[tissieres]

I inspected the headers of two emails in the same context as b) in the first message above. I'll use the same example:

Mailbox: [email protected] forwards to [email protected].
[email protected] send a mail to [email protected]

Before the update:

Return-Path: [email protected]
X-Sieve: Pigeonhole Sieve 0.5.5 (2483b085)
X-Sieve-Redirected-From: [email protected]
To: [email protected]
From: [email protected]

After the update:

Return-Path: [email protected]
X-Sieve: Pigeonhole Sieve 0.5.8 (b7b03ba2)
X-Sieve-Redirected-From: [email protected]
To: [email protected]
From: [email protected]

The error message I received from SES:

<[email protected]>: host email-smtp.eu-west-1.amazonaws.com[52.48.248.62]
    said: 554 Message rejected: Email address is not verified. The following
    identities failed the check in region EU-WEST-1: Friend
    <[email protected]> (in reply to end of DATA command)

[andryyy]

Ah, you didn't update in a longer time then, I think?

You can try to set sieve_redirect_envelope_from = sender in dovecot.conf (it exists and is set to rcpt for a reason) and restart Dovecot.

[tissieres]

Yep @andryyy you were correct in thinking I did not update for a long time :-)

Your suggestion fixed my problem. Thanks!

[andryyy]

That's cool. :) Thanks for confirming it!

[christoph-kluge]

Hi @tissieres, nope I didn't fixed it because I did not investigate further. I went down with a different implementation for my use case.

For now I'm using SES directly as MX and configured a lambda which acts as an forwarder - because I don't want to store emails at all. I am using mailcow as an smtp-only mailserver now, probably a bit overkill but ok. The configurable sender transport through SES works here perfectly.

Maybe some followups on my gathered knowledge so far:

Case b) might be solved with the implementation of SRS (#2418). To be honest I'm not sure if SES supports SRS (AWS Forum) now. I'm partially working on a lambda implementation when SES is configured as MX to see if SRS is working there. I hope that I can share some spare time for it during the next 4 weeks. If I will find something interessting I will share my insights.

Case c) this is indeed interesting because aliases are not routed through the configured sender transports and sent directly from the mailcow. This might be correct behavior and might be the reason why SES does not support it. I'm guess (with my little understanding of SRS) that SRS got implemented excactly for this reason to support mailfowraders. The receiving server will instead check check the original sender headers like spf/dkim/dmarc etc rather than my hosts IP address.

Please take into account that I'm not an email expert. I have a basic understanding of this topic but it's really basic. I'm just sharing my thoughts here of the thinhs that I've discovered so far.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[mattmalec]

I'm also having this issue - sending emails via the SES relay directly from SOGo works flawlessly, but receiving emails is not working nor is sending to an alias (i.e. all emails going to [email protected] to go [email protected] are not routed through the relay)

[andryyy]

But receiving is not related.

[mattmalec]

Alright, regardless, I'm still having the issue with case C

c) Aliases/Forwarders are not going through a configured relay

I use a recipient map so all emails coming into Mailcow are forwarded to my Gmail. They are not forwarding through the relay.

[andryyy]

Ask in one of the support channels, someone might be able to help.

A global relayhost in main.cf/extra.cf will probably help. :)

[mattmalec]

I'm not too familiar with that. I thought Mailcow took care of that?

[christoph-kluge]

@mattmalec I was not able to setup this configuration as well.

I thought Mailcow took care of that?

It seems that Alias-Entries and Mailbox-Forwardings are simply not routed through the configured transport. I've stopped digging further into it to make it work.

so all emails coming into Mailcow are forwarded to my Gmail

If this is the only use-case for you and you're little bit familiar with AWS then I would suggest arithmetric/aws-lambda-ses-forwarder as a small AWS lambda. I went the same way. It works pretty easily and saves you some headache.