[Exim] Exim 4.14 ChangeLog item #90: local part prefixes/suf…

Item #90 in the Exim 4.14 ChangeLog says that Exim now strips prefixes/suffixes
that were found during routing so that they are no longer part of $local_part
when the delivery via SMTP or LMTP happens.

This is a problem for me: my Cyrus system has "local_part_suffix = +*" and
"local_part_suffix_optional" on the router that decides whether the local part
is valid or not, because the Cyrus userlist needs to be searched that way.
However, this means that when the delivery to Cyrus actually happens, the suffix
is gone and the message is not delivered into the subfolder it was intended for.

I can make up a combination of redirect and accept routers to put the suffix
back on after doing the lookup, but that causes another problem: I'm using LMTP
AUTH to deliver to Cyrus, which uses the new authenticated_sender option on the
SMTP transport. However, at this point, $local_part is now the full local part
again, and that is not a valid username.

So, I'm in a catch-22 here: if I want to validate the username part of the local
part (sans suffix), the suffix won't be there when the actual delivery happens.
If I don't do a lookup ahead of time, I can't verify recipient addresses without
doing an LTMP callforward into Cyrus. I can't do a callforward because the
callout code doesn't support AUTH, and Cyrus' LMTP daemon (and probably most
others) won't accept MAIL FROM:<> unless the connection is AUTH'd. Finally, if I
don't strip the suffix during routing at all, Exim will try to send the entire
local part (including suffix) as the AUTH= identity during the LMTP
conversation, and that won't work because it still has the suffix included.

Philip, got any wonderful ideas? Basically, here's what I need to accomplish:

Message comes in addressed to user+folder@???.
I need to lookup "user" in the Cyrus user list before I will accept the address
as being valid.
If the message is accepted for delivery, the AUTH= token that gets sent during
the LMTP conversation needs to be "user".
The RCPT TO: address sent during the LMTP conversation needs to be "user+folder"
or "user+folder@???".

Alternatively (and I've looked at the code so I know this is not a simple
solution), if the callout code supported AUTH, I could use this sequence:

Message comes in address to user+folder@???.
Callforward to Cyrus LMTP tests "user+folder@???" and succeeds, so the
address is valid.
Again, the AUTH= token during LMTP delivery would have to be "user", but I may
be able to accomplish that with some magic string manipulation when I set
authenticated_sender.
Again, the RCPT TO: address during LMTP delivery would need to be "user+folder".

I am going to try to figure out how to chop off the +folder stuff when I set
authenticated_sender, and that may get me past the current problem. But it's not
a pretty combination of routers that got me there :-)