As of version 4.94 of exim, srs-native is now available in addition to the srs_alt implementation. The SRS implementation via srs_alt is described here: https://github.com/Exim/exim/wiki/SRS And frankly, whilst the documentation seems good, it also happens to not function properly (it rewrites for local deliveries but not remote - or at least, I couldn't get it working). The configuration and implementation here in my opinion is fairly clean and makes a lot of sense, the only issue is that the srs_rewrite property gets lost after the redirect router before the eventual remote (manualroute / dnslookup) transport (the rewritten address passes through another router). It is much simpler to configure though, and I really like the way this is supposed to work. Then, from the first link from there one can find this: https://git.exim.org/exim.git/commitdiff/7ef88aa0c4c0608ee54ed2ff90b4b34c518d9bb5 Which is a more flexible implementation, but does have a few drawbacks: 1. $original_domain isn't available in all cases. Need a max_recipients somewhere I can't recall at the moment (suspect transport since $original_domain would be available if there is a single parent address ... or at least, single parent forwarding to a single recipient ... not sure what would happen with single original address forwarded to multiple destinations). 2. Only supports a single secret. This is not an issue for the forward case, but makes things tricky for the return case if/when you rotate keys (let's say validity period is 30 days, then for 30 days after rotating a key the previous key still needs to function). 3. No support for database backing that I can see (where a random key gets put into the SRS address, so the original return path isn't deducible). This isn't a concern for us but others may care about this. One could generate the DB kind of mechanism using errors_to in this case probably, but coding the validators etc for that could get more interesting than I'd care to aim for right now. Sorry for the essay here, just figured it might be helpful to have some form of write-up to direct people at WHY there are two SRS implementations. Of course there are other ways to achieve the same as well as per the first link that references a few alternative options. Reproducible: Always
Thanks for this, I think the best way forward here is: 1. keep USE=srs 2. for now, add USE=srs-native (requires srs to do anything) 3. decide whether or not we should make srs-native default (e.g. +srs-native) 4. when srs_alt is removed, drop srs-native flag (but keep srs)
Hi Fabian, Sorry, only saw your comment after making the push for the PR. (In reply to Fabian Groffen from comment #1) > Thanks for this, I think the best way forward here is: > > 1. keep USE=srs I did update but can revert. My gut tells me that we should rather rename it at this point. Or another ideal would be to keep it but have that depend on setting at least one of the other two srs-* USE flags, so that it'll block users that currently have USE=srs from upgrading without taking explicit action. USE=srs will then (for the time being, until it gets dropped) only be used in REQUIRED_USE="srs? ( || ( srs-alt srs-native ) )" style. > 2. for now, add USE=srs-native (requires srs to do anything) Does it? There doesn't (codewise) that I can find, and I independently compiled with EXPERIMENTAL_SRS_NATIVE now, without EXPERIMENTAL_SRS ... and the required functions are exposed in the exim binary (whether they're functional is my next test). For srs-native we don't even require libsrs_alt. > 3. decide whether or not we should make srs-native default (e.g. +srs-native) > 4. when srs_alt is removed, drop srs-native flag (but keep srs) So this is where things get confusing - the two implementations are completely independent. If we later drop USE=srs, and rename srs-native to srs that's going to catch people off guard and break configurations. Agreed, srs-native should almost be the default ... but not everybody will have that configured (even if they should). If anything, we may just decide to enable it unconditionally since there is no effect unless you're using srs_encode or inbound_srs functions in your configuration, and the code is fairly small. Funny enough, you can have both implementations active at the same time in any case (at least at a code level, but they'll probably interfere or do funny things if you *use* both at a configuration level and aren't careful). Anyway, now to go figure out how to do that *IFF* the source domain isn't in +local_domains, and the sender domain has SPF published :). And how to determine a sensible "from" domain for SRS ... Will revert once you confirm what your final decision is w.r.t. naming of the USE flags. I don't think we should unconditionally enable srs-native whilst it's still experimental, but that's also an option. Kind Regards, Jaco
this is now in 4.94-r3
