Hello! Sergey Poznyakoff wrote: > To begin with, test that patch as hard you can. Please, report back > any results, be they positive or negative. It looks too simple to > be right, so I'd better refrain from pushing it for now.
Hmmm ... It seems that there are no problems, everything works fine. All my tests pass well and on production environment also without problems. > Then, please try to answer the following questions: > > 1. What MUA produces this? It is good to have a black-list of such MUAs, > that notoriously break the standards. It is not always possible to have a black-list of such MUAs. Not all msgs contain information about MUA. And in that particular case, my filter can not trust the content. > 2. The same question for whitespace before the semicolon, please. Yes, I agree that it is impossible to accept the violations. However, small deviations are possible. Especially when the whole world no longer believes that this violation. If I programmed Google - I could dictate terms. But my little program must follow the rules of the game. Even if they do not quite meet the RFC. But when I conquer the whole world, then... :) > 3. What other schizophrenic ways of packing the filename may this MUA > (or maybe others) implement? In my particular case, that is not a problem. I do not care what thinks one single MUA(or maybe two). But if it works on most popular MUAs - I need that would be my filter to work the same way. > E.g. can the filename be encoded using QP > instead of B64? Yes, it can, why not? With patch its work well too: --- Content-Disposition: attachment; charset=koi8-r; filename==?windows-1251?Q?=CF=F0=EE=E5=EA=F2_=CF=F0=EE=E5=EA=F2_=2Ejpg?= --- ... and traditionally, I have a few new complaints :) mu_message_aget_decoded_attachment_name() return fname=NULL for: 1. The problem is in a double semicolon: --- Content-Type: application/octet-stream;; name = "konf_2010.doc" Content-Transfer-Encoding: base64 --- 2. The problem is in a very long filename: --- Content-Disposition: attachment; filename="=?windows-1251?Q?=CF=F0=EE=E5=EA=F2_=CF=F0=EE=E5=EA=F2_=CF=F0=EE=E5=EA=F2_=CF=F0=EE=E5=EA=F2_=CF=F0=EE=E5=EA=F2_=CF=F0=EE=E5=EA=F2_=CF=F0=EE=E5=EA=F2_=CF=F0=EE=E5=EA=F2_=CF=F0=EE=E5=EA=F2_=CF=F0=EE=E5=EA=F2_=CF=F0=EE=E5=EA=F2_=CF=F0=EE=E5=EA=F2_=CF=F0=EE=E5=EA=F2_=CF=F0=EE=E5=EA=F2_=CF=F0=EE=E5=EA=F2_=CF=F0=EE=E5=EA=F2_=2Ejpg?=" --- ( RFC 2822 2.1.1. Line Length Limits There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. ) And as I said earlier, both these claims works well on the most popular MUAs. And my interest in that it would work in my filter too. =kostik _______________________________________________ Bug-mailutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-mailutils
