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 "<zupa@???>" 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
> > "<zupa@???>" 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 )
