-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feat: Add message token to return path #2855
base: main
Are you sure you want to change the base?
Conversation
* Fix: allow build for jmdunsing version of postal Signed-off-by: jmdunsing <[email protected]> * Fix: Revise version number for jmdunsing version of postal Signed-off-by: jmdunsing <[email protected]> --------- Signed-off-by: jmdunsing <[email protected]>
Adding the message token to the return path would be beneficial for users to link bounces to email addresses when X-Postal-MsgID was not included in the bounce message's headers. Signed-off-by: jmdunsing <[email protected]>
Signed-off-by: jmdunsing <[email protected]>
I created an image in my fork of postal and emails are being sent correctly using the new method. |
This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
i like this |
What needs to be done to get this change incorporated? |
In our current setup (not using postal, but "exim"), we are using the exact same approach to have a "dedicated" bounce address per sent message. This way, we unambiguously can match incoming bounces to the corresponding outgoing emails without relying on still-included headers or message-ids. |
This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
This PR incorporates a minor change to the way the return path is generated to allow for additional bounce processing and message forwarding. Those using postal strictly as a transactional email solution should notice no difference in performance. Those who wish to be able to capture all hard bounces and those who use postal as a marketing solution will have another method besides the X-Postal-MsgID header to identify bounces and replies, since the message token will be included in the return path.
Background:
Some mail servers return a bounce but omit identifiable information and strip the X-Postal-MsgID header from the email, leaving postal users unable to prevent future hard bounces. This change will provide the ability for a subsequent coding solution to tie bounces and replies to emails to their original sender.
This design change is consistent with the current bounce design, which splits the domain path on "@" then subsequently on "+", and checks the uname to see if the server was a bounce (specifically line 328), see
postal/app/lib/smtp_server/client.rb
Lines 303 to 340 in 6df9636
These bounces will still not be identified by postal as bounces, and the incoming messages will still hardfail, because the current code still searches exclusively for the X-Postal-MsgID header
postal/lib/postal/message_db/message.rb
Lines 496 to 508 in 6df9636