Return-Path header via local forwarder/alias

#1

I’m doing some testing before setting up a ticketing system (BestPractical’s RT). I’m planning to use a single mailbox for all mail to/from RT and configure the individual queue addresses as forwarders. The forwarders are all for addresses on the same domain as the mailbox address. My account is on Shadow, which is a DirectAdmin-based server.

First off, thanks for adding the Envelope-to header. That makes this kind of setup much easier. Many mail hosts don’t provide an equivalent and you end up having to try to extract the envelope recipient address from the Received headers or guess it from To and Cc.

Unfortunately it looks like the value of the Return-path header is an SRS address even for mail delivered via a forwarder beteween addresses on the same domain. For example:

Return-path: <SRS0=5MxdcK=IV=example.net=sender@example.com>

That makes it difficult for me to extract the original envelope sender on ingest to RT. I can reverse the SRS transformation, but that requires custom code, which I would prefer to avoid.

Is there a way to configure a local alias that doesn’t perform SRS rewriting on the Return-Path address?

If not, would it be possible for you to add an e.g. Envelope-from header with the original envelope sender address?

#2

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.