http://bugzilla.spamassassin.org/show_bug.cgi?id=3383
------- Additional Comments From [EMAIL PROTECTED] 2004-05-16 01:53 ------- Subject: Re: Folded message-id unrecognized On Sat, May 15, 2004 at 06:26:27AM -0700, [EMAIL PROTECTED] wrote: > About your comment to my second patch, I don't really understand what you > mean. The points of these patch are: > 1. Don't reinvent the wheel and do the header parsing in spamd.raw but use > Message.pm. That's trivial. Right, we agree on that. > 2. Don't store two copies of the mail in the memory. Currently the mail is > first completely read into @msglines which is then copied inside the > Message.pm ctor. At that point, two copies of the mail exist in memory while > we theoretically only need one if we could just feed the incoming stuff > directly line-per-line to the Message.pm. That's what the anonymous > subroutine > is for. As that one also has to check for the size, I can't just feed the > ctor > a reference to $client->getline(). Well, a few things here. 1) The current method is cleaner. 2) I don't think the patch works. It references non-global/non-local variables in the anon-sub. Not only that, but the variables it wants to use really have no way of being passed in without mucking up the Message API, which I don't want to do. 3) We should do an 'undef @msglines' after the parse. The Message code specifically wants to get a copy of the message for itself, since it'll be messing with it during the parse. 4) Changing the M::SA::Message code in a non-trivial way is beyond this ticket IMNSHO. So what I was saying was we can easily put the parse before the use of the message-id. I was also commenting that we could probably put the expected!=actual test before the message-id output, so we don't have to worry about calling $mail->finish(). We can also undef the msglines array to free up some memory during processing. ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
