Why does Amazon SES throw that error when sending email?
For example, you have verified your domain example.com. Now, someone@yahoo.com sends an email to myaccount@example.com. Postfix gladly accepts it and because of the alias file, postfix will forward it to otheraccount@gmail.com.
The problem is, postfix uses someone@yahoo.com as envelope sender in the SMTP transaction. It's a desired and default behavior of postfix. The purpose is to not lose the sender information when GMAIL receives that email from someone@yahoo.com. Unfortunately Amazon SES only allows envelope sender domain as example.com.
Solution
From the thread mentioned by OP in comment, there are some solutions to alter the envelope sender so it will be passing the Amazon SES restriction. One possible solution is using sender_canonical_maps. By default postfix will rewrite both sender in envelope and header. With proper configuration of sender_canonical_classes, postfix will only rewrite the envelope one.
In /etc/postfix/main.cf, add
sender_canonical_maps = regexp:/etc/postfix/sender_canonical
sender_canonical_classes = envelope_sender
In /etc/postfix/sender_canonical, add
/.*/ mysenderaddress@example.com
The problem is your original sender is unknown. One method to obtain the original is with a prepend action of check_sender_access as suggested by Postfix author.
In /etc/postfix/main.cf, add
smtpd_data_restrictions = check_sender_access pcre:/etc/postfix/sender_access
In /etc/postfix/sender_access, add
/(.*)/ prepend X-Envelope-From: <$1>
Those settings will add X-Envelope-From header which will contain the original sender email address.
When this problem happens, where does the email end up? Where did it go?
By default, postfix will bounce this message to the original sender (Yahoo address). You can trace it by following mail.log after the rejection. Of course, some postfix setting could suppress the bounce message, or maybe Yahoo silently rejects it.
I see two solutions here.
(i did configuration like this many years ago)
google use many ip's as MX. You can define in transport map, that first mail is routed via gmail-smtp-in.l.google.com., and second via alt1.gmail-smtp-in.l.google.com. Then - using iptables and nat/POSTROUTING - nat connections to first google MX via first ip, and to second google MX via second ip.
(not tested, but should work)
ip used for outgoing mail is defined via smtp_bind_address.
you can define second (and next) smtp transport in master.cf like:
smtp-1 unix - - n - - smtp -o smtp_bind_address=firstip
smtp-2 unix - - n - - smtp -o smtp_bind_address=secondip
and then define in transport map something like:
person1@gmail.com smtp-1:
person2@gmail.com smtp-2:
you must specify using transportmap file in main.cf file:
transport_maps = hash:/etc/mail/transport
and run
postmap /etc/mail/transport
to create hash map of it.
Best Answer
Just to show that the suggestion feature when you enter a subject works, when I entered the subject for this question the first result was a link to Route mail in postfix to different relays based on subject. It's not what I was looking for, but it led me to look more closely at header_checks despite what is stated in the answer at the link in my question. A web search led me to How to filter mail with postfix header_checks, which was the answer I was looking for.
In my case this worked in /etc/postfix/header_checks:
I actually put a very rude message after "REJECT", but that's not appropriate to include here.
Here is the log entry for their most recent attempt:
The regex is case insensitive.
Other answers I found useful: