On 18/02/2019 05:13, Jasen Betts via Exim-users wrote:
> I have submitted a patch:
Thanks.
> I'm not sure if I should be free()ing "t" in that code - the old code
> wasn't. I guess exim will clean that up automatically.
It's correct to not do so.
--
Cheers,
Jeremy
--
## List details at
On 2019-02-15, Jasen Betts via Exim-users wrote:
> On 2019-02-14, Jeremy Harris via Exim-users wrote:
>> Summary:
>>
>> On 13/02/2019 05:41, Jasen Betts via Exim-users wrote:
>>> Should it be doing that?
>> They should be stripped.
>>
>>> (I could write a patch if this is a bug)
>>
>> That
On 2019-02-14, Jeremy Harris via Exim-users wrote:
> Summary:
>
> On 13/02/2019 05:41, Jasen Betts via Exim-users wrote:
>> Should it be doing that?
> They should be stripped.
>
>> (I could write a patch if this is a bug)
>
> That would be very useful.
I'll also have a look at the code behind
Summary:
On 13/02/2019 05:41, Jasen Betts via Exim-users wrote:
> Should it be doing that?
They should be stripped.
> (I could write a patch if this is a bug)
That would be very useful.
> Is there some other method for that?
Ugly, but... you could take them out with ${sg }.
It's probably
>
> But you're not dealing with a From: header. You're only doing
> a ${address:foo} expansion with a literal string for foo,
> in this test. And "foo" gets string-processed, which means
> backslash-interpretation for escaping.
>
Doh! I've got it now. So if it had instead been
On 13/02/2019 12:39, Mike Brudenell via Exim-users wrote:
>>> exim -v -be '${address:Pete(A nice \) chap) }'
>>> gives the empty string, suggesting Exim thinks it's a parse error
>>
>> You'd be needing to double the backslash, for the string-parsing
>> stage of the 822 address there, to actually
On Wed, 13 Feb 2019 at 12:10, Jeremy Harris via Exim-users <
exim-users@exim.org> wrote:
> On 13/02/2019 11:07, Mike Brudenell via Exim-users wrote:
>
> > exim -v -be '${address:Pete(A nice \) chap) }'
> > gives the empty string, suggesting Exim thinks it's a parse error
>
> You'd be needing to
On 13/02/2019 11:07, Mike Brudenell via Exim-users wrote:
> Hmm… There does seem to be an oddity.
Agreed.
> Jasen gave a link to an "extreme
> example" included in the RFC:
>
> https://tools.ietf.org/html/rfc5322#appendix-A.5
>
>
> Trying this in various forms using Exim 4.90.1 on Ubuntu
Hmm… There does seem to be an oddity. Jasen gave a link to an "extreme
example" included in the RFC:
https://tools.ietf.org/html/rfc5322#appendix-A.5
Trying this in various forms using Exim 4.90.1 on Ubuntu shows up some
interesting things:
exim -v -be '${address:Pete(A nice chap) }'
gives
On 13/02/2019 05:41, Jasen Betts via Exim-users wrote:
> the string expansion operator ${address:
>
> doesn't seem to strip RFC5322 comments (described in section 3.2.2)
>
> https://tools.ietf.org/html/rfc5322#section-3.2.2
>
> An extreme example:
>
>
the string expansion operator ${address:
doesn't seem to strip RFC5322 comments (described in section 3.2.2)
https://tools.ietf.org/html/rfc5322#section-3.2.2
An extreme example:
https://tools.ietf.org/html/rfc5322#appendix-A.5
Should it be doing that? (I could write a patch if this
11 matches
Mail list logo