On Tue, Oct 30, 2012 at 3:57 AM, Molly Fletcher <[email protected]> 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 [email protected] >>> 2540 system filter added [email protected] >>> 2540 Delivery address list: >>> 2540 [email protected] >>> 2540 [email protected] >>> 2540 [email protected] >>> >>> 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 -- ## 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/
