On Thursday 14 of July 2016, Jeremy Harris wrote: > On 13/07/16 21:45, Arkadiusz Miśkiewicz wrote: > > Scenario: > > > > ^test@$primary_hostname "$h_from:" Ffs > > ^test@$primary_hostname "<[email protected]>" Ffs > > > > First rule in some cases will return "yielded unparseable address: > > empty address in address" which is fine and expected. > > > > But exim will stop rewritting in such case. It won't go to next rule > > (which I wanted to be a fallback rule). And that's unexpected. > > > > Docs ( > > http://www.exim.org/exim-html-current/doc/html/spec_html/ch-address_rewr > > iting.html ) don't seem to mention anything about such case, so I assumed > > next rewrite rule to be applied. > > > > > > For now I have a workaround for such problem: > > ^test@$primary_hostname "${if !eq {${address:$h_from:}}{} > > {${address:$h_from:}}fail }" Ffs ^test@$primary_hostname > > "<[email protected]>" Ffs > > When "fail" is returned then exim uses next rule. > > > > I wonder if that's (stopping when unparseable address occurs) a bug (and > > exim should try next rule) > > Exim has applied your first rule, which gave an empty result.
Resulting headers didn't end up with empty result, so it didn't apply it. > How > will any subsequent rule match the now-empty address? This is rather about: if no success -> stop rewritting vs if no success -> try next rule especially that there is no 'q' flag being used. > > or a feature (if feature then would be nice to see it documented) ? But ok, that may be desired result from exim people point of view, so the only missing thing is mentioning this in docs. -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
