On Tue, Oct 30, 2012 at 3:57 AM, Molly Fletcher
<molly.fletcher@???> wrote:
>>>>> 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.
>>> 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.
>> Note that in this case, all the recipients are of type email, so the
>> processing which looks at the first element in the list sees the > and
>> strips it off all of them. In the bug case, the first recipient address
>> is a path, so that doesn't happen.
> The path was only added as an aid to debug a problem we were already
> having. It still occurred when we only had email address deliveries.
Molly, can you test to make sure that when it's only delivering to
email addresses that the debug output above still has the errant '>'
symbols present?
...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
