From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 394020257792 X-Google-Groups: supmua X-Google-Thread: 3030fda1bf,d65b43b9517108fb X-Google-Attributes: gid3030fda1bf,domainid0,public,googlegroup X-Google-NewGroupId: yes X-Received: by 10.180.182.164 with SMTP id ef4mr3245480wic.0.1416505722564; Thu, 20 Nov 2014 09:48:42 -0800 (PST) X-BeenThere: supmua@googlegroups.com Received: by 10.180.11.42 with SMTP id n10ls74625wib.14.gmail; Thu, 20 Nov 2014 09:48:41 -0800 (PST) X-Received: by 10.180.108.101 with SMTP id hj5mr1264802wib.3.1416505721968; Thu, 20 Nov 2014 09:48:41 -0800 (PST) Return-Path: Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com. [74.125.82.42]) by gmr-mx.google.com with ESMTPS id r4si214604wia.0.2014.11.20.09.48.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Nov 2014 09:48:41 -0800 (PST) Received-SPF: none (google.com: eg@gaute.vetsj.com does not designate permitted sender hosts) client-ip=74.125.82.42; Authentication-Results: gmr-mx.google.com; spf=none (google.com: eg@gaute.vetsj.com does not designate permitted sender hosts) smtp.mail=eg@gaute.vetsj.com Received: by mail-wg0-f42.google.com with SMTP id z12so4437683wgg.29 for ; Thu, 20 Nov 2014 09:48:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :user-agent:message-id:mime-version:content-type :content-transfer-encoding; bh=FJtwC4vcBqjpr5zJS8K+j3jMdFa4JjrpMEr5Qy2bDZo=; b=O2axIemPogzaseHkD5O5NOZx99kYrp38UYLN+JRLxAiZj+kjbCXMrcTXYmGf/66HnM DMVEG/hdSjSsF5nmDx5PDGgFXMan1V9gXirw2J8OctDTORxo78y5XcrHkldSuWvX5cFj HjuF327q3auoSsDr2mouY5fnp3l2SNCG9InyYuCr/cWVRMzecNQHdpTx8czMN9wU79IO 8ry6dOeGnmNf096IrpuQ4T1Gj9w6KLAPULkDd8gYkkS31qYWourcRHHntDwphLUr2Lib UJ7XfXNG3gOl/2uGxlM9e0bMqbs55fnhtkYTevWudC7vxQ3JnU0Vx1zXIQ44wvUtsZNJ /2NQ== X-Gm-Message-State: ALoCoQkMEB3BtQkbpPXp03UZI06HPV38gnR7H0zsDU7asTQfxuSQ8/SxxwWAumpdDF6U/Yu1f0TD X-Received: by 10.180.98.233 with SMTP id el9mr13284wib.3.1416505721282; Thu, 20 Nov 2014 09:48:41 -0800 (PST) Return-Path: Received: from localhost (216.89-20-249.enivest.net. [89.20.249.216]) by mx.google.com with ESMTPSA id lp14sm5041700wic.20.2014.11.20.09.48.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Nov 2014 09:48:40 -0800 (PST) Date: Thu, 20 Nov 2014 17:48:53 +0000 From: Gaute Hope Subject: Re: [sup] Bug in mbox.rb? To: Ruthard Baudach Cc: supmua References: <1416264666-sup-9223@ruthard-lappi> <1416387515-astroid-1-m2ak1advzy-2022@strange> <1416415410-sup-6292@ruthard-lappi> In-Reply-To: <1416415410-sup-6292@ruthard-lappi> User-Agent: astroid/vc24d4330 (https://github.com/gauteh/astroid) Message-Id: <1416505196-astroid-8-i6copfrsyz-3226@strange> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Excerpts from Ruthard Baudach's message of November 19, 2014 17:53: >>=3D=3D Ausz=C3=BCge aus der Nachricht von Gaute Hope vom 2014-11-19 10:0= 3: >> Excerpts from Ruthard Baudach's message of November 18, 2014 0:08: >> > If I am not mistaken, both RFC4155 and >> > http://www.qmail.org/man/man5/mbox.html >> > specify that an mbox entry is *terminated* by a blank line. >> >=20 >> > line 117 -124 of lib/sup/mbox.rb reads: >> >=20 >> > def store_message date, from_email, &block >> > need_blank =3D File.exists?(@path) && !File.zero?(@path) >> > File.open(@path, "ab") do |f| >> > f.puts if need_blank >> > f.puts "From #{from_email} #{date.asctime}" >> > yield f >> > end >> > end >> >=20 >> > As far as I understand this, sup puts a blank line *before* the >> > separator line except for the first message. >> >=20 >> > My old sent.mbox is terminated by the last line of the last message, m= y >> > old inbox.mbox is terminated by a blank line. I am not sure this is a problem after all, as stated in qmails 'How a message is read', message reading is stopped either at the next From line or EOF. The blank line does not play a huge role, but it is in effect added to all messages except the last one (which is terminated by EOF anyway). You could do a f.puts as you suggest below in stead, but it would not make much of a difference as far as I can see. I think the mbox is valid as it is. Now; mbox.rb does escape From lines in the body, but I cannot see how they are un-escaped when reading. Does RMail::Parser.read unescape these? Also, does mbox.rb skip the extra blank line or do messages get an extra blank line after being re-read? probably not critical, but tests should be run on this.. cheers, gaute >> >=20 >> > If I'm not mistaken, this could lead to problems, if the same mbox wou= ld >> > be fed by sup and another MDA, e.g. if someone would use the same mbox >> > for in- and outgoing mail (as I did when I had to setup sup anew after >> > upgrading to 0.15. Changing to maildir simultaneously safed me from th= is >> > bug. Huh!) >> >=20 >> > Changing the lines 117 - 124 of lib/sup/mbox.rb to >> >=20 >> > def store_message date, from_email, &block >> > File.open(@path, "ab") do |f| >> > f.puts "From #{from_email} #{date.asctime}" >> > yield f >> > f.puts >> > end >> > end >> >=20 >> > would take care of this. >> >=20 >> > Do you agree? >> >=20 >> > Shall I submit a patch? >> >=20 >> > O =E2=80=93 of course this would break existing setups with wrong form= atted >> > mboxes. >> >=20 >> > Hmmmmmm????=20 >>=20 >> haven't looked at the details yet, but nice catch. >>=20 >> oh.. that would be baad. breaking existing setups is a >> out-of-the-question though. Consequently; we need tests for whatever >> change fixing this introduces (have a look at the test folder). >>=20 >> I think a fix should;=20 >> - fix existing mboxes (on next write) >> - don't break on any existing mboxes >> - conform to standards >> - include tests of all these points >> - RMail has a mbox parser (i think) which perhaps could be used for >> testing, i think sup included its own for performance reasons. >>=20 >>=20 >> gaute >=20 > I think >=20 > 1) It's a minor bug, it would only cause problems if one would > intermingle in- and outgoing mail. Does it has to be fixed? >=20 > 2) I could either just fix it, write a script to fix wrongly formatted > mboxes, and the next release would need a WARNING RUN SUP_FIX_MBOXES > prior to using it after update. >=20 > 3) I could check the mbox everytime a message is added and add a empty > line as needed. Would increase disk usage. >=20 > I couldn't make any sense of the test dir in the source code, probably fo= r > lack of knowledge, not because of lack of sense;-) >=20 > Could you point me to some documentation on testing the sup team is > using? >=20 =