POP3 Attachment corruption issues

[gregs]

Currently we have installed the community version of Scalix 10.0 on Red Hat 4.0. I have run into a problem when using Outlook 2003 with POP3. We are seeing a lot of corrupt attachments to the recipient including PDF files. However if you send the exact same message with webmail or use the Scalix connector for Outlook the attachments go through and are OK at the recipient. Also several clients are getting bounce backs with the error 501 5.5.4 Invalid arguments in the returned message. Any one else run across this.

[ScalixSupport]

Can you post the headers of a corrupted message ?

With the invalid arguments, are the users requesting read/delivery receipts when they send the message ? Again, please post more information. In this case, the exact text of the NDN will give us the details.

Cheers

Dave

[gregs]

Dave,

Thanks for the response. I am a newbie to both Linux and Scalix so bear with me.

The users that have gotten the messages back were requesting read reciepts. Below are the details of the NDN:

The original message was received at Mon, 20 Mar 2006 15:32:52 -0500
from localhost.localdomain [127.0.0.1]

----- The following addresses had permanent fatal errors -----
<Jennifer.Cheng@kylintv.com>
(reason: 501 5.5.4 Invalid arguments)

----- Transcript of session follows -----
... while talking to mail.kylintv.com.:
>>> MAIL From:<Joanna.Lo@neulion.com> SIZE=216489 ENVID=!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA6e1sNFhe4E+2BV6WvwR192K8KAAAAQAAAAlbwG+2BMP91UCPqZL5pk5lrgEAAAAA@neulion.com RET=FULL

<<< 501 5.5.4 Invalid arguments
501 5.6.0 Data format error

[ScalixSupport]

Unfortunately, this is a problem on the receiving side and it's a little ironic that the problem is happening with an Exchange server :-)

ENVID is being used when a read/delivery receipt is being requested. The only client we have seen that generates a really long ENVID is Outlook 2003 in Internet mode. This caused us some problems for the SMTP Relay and also for sendmail in 9.4. All of those have been fixed in Scalix 10.

As a quick test, you can run the following SMTP conversation through the SMTP Relay or sendmail:

Code: Select all

ehlo localhost
mail from: someone@domain.com ENVID=!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA6e1sNFhe4E+2BV6WvwR192K8KAAAAQAAAAlbwG+2BMP91UCPqZL5pk5lrgEAAAAA@neulion.com RET=FULL
rcpt to: recipient@domain.com
data
Subject: Hello

This is a test
.
quit

In most cases, you will see that the message is accepted. However, the receiving server, mail.kylintv.com is not able to deal with either the length or the format of the ENVID value.

I just ran a quick test against it and it returns the invalid arguments error.

This isn't something that we can readily fix in Scalix. The ENVID is being supplied by the client and we are just propagating it.

Cheers

Dave

[gregs]

Dave,

I haven't done mail or clients in a few years. Is there a way to modify 2003 to address this?

Also an update on the PDF document it appears that the issue is not with all PDFs. I have an application that exports data to PDF. The version information shows the exported file being version 3. Sending newer version PDF's appear to deliver correctly.

[gregs]

Dave,

Thanks for the help. I am still working through the issue but have confirmed it is definitely the read receipt that is causing the issue. If you get any updates I would appreciate the assistance and I will post any findings I get to the community board.

[ScalixSupport]

As far as I'm aware, there is no way to change this apart from not requesting a read receipt.

Section 4.4 of RFC 3461 details what is acceptable with the ENVID. It can be up to 100 characters and non-Ascii characters need to encoded. When I said, we don't do anything, I was incorrect.
We ensure that the ENVID value meets those requirements, in particular, we encode the string as "xtext", section 4 of RFC 3461 shows how, before we pass it on.

From what I can see of the ENVID supplied, it all falls within the requirements of the RFC.

I checked through the Microsoft knowledgebase and couldn't see anything immediately but the issue is definitely with the receiving server.

Cheers

Dave

[gregs]

For anyone else interested here is your answer.

http://support.microsoft.com/kb/195108/en-us

If I read the document correctly read reciepts not supported in POP3 and IMAP4 Since Outlook 2000. Another way for the M$ machine to make money. Even though IMHO the read receipts are a waste anyway as they do not froce teh user to say yes before they read the message.

[gregs]

Ooops My mistake the above post is for delivery receipts not read receipts.

I guess my question is I can send messages with a read receipt using the Scalix Outlook Connector and webmail but when I use POP3/SMTP it fails. So the question is how is the message formatted differently between these methods?

[jola16]

As far as I'm aware, there is no way to change this apart from not requesting a read receipt.

Section 4.4 of RFC 3461 details what is acceptable with the ENVID. It can be up to 100 characters and non-Ascii characters need to encoded. When I said, we don't do anything, I was incorrect.
We ensure that the ENVID value meets those requirements, in particular, we encode the string as "xtext", section 4 of RFC 3461 shows how, before we pass it on.

From what I can see of the ENVID supplied, it all falls within the requirements of the RFC.

I checked through the Microsoft knowledgebase and couldn't see anything immediately but the issue is definitely with the receiving server.

Cheers

Dave

Still a problem:
But you don't seem to ensure that the 100 character limit is met!

Related rfc information:
If you have a look at rfc3885 there's a solution:
"In some cases, the total length of (local-envid + fqhn + 1) (for the
‘@’ sign) may exceed the total acceptable length of ENVID (100). In
this case, the fqhn SHOULD be replaced by the SHA1(fqhn) encoded into
BASE64. After encoding, the 160 bit SHA-1 will be a 27 octet string,
which limits local-envid to 72 octets."

Suggested solution 1:
This really should be fixed within the Outlook client, but as Microsoft haven't done that yet, I suggest the following work-around:
That Scalix should do the hash-calculation suggested in rfc3885.

Benefits of Suggested Solution 1:
1) The message can then be delivered without any servers complaining on the way.
2) If an automated reply is sent back to the sender, the Outlook client will not be able to match the reply with the original message, but the user can at least manually read it.
Especially when using Delivery Receipts, you just want to see that the delivery was ok, or not, and that message is normally replied within a minute.

Suggested solution 2:
Handle too long ENVIDs as Microsoft Exchange does, i.e. with an error response to the Outlook client:
"MAIL From:<donald.duck@mytestserver.se> SIZE=2088 ENVID=!&!AAAAAAAAAAAYAAAAAAAAAGz3vv+2BocH9Em0OJMvF9RF9igQAAEAAAAMSddsK2RvVGnvVtzkVpv9UBAAAAAA+3D+3D@mytestserver.se RET=FULL
501 5.5.4 Invalid arguments
501 5.6.0 Data format error"

Benefits of Suggested Solution 2:
1) If it works for Microsoft Exchange, so why not for Scalix...? Maybe worth a try at least?

Thanks in advance!

Regards,
/Jonas

[ScalixSupport]

Thanks for the suggestion, would like to point out however that MSFT needs to fix their own products, in this case Outlook. Makes you actually wonder why one division of MSFT needs to workaround the bugs of another division and both of them actually are symbiotic ;-)

Sascha.

[jola16]

I totally agree with you about MSFT.

It looks however as if the Oulook client understands the error responses from the Exchange server, and then reformats the ENVID.
I haven't actually looked at the traffic, but as the Outlook client seems to be able to send messages via SMTP to Exchange servers, this is my assumption.

I also have an old Postfix server that doesn't want the ENVID at all, but still the Outlook client can send messages through it. So, that adds even more to my assumption.

Regards,
/Jonas