On Fri, Oct 12, 2012 at 7:10 AM, Molly Fletcher
<molly.fletcher@???> wrote:
>> If you run a second exim on a different port, started with -d on the
>> command-line, that _should_ propagate.
> That worked:
>
> 5958 3095 bytes read from /etc/exim4/exim.filter
> 5958 data is an Exim filter program
> 5958 Filter: start of processing
<snip>
> 5958 Filter: save message to: /var/log/exim4/filtertest
> 5958 Filter: mail to: molly.fletcher@???
The above plain address becomes:
> 5957 original recipients ignored (system filter)
> 5957 system filter added >molly.fletcher@???
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
sorts, it indicates to the upcoming code that it is a local delivery
and not a file or pipe.
Comments at line 5321 indicate that the '>' are used a little more at
that point, but I can't see what use it provides past this point.
/* If a filter file specifies two deliveries to the same pipe or file,
we want to de-duplicate, but this is probably not wanted for two mail
commands to the same address, where probably both should be delivered.
So, we have to invent a different unique string in that case. Just
keep piling '>' characters on the front. */
> 5957 system filter added /var/log/exim4/filtertest
> 5957 Delivery address list:
> 5957 >molly.fletcher@???
> 5957 /var/log/exim4/filtertest
It does seem that by this it should have removed the '>' from the
front of the email address.
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.
<snip>
> 5957 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 5957 Considering: >molly.fletcher@???
> 5957 unique = >molly.fletcher@???:system-filter
> 5957 queued for local_delivery transport
> 5957 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 5957 Considering: /var/log/exim4/filtertest
> 5957 unique = /var/log/exim4/filtertest:system-filter
> 5957 queued for address_file transport
> 5957 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 5957 After routing:
> 5957 Local deliveries:
> 5957 /var/log/exim4/filtertest
> 5957 >molly.fletcher@???
Shortly after the above, line 5994 calls do_local_deliveries(). No
checking of the leading character for '>' was done past this point
that I could find.
<snip>
> 5959 changed uid/gid: local delivery to /var/log/exim4/filtertest
> </var/log/exim4/filtertest> transport=address_file
> 5959 uid=104 gid=112 pid=5959
> 5959 auxiliary group list: <none>
> 5959 home=NULL current=/
> 5959 set_process_info: 5959 delivering 1TMfc9-0001Xe-R0 to
> /var/log/exim4/filtertest using address_file
<snip>
> 5957 --------> >molly.fletcher@??? <--------
And when do_local_deliveries() calls deliver_local (actually does the
transport delivery), it seems like it definitely should have been
stripped by then.
<snip>
> 5960 changed uid/gid: local delivery to >molly.fletcher@???
> <>molly.fletcher@???> transport=local_delivery
> 5960 uid=104 gid=112 pid=5960
> 5960 auxiliary group list: <none>
> 5960 home=NULL current=/
> 5960 set_process_info: 5960 delivering 1TMfc9-0001Xe-R0 to
>>molly.fletcher@??? using local_delivery
This line is printed in src/transport.c:1862 by:
set_process_info("delivering %s to %s using %s", message_id,
addr->local_part, addr->transport->name);
...so that means it thinks local_part is the whole email address plus
the > on the front.
IMHO, it's possible that these '>' should be stripped somewhere in the
do_local_deliveries() function in src/receive.c:2126. But why has
this never been noticed before? If just the email address or just the
maildir are defined, does it still do this?
...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
