On Thu, 13 Mar 2003, Kevin P. Fleming wrote:
> 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.
Yes, that was to bring it in line with the specification. It was doing
it as specified for appendfile and pipe, but not for lmtp and smtp. I
had received a bug report about this from somebody using the smtp
transport, for whom it mattered.
> 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.
This just goes to prove the old saying that one person's bug is another
person's facility. Sigh.
> So, I'm in a catch-22 here:
> 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@???".
Seems like NOT using local_part_prefix is called for, so that you don't
mess with the local part for RCPT. Then, I think, regular expressions
are your friend. Something like
${if match{$local_part}{\N^([^+]+)\+\N}{$1}{$local_part}}
should give you "user" or the full local part if there's no "+" in it.
You can use this in the lookup that validates the local part, and also
in setting authenticated_sender, can't you?
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
