Re: [bug-mailutils] improve behavior of mu_mimehdr_a?get_disp

[Kostik]

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