Not a whole lot of room for customization on that end at the moment. The current iteration of the stack adds an unusual amount of tech debt for each one, and that’s the kind of thing that I suspect would have unforeseen consequences requiring further adjustments/debt down the line as well.
To put that in context, the inbound configuration is largely managed by DirectAdmin as that’s part of the setup for what we did to get off the ground early. We basically outsourced the control panel aspect (MXroute is my baby, I’m not a front-end dev), and that comes with it having control over some basic services. The majority of our overrides for customization come from it’s default handling of exim/dovecot includes, which largely gives us more control over the outbound. That was my real focus from the beginning, perfecting outbound delivery as it is obviously an increasingly horrible nightmare year after year. The area most problematic for customization right now is exim.conf. It’s replaced on DA updates, which means we have to automate the running of their updates followed by reapplication of customizations, which could be damaging in any case that the customizations were actually vital. None of the includes in exim.conf would allow such inbound adjustment, requiring that we take it back to the DirectAdmin devs as a feature request for the most seamless implementation. For something like that, unlikely that it’d be a good idea for their whole customer base.
Of course, the goal was back-end development focused mostly on outbound delivery, and temporary outsourcing of front-end which included a lack of control over some inbound functionality (not really caring about the loss of some of that, because inbound isn’t typically a problematic affair, outbound is the real raid boss, anybody can run an inbound server and rarely do people need customization outside of spam filter settings). As we’ve grown, we continue to move closer to replacing the outsourced front-end aspects with in-house development, and we’re closer than ever, but today isn’t quite that day.
With a bit of excessive history out of the way…
Envelope from is there but it’s under the received header as you’ve probably noticed. It shouldn’t be too hard to parse with a script but it’s worth noting that there’s nothing stopping any prior relay from writing another one in the headers, we’re not going to cut it out. Similarly with any other header you rely on, you may want to consider that possibility as it may throw something for a loop.
SRS is pretty much all or nothing, it doesn’t know context, but it’s of extreme importance in the stack.