Re: [exim] Strange system filter behaviour.

Top Page
Delete this message
Reply to this message
Author: Todd Lyons
Date:  
To: Todd Lyons, Molly Fletcher, <exim-users@exim.org>, Ian Eiloart
Subject: Re: [exim] Strange system filter behaviour.
On Fri, Oct 12, 2012 at 3:12 PM, Phil Pennock <pdp@???> wrote:
> On 2012-10-12 at 09:11 -0700, Todd Lyons wrote:
>> This is processed and detected starting at line 5018 in src/deliver.c.
>>  It is the original code since Philip Hazel imported it, so I don't
>> think it's the problem.  It detects it properly.  The '>' is a flag of
> It looks as though we have a false comment in filter.c then:
> 2260       /* Create the "address" for the autoreply. This is used only for logging,
> 2261       as the actual recipients are extracted from the To: line by -t. We use the
> 2262       same logic here to extract the working addresses (there may be more than
> 2263       one). Just in case there are a vast number of addresses, stop when the
> 2264       string gets too long. */


Ok, so the addr structure was originally not used for sending this?

> This code was added in c25242d781667319938db77399e2073ba9e798f8;
> ChangeLog entry was for release 4.60:
> ----------------------------8< cut here >8------------------------------
> PH/05 When a filter generated an autoreply, the entire To: header line was
>       quoted in the delivery log line, like this:

>
>         => >A.N.Other <ano@???> <original@ddress> ...

>
>      This has been changed so that it extracts the operative address. There
>      may be more than one such address. If so, they are comma-separated, like
>      this:

>
>        => >ano@???,ona@??? <original@ddress> ...
> ----------------------------8< cut here >8------------------------------
> Note that part of the commit diff is:
> -      addr = deliver_make_addr(string_sprintf(">%.256s", to), FALSE);
> +      addr = deliver_make_addr(log_addr, FALSE);

>
> So the "addr" was with the > prefix before this too.


I don't know what to make of this just yet.

>> Has nobody ever used this before and noticed that email addresses
>> still have this '>' character in front of them? Googling didn't find
>> any for me.
> I suspect that at some point, the "-t parse" logic must have been
> removed/simplified away without realising the address format.


Ah, good point. Maybe we can look and find said parse logic.

I didn't google very well before apparently. I dug a little more and
found something from 2008:
http://forum.lissyara.su/viewtopic.php?f=20&t=8366#p68304
I don't read Russian, but I did see this debug output:

2540 Filter: end of processing
2540 system filter returned 1
2540 system filter added mail-copy-mailbox@???
2540 system filter added mail-copy-mailbox@???
2540 Delivery address list:
2540 mail-copy-mailbox@???
2540 mail-copy-mailbox@???
2540 opt1k@???

It's without the '>' mark, so there's at least a possibility that the
simple fix is to strip the leading '>' before it prints this output.

...Todd
--
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine