I keep feeling rather uneasy at the original example Arkadiusz mentioned: ^test@$primary_hostname "$h_from:" Ffs ^test@$primary_hostname "<[email protected]>" 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 <[email protected]> then the *$h_from* variable contains the text Mike Brudenell <[email protected]> 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 <[email protected]>> 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 <[email protected]> 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 "<[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/ > -- 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 -- ## 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/
