postalserver
Feat: Add message token to return path
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 https://github.com/postalserver/postal/blob/6df963651d6d7d4613caebde090753123398da5f/app/lib/smtp_server/client.rb#L303-L340:
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 https://github.com/postalserver/postal/blob/6df963651d6d7d4613caebde090753123398da5f/lib/postal/message_db/message.rb#L496-L508:
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
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. The commit in this pull request just fulfills the "first half" of the process: adding individual bounce addresses. The "recognition" of bounces still relies on the X-Postal-MsgID header. This even could be supplemented by an additional search by the "tag" (as given in the new bounce-address after the "+" sign) - then, no "special" / "custom" processing of all "unmatched" bounces would be required. Optionally, this additional tag-based mail search could be enabled by some environmental / config setting.
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.