Postfix, hide real sender?

Question

Debian

We have done the first stage, everything works:
1. We added the X-UserID service header and wrote some sender identifier into it.
2. In the service headers, the real e-mail of the sender [email protected] was replaced with the e-mail of the sales department [email protected]

At the second stage, it is required: when receiving a response from the client using the X-UserID service header, find the real e-mail [email protected] kontora.ru and forward the letter to this e-mail.
The problem is that the X-UserID does not get into the email when replying to it. And, as a consequence, it is impossible to determine the recipient's e-mail ([email protected]).

In my opinion, when replying to a letter, only the subject of the letter is saved (and then the user can correct it when answering).
Therefore, you can consider this option:
1. The user [email protected] sends an email to the client with the subject "Offer".
2. When sending a letter, Postfix adds the sender's ID ([email protected]) to the subject line, for example "Commercial offer [ID=12345]" and replaces [email protected] with [email protected] in the letter.
3. The client responds to the letter. At the same time, the mail client will add the "Re:" prefix to the subject of the letter and the subject will be: "Re: Commercial offer [ID=12345]"
4. Upon receipt of this letter, Postfix will parse the subject and find the employee ID, find his e-mail by ID ([email protected]) and send a letter to this e-mail.
This option will suit us with all its shortcomings.

Question: how to implement adding a user ID to a topic?
If done with header_checks, the sender's e-mail is only known when the "From" header is processed.
And I need to know the sender's e-mail when the "Subject" header is processed, but at that moment it is unknown.
Maybe header_checks is not suitable for this task?
Maybe there is another way? For example, write some script in some language that would process a specific letter and this script could be included in Postfix in the message processing chain?

Answer 1

Of course you can.
But such a letter will be cut down by the nearest spam protector.
Therefore, it will work within your mail server (for example, send service mailings from a non-existent user), but outwardly such letters will be cut at all mail nodes with a 99% probability.

Answer 2

Spoofing mail headers is an extremely bad idea. Not to mention that the response will also go to [email protected], because the SMTP protocol does not provide any header protection. That is, of course, you can delve into the brains of the postfix and organize something like "mail NAT", when the server "remembers" that the letter with the X-Zhopa: AAAA header actually sent [email protected], the letter with the X-Zhopa header: BBBB sent [email protected] and changes the header back when received - but I'm afraid you'll have to write it yourself :)
This is not counting the fact that usually offices that have correspondence from one address can be counted as sharashkins.

Answer 3

Official postfix doc www.postfix.org/ADDRESS_REWRITING_README.html
You need the section "Relocated users table" and below, everything is extremely simple there.

Answer 4

See ADDRESS_REWRITING_README , in particular Canonical address mapping.
This will be an easily implemented and correct replacement for [email protected] → [email protected]and, [email protected] → [email protected]respectively.

the recipient sees that the letter came from [email protected] ... the recipient responds to this letter, then it should come from [email protected]

But here it is more difficult. The conditional header X-Real-Sender-IDin the body of the email you send will not get into the response sent by the recipient of such a letter. Accordingly, it does not make much sense. In principle, you can adapt the header for these purposes References, but you still have to write your own proxy for incoming processing.
The address to which the letter will be sent when the "Reply" button is clicked is set by the header Reply-To. But even here you need to understand that you cannot prevent the recipient from clicking on the address in the "From" field and preparing a response to this address, or specify [email protected] in the "To" field in any other way.
So your idea obviously contains fatal flaws and goes beyond the responsibilities of the MTA. To solve it, for good, it is necessary in other ways. For example, if this is a support service, then a specialized system (Jira, YouTrack, etc.) should be responsible for receiving and sending letters.