I keep feeling rather uneasy at the original example Arkadiusz mentioned:
^test@$primary_hostname "$h_from:" Ffs
^test@$primary_hostname "<zupa@???>" Ffs
I thought that the replacement string should be an email address, not the
(entire) value of a "From:" header? For example if the message's "From:"
header is
From: Mike Brudenell <mike.brudenell@???>
then the *$h_from* variable contains the text
Mike Brudenell <mike.brudenell@???>
so rewriting an address and replacing it with this text would surely be
wrong? Wouldn't it give something like:
From: Mike Brudenell < Mike Brudenell <mike.brudenell@???>>
So the 'workaround' is actually correct: using ${address:$h_from:} to
extract just the address part from the From header's value?
If, of course, there *is* a "From:" header…!
When there is no "From:" header within the message then *$h_from* is empty,
so replacing a valid address with an empty string. The defensive test
within the 'workaround' presumably guards against this, I think, by
comparing the value against the empty string… It tests if the *$h_from* value
is not the empty string and goes ahead with the replacement, whereas if the
variable is empty then the 'fail' forces replacement in the first rule not
to happen so drops through to the second, fallback, rule.
If I've got those right, then Exim complaining about rewriting the address
to an empty or malformed string is actually rather helpful.
Cheers,
Mike B-)
On 14 July 2016 at 14:40, Arkadiusz Miśkiewicz <arekm@???> wrote:
> 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 )
>
> --
> ## 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/
>
--
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811
Web:
www.york.ac.uk/it-services
Disclaimer:
www.york.ac.uk/docs/disclaimer/email.htm
