Enda writes:
Sam wrote:
You are unclear in your explanation, as to whether messages received by
sqwebmail show an incorrect attachment name, or whether messages sent from
sqwebmail show an incorrect attachment name when download by some other
mail
client. I believe that it's the latter, but you are not clear.
It is what is received by the third party is what gets renamed.
If this is the latter, try renaming the file before attaching it, to
exclude
any punctuation, spaces, or non-English characters from the filename
(except
for a single .extension). When present, they cause the attachment's name
to
be encoded according to certain standards which some poorly written mail
clients may not be able to process. In any case, no renaming of any
attachment occurs on any server, it's just that the mail client that
downloads the attachment fails to properly implement the applicable
Internet
standards.
The testcase is a single pdf file named brochure.pdf
I send it through courier from a regular MUA, recipient receives
brochure.pdf attachment.
I send it through couerier from sqwebmail, receipient receives brochure.dat
attachment
Only the three letter extension is changed, and while I am confident that it
is happening entirely on the third party server, the only time it happens is
when the attachment originates from sqwebmail.
Seems to me that it is something to do with the envelope encoding used by
sqwebmail, and just wondering if that can be changed.
"Envelope encoding" is completely meaningless in this context. Nothing needs
to be done, in absence of any evidence that anything needs to be done. If
you Cc a copy of the message to a separate mailbox, after examining the
message you should not find anything wrong with its headers. If the
receipient's mail client is broken, the recipient's client needs to be
fixed.
5 messages in net.sourceforge.lists.courier-sqwebmailRe: [sqwebmail] Sqwebmail composed em...
