Attachment filename problem

[Marc]

I just noticed something strange when sending an attachment with an exceedingly long filename. I sent the exact same mail, once with old (RFC2037) and once with new (RFC2231) style filename encoding through both our Scalix server and directly through our smtp gateway.

1) old, through smtp gateway

Code: Select all

--------------060305050804090503060003
Content-Type: application/pdf;
 name="=?ISO-8859-1?Q?a_very_long_and_completely_meaningless_name_?=
 =?ISO-8859-1?Q?with_umlauts_like_=E4=FC=F6=DF_in_it=2Epdf?="
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="=?ISO-8859-1?Q?a_very_long_and_completely_meaningless_name_?=
 =?ISO-8859-1?Q?with_umlauts_like_=E4=FC=F6=DF_in_it=2Epdf?="

JVBERi0xLjMKJcfsj6IKNiAwIG9iago8PC9MZW5ndGggNyAwIFIvRmlsdGVyIC9GbGF0ZURl
Y29kZT4+CnN0cmVhbQp4nN1RO04EMQztfQrXFCb+JHaOAZSIahALElssFFyfDBMP7AougFLk


2) old, Scalix

Code: Select all

--------------050208050300000202030609
Content-Type: application/pdf;

name="=?ISO-8859-1?Q?a_very_long_and_completely_meaningless_name_?==?ISO-8859-1?Q?with_umlauts_like_=E4=FC=F6=DF_in_it=2Epdf?"
Content-Transfer-Encoding: base64
Content-Disposition: inline;

filename="=?ISO-8859-1?Q?a_very_long_and_completely_meaningless_name_?==?ISO-8859-1?Q?with_umlauts_like_=E4=FC=F6=DF_in_it=2E"

JVBERi0xLjMKJcfsj6IKNiAwIG9iago8PC9MZW5ndGggNyAwIFIvRmlsdGVyIC9GbGF0ZURl
Y29kZT4+CnN0cmVhbQp4nN1RO04EMQztfQrXFCb+JHaOAZSIahALElssFFyfDBMP7AougFLk


3) new, smtp gateway

Code: Select all

--------------090409070002020105070406
Content-Type: application/pdf;
 name*0*=ISO-8859-1''%61%20%76%65%72%79%20%6C%6F%6E%67%20%61%6E%64%20%63%6F;
 name*1*=%6D%70%6C%65%74%65%6C%79%20%6D%65%61%6E%69%6E%67%6C%65%73%73%20;
 name*2*=%6E%61%6D%65%20%77%69%74%68%20%75%6D%6C%61%75%74%73%20%6C%69%6B;
 name*3*=%65%20%E4%FC%F6%DF%20%69%6E%20%69%74%2E%70%64%66
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename*0*=ISO-8859-1''%61%20%76%65%72%79%20%6C%6F%6E%67%20%61%6E%64%20;
 filename*1*=%63%6F%6D%70%6C%65%74%65%6C%79%20%6D%65%61%6E%69%6E%67%6C%65;
 filename*2*=%73%73%20%6E%61%6D%65%20%77%69%74%68%20%75%6D%6C%61%75%74%73;
 filename*3*=%20%6C%69%6B%65%20%E4%FC%F6%DF%20%69%6E%20%69%74%2E%70%64%66

JVBERi0xLjMKJcfsj6IKNiAwIG9iago8PC9MZW5ndGggNyAwIFIvRmlsdGVyIC9GbGF0ZURl
Y29kZT4+CnN0cmVhbQp4nN1RO04EMQztfQrXFCb+JHaOAZSIahALElssFFyfDBMP7AougFLk


4) new, Scalix

Code: Select all

--------------040707080202090805030201
Content-Type: application/pdf;
        name*0="=?ISO-8859-1?Q?a_very_long_and_co?=";
        name*1="=?x-scalix-%6D%70%6C%65%74%65%6C%?Q??=";
        name*2="=?x-scalix-%6E%61%6D%65%20%77%69%?Q??=";
        name*3="=?x-scalix-%65%20%E4%FC%F6%DF%20%?Q??="
Content-Transfer-Encoding: base64
Content-Disposition: inline;
        filename*0="=?ISO-8859-1?Q?a_very_long_and_?=";
        filename*1="=?x-scalix-%63%6F%6D%70%6C%65%74%?Q??=";
        filename*2="=?x-scalix-%73%73%20%6E%61%6D%65%?Q??=";
        filename*3="=?x-scalix-%20%6C%69%6B%65%20%E4%?Q??="

JVBERi0xLjMKJcfsj6IKNiAwIG9iago8PC9MZW5ndGggNyAwIFIvRmlsdGVyIC9GbGF0ZURl
Y29kZT4+CnN0cmVhbQp4nN1RO04EMQztfQrXFCb+JHaOAZSIahALElssFFyfDBMP7AougFLk


The result is in both cases a broken filename when the mail passes through Scalix.

My filename was "a very long and completely meaningless name with umlauts like äüöß in it.pdf" if someone wants to try.

I found the *_FNAME_ENCODING parameters and tried setting them to NONE, but this seems to have no effect when using the older encoding and just leaves empty lines when using the newer one... are there any other config values I could set to prevent this?



Thanks,

Marc

[gren]

Hi Marc,

I regret that Scalix does not fully support RFC 2231 yet.
See Bug :
http://bugzilla.scalix.com/show_bug.cgi?id=12900

Regards,
Gren.

[Marc]

Hi Greg,

I regret that Scalix does not fully support RFC 2231 yet.

sorry, I think I didn't describe the problem clearly enough: this mail was outbound, sent by me to an address not within our domain. In the first and third example I used our mail gate as smtp server (read: the mail did not pass through Scalix), in the second and fourth I used our Scalix server (which in turn uses the above mentioned mail gateway to relay).

The examples I posted are not taken from anything that's stored on Scalix, they are snapshots taken from the mail spool on the gateway.

RFC2231 aside, if you look at 1) and 2), you'll see that the linebreak after 76 characters in the filename is removed and the suffix ("pdf") is cut off, which leads to a mangled attachment name once the mail arrives at its destination.

Why are these names changed anyway? They look pretty much ok to me the way they are sent by the client...


Marc

[gren]

Ah, indeed So there are at least 2 issues here then...

[Marc]

Hi gren,

(sorry for the 'Greg' in my last post, probably was to early in the day for me)

Ah, indeed So there are at least 2 issues here then...

I think so. Please let me know if you need any additional info on our setup.


Marc

[gren]

With Scalix 11 pre-release, I have a test sample SMTP conversation which I use as input to unix.in :

Code: Select all

EHLO localhost
MAIL FROM:<frodo.baggins@crowley.uk.scalix.com>
RCPT TO:<gandalf.gray@crowley.uk.scalix.com>
RCPT TO:<gren@example.com>
DATA
Subject: Testing long name.
From: this.person@example.com
To: gandalf.gray@crowley.uk.scalix.com
To: gren@example.com
MIME-Version: 1.0
Content-Type: text/plain
 name="=?ISO-8859-1?Q?a_very_long_and_completely_meaningless_name_?=
 =?ISO-8859-1?Q?with_umlauts_like_=E4=FC=F6=DF_in_it=2Epdf?="
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="=?ISO-8859-1?Q?a_very_long_and_completely_meaningless_name_?=
 =?ISO-8859-1?Q?with_umlauts_like_=E4=FC=F6=DF_in_it=2Epdf?="

Hello there.
.
QUIT


This comes into Scalix and then goes out through the internet gateway for the example.com address with this as the output :

Code: Select all

EHLO crowley.uk.scalix.com
MAIL FROM: <frodo.baggins@crowley.uk.scalix.com>
RCPT TO: <gren@example.com>
DATA
Date: Thu, 21 Dec 2006 18:49:52 +0000
From: this.person@example.com
To: Gandalf Gray <gandalf.gray@crowley.uk.scalix.com>,
        gren@example.com
Message-ID: <X000000000006890.1166726992.crowley.uk.scalix.com@MHS>
Subject: Testing long name.
x-scalix-Hops: 1
MIME-Version: 1.0
Content-Type: text/plain name="=?ISO-8859-1?Q?a_very_long_and_completely_meaningless_name_?= =?ISO-8859-1?Q?with_umlauts_like_=E4=FC=F6=DF_in_it=2Epdf?="
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
        filename="=?ISO-8859-1?Q?a_very_long_and_completely_meaningless_name_?= =?ISO-8859-1?Q?with_umlauts_like_=E4=FC=F6=DF_in_it=2Epdf?="

Hello there.
.
QUIT


I don't see the clipping of the ".pdf" that you saw. Were you using an earlier version of Scalix?
I'm not sure whether it matters that the string is in 2 bits joined only by a space. Which client is having difficulties with that?

Regards,
Gren.