[quote user="Timo Harmo"]This is getting more and more annoying and people are switching from pegasus because of this. [/quote]

David Harris' comment on this.

I have a message with an attachment that has a very long name. Pegasus does not show the attachment name in the attachments tab.

 The attachment is marked as 

Content-Type: application/pdf;

name*0="long";

name*1="name"

I abbreviated the name, but this one behaves in the same way as the original with a really long name, that had had to be split in this way.

Yet this name*0.. name*1 .. syntax seems to be correct accoding to  http://tools.ietf.org/html/rfc2231  "3. Parameter Value Continuations"

A small thing, but this caused quite a lot of trouble as an important memo went unnoticed by several people.  (mainly on peg 4.41, but 4.52 seems not to have fixed this)

Just to clarify, the file name is not shown but the attachment is on the list and can also be clicked and opened successfully?

Also, are we talking about the attachments tab of the message reader window or the preview pane? The same behaviour exists in both of these areas?

[quote user="Timo Harmo"]Yet this name*0.. name*1 .. syntax seems to be correct accoding to  http://tools.ietf.org/html/rfc2231  "3. Parameter Value Continuations"

A small thing, but this caused quite a lot of trouble as an important memo went unnoticed by several people.  (mainly on peg 4.41, but 4.52 seems not to have fixed this)[/quote]

Yes, I remember this issue came up before but hasn't been fixed yet. I'll try to make a bit more urgent if I can ...

It is shown, with [type unknown] and no name to click on. It can be saved (but not opened directly) by selecting it and clicking "save". Same behaviour in preview mode and in message reader.

rfc2231 seems to a "proposed standard" (less than "draft standard"). I would think that implementing this in the sender makes the sender "broken", but on the receiving end  it would make life easier if even such broken messages could be read. But I'm not an expert on these issues and would like to hear more knowledgeable views. At least one long-time user swiched  away from Pegaus because of this.

Proposed or final, there are more and more problems because of this. Implementing it on the sending side is bad, but as many have done it, it seems necessary to implement it in receiving side. It's not just long filenames,but also encoded filenames

Pegasus does not understand the rfc2231 compliant: Content-Type: application/pdf; name*="utf-8''ty%C3.pdf", the asterisk after the parameter name seems to break it.

This is getting more and more annoying and people are switching from pegasus because of this.

Could you please identify which email client is generating these long attachment name derivatives?

Martin