[quote user="Joerg"]Thanks Michael, Mail has been sent
[/quote]

Got it, thanks, I'll forward it to David Harris!

Since a few days one of our customers is regularly sending pdf attachments to us with following file name pattern "L2000877_PB-15-04421 - Project M_V Name123, Company ABCD.pdf".

Unfortunately it seems Pmail is not able to process this file name correctly. When opening the mail and switching to the attachment section, Pmail is showing only  " - " as file name, and the real file name is added to "description".

When trying to save the attachment at harddisk, Pmail is only creating a file called " - " without any name or file extension. In that case we have to manually rename the file into its original "name.pdf". Then we are able to open it by a pdf viewer, means the file is not corrupt but only the name is wrong.

Here is the attachment header, taken from the raw view of Pmail:

-----=_Part_28_248831067.1583941918156
Content-Type: application/pdf;
name*0="L2000877_PB-15-04421 - Projekt M_V Name123, Company ABC"; name*1=n.pdf
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*0="L2000877_PB-15-04421 - Projekt M_V Name123, Company ABC"; filename*1=n.pdf
Content-Description: L2000877_PB-15-04421 - Projekt Name123, Company ABCD.pdf

Worth to mention that the "name" and "filename" section above in the header are showing a shortened filename, while the content-description is showing the correct name.

In contrast to the above said Thunderbird has no problem with this mail and the attachment (opened from the same local Mercury/Pmail user mailbox), showing and saving it correctly. Maybe the long file name, especially with the "comma" inside is not in accordance with any internet standards. Has anybody an idea?

[quote user="Joerg"]Maybe the long file name, especially with the "comma" inside is not in accordance with any internet standards.[/quote]

That's what the quotes are for, but you can easily test this by omitting the blanks and commas in the respective CNM file after copying the message to the new mail folder. But I guess it's rather an issue with the special kind of splitting long header content into two parts (starting with an asterisk) used here according to RFC 2231, called Parameter Value Continuations (Section 3): "a continuation mechanism for long parameter values to avoid problems with header line wrapping". Looks like it's still not supported by Pegasus Mail, we need to ask David Harris here, once again ...

Thanks Michael, I already suspected that there would be another RFC for [:)]. Will see if David answers. Nevertheless it's an unpleasant thing where my users claim Pmail again for.

Take care of you and stay healthy.

[quote user="Joerg"]Will see if David answers.[/quote]

It would help to have a sample message for him. I might have one somewhere since I remember having dealt with it for some reason in the past already, but I'm not too sure about it. Could you provide one for us maybe?

[quote user="idw"]It would help to have a sample message for him. I might have one somewhere since I remember having dealt with it for some reason in the past already, but I'm not too sure about it. Could you provide one for us maybe?
[/quote]

Just checked the problematic attachment. Unfortunately it has content which I must not share.

Sending any other attachments with such long file name or name pattern doesn't reproduce the issue. I'm gonna wait until the next problematic attachment from that client is reaching us. Maybe it has less important content that I can provide you with.

Thanks for your offer.

[quote user="Joerg"]

[quote user="idw"]It would help to have a sample message for him. I might have one somewhere since I remember having dealt with it for some reason in the past already, but I'm not too sure about it. Could you provide one for us maybe?
[/quote]

Just checked the problematic attachment. Unfortunately it has content which I must not share.

Sending any other attachments with such long file name or name pattern doesn't reproduce the issue. I'm gonna wait until the next problematic attachment from that client is reaching us. Maybe it has less important content that I can provide you with.

Thanks for your offer.

[/quote]

How about your client late messages?

[quote user="Euler GERMAN"]

How about your client late messages?

[/quote]

Hi Euler,

What do you mean? Making no sense for me sending the last client e-mail without the attachment. How do you want to test the saving of attachment if the attachment is missing?

[quote user="Joerg"][quote user="Euler GERMAN"]

How about your client late messages?

[/quote]

Hi Euler,

What do you mean? Making no sense for me sending the last client e-mail without the attachment. How do you want to test the saving of attachment if the attachment is missing?

[/quote]

Joerg,

What I meant is that a late message (with attachments, of course), which doesn't carry any sensitive data, would be entitled to use.

Sorry if I wasn't clear at first.

Reading of RFC  it seems that the protocol for the Mime header folding is not being followed. The filename*1=n.pdf should be on a following line with one blank at the start of the line (following folding rules). Both file* and name* are breaking the rules of the RFC.  As-is, the filename is the whole string on one line, and contains illegal characters, and thus there is no folding of multiple lines.

Somewhere the rules are being broken. The content-description above shows the actual filename and doesn't need folding, as the length must exceed 78 bytes to need folding.

Martin

[quote user="irelam"]Somewhere the rules are being broken. The content-description above shows the actual filename and doesn't need folding, as the length must exceed 78 bytes to need folding.[/quote]

... supposed Joerg didn't modify the headers when posting them here which I'm sure he did ... and the RFC doesn't say you're not allowed to use it's rules when it's not strictly required, its samples actually wouldn't require using them either ...

And, BTW, all of the filname is actually legal: "L2000877_PB-15-04421 - Projekt M_V Name123, Company ABCD.pdf" is a valid filename on Windows systems.

[quote user="Joerg"]

[quote user="idw"]It would help to have a sample message for him. I might have one somewhere since I remember having dealt with it for some reason in the past already, but I'm not too sure about it. Could you provide one for us maybe?
[/quote]

Just checked the problematic attachment. Unfortunately it has content which I must not share.[/quote]

[quote user="idw"]Danke! Es ist aber definitiv ein RFC-Standard, daher muß es irgendwann sowieso umgesetzt werden. [/quote]

Thanks for the link to a former discussion in this regard from 2018. Seems it's not a "Joerg only" issue.  :-)

But what does your (german) message mean? Are the folded long file names RFC standard, but have yet to be implemented by Pmail? Or is it a fault behaviour of the sender's e-mail client, which is transforming long attachment file names in the wrong way?

I have to tell something to my 20 local users, whether they have to live with or whether they should notify the sender don't using such long file names beause of a faulty mail client on its side (sender)?

[quote user="Joerg"]Thanks for the link to a former discussion in this regard from 2018. Seems it's not a "Joerg only" issue.  :-)[/quote]

Far from that! [:)] I just found an interesting discussion on the matter at GitHub: https://github.com/PHPMailer/PHPMailer/issues/1469

Can you identify the Sender's mailer? (e.g. X-mailer:)

Folks,

Sending a message to myself containing a very long filename produced this section header:

[quote]--Message-Boundary-1102
Content-type: Application/Octet-stream; name="0________1_________2_________3_________4_________5_________6_________7_________8_________9________10________11________12________13________14________15________16________17________18________19________20.pdf"; type=Adobe-PDF
Content-disposition: attachment; filename="0________1_________2_________3_________4_________5_________6_________7_________8_________9________10________11________12________13________14________15________16________17________18________19________20.pdf"
Content-transfer-encoding: BASE64

JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PC9TdWJ0eXBlL1hNTC9UeXBlL01ldGFkYXRhL0xl
bmd0aCAzMzM4Pj5zdHJlYW0KqXNAqbcx8vTXd6gXB3/c+IumabTYU/IuuUYkDkz5oRi5/…
[/quote]

File is correctly recognized as "Adobe-PDF", opened and saved.

I edited the .CNM file to the following format (and to meet Joerg's description):

[quote]--Message-Boundary-1102
Content-type: Application/Octet-stream;
name*0="0________1_________2_________3_________4_________5_________6";
name*1="_________7_________8_________9________10________11________12";
name*2="________13________14________15________16________17________18";
name*3="________19________20.pdf"; type=Adobe-PDF
Content-disposition: attachment;
name*0="0________1_________2_________3_________4_________5_________6";
name*1="_________7_________8_________9________10________11________12";
name*2="________13________14________15________16________17________18";
name*3="________19________20.pdf"
Content-transfer-encoding: BASE64

JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PC9TdWJ0eXBlL1hNTC9UeXBlL01ldGFkYXRhL0xl
bmd0aCAzMzM4Pj5zdHJlYW0KqXNAqbcx8vTXd6gXB3/c+IumabTYU/IuuUYkDkz5oRi5/mjh
mI1DEUH4etVJQydB7CS6ZsysFCMOkMZ59w2yjk4BmQjUUbigxCa7fXzkW4EjDeEC+36Z3…
[/quote]

File is recognized as "Type unknown", and if saved it appears as a single hyphen. OTOH both files are identical in content if saved.

Anyway, and if I got things right, editing multiple name*#="... to a single line filename="..., keeping only first open and last close double quotes, should do the trick.

Hope it helps.

[quote user="Euler GERMAN"], and if I got things right, editing multiple name*#="... to a single line filename="..., keeping only first open and last close double quotes, should do the trick.
[/quote]

Playing a bit more I found the filename=" … " must NOT have CR-LF in between to work. More below.

[quote user="Joerg"]

[quote user="idw"]Danke! Es ist aber definitiv ein RFC-Standard, daher muß es irgendwann sowieso umgesetzt werden.[/quote]

Thanks for the link to a former discussion in this regard from 2018. Seems it's not a "Joerg only" issue.  :-)[/quote]

If you take a closer look, it was: The author of the post in the German forum was a "Jörg" as well ...

[quote user="Joerg"]But what does your (german) message mean? Are the folded long file names RFC standard, but have yet to be implemented by Pmail?[/quote]

Yes, and It means exactly what I wrote. I re-submitted the sample message from 2018 to re-raise this issue with David Harris, his reply being more or less the same as last time: It should be an easy fix. I think we've got a good chance to get it solved rather soon this time since he's got to come up with another interim release anyway because of the OAuth2 issue having to be solved in the very near future and no health issues keeping him off work for another year or so.

BTW: Thanks Euler for narrowing down this issue ;-)

Thanks a lot Michael and Euler for clarification, discovery and your effort. Highly appreciated. Fortunately such long file names appear with us not soo often, appr. once every two weeks. And we are happy if David will implement the soluion soon.

@Michael: It's funny that the original author was "Jörg" as well. I indeed didn't notice it. [:D]

Moin Michael,

Just received another e-mail with such an odd attachment. Although this time the attachment name is not soo long, the file name is missing when trying to save it.

The content of this new mail is not soo sensitive, so I could forward it to you in trust that you don't share it further (except to your Pmail dev team). Should I use your IDW t-online address? Would you prefer that I bounce the mail or should I forward the mail by "new mail with current mail attached"?

Jörg

[quote user="Joerg"]The content of this new mail is not soo sensitive, so I could forward it to you in trust that you don't share it further (except to your Pmail dev team). Should I use your IDW t-online address? Would you prefer that I bounce the mail or should I forward the mail by "new mail with current mail attached"?[/quote]

The latter option would be the preferred one and don't use my personal address because the message might not get through my provider's spam filters. Please forward it to <beta-reports [at] pmail.gen.nz> using a subject line that refers to this thread so I can easily tell it apart from all the spam messages sent to this account. Thanks in advance, Joerg!