Susan, I'm sorry but we are not going to change the server because a vendor thinks that a bug in their code requires us to change perfectly correct code. We disagree with their belief that a robust MIME parser is one that works around their bugs and do not consider this change an enhancement of any sort.
Since the source is freely available, you are more than welcome to make the change in order to get things deployed on your end and announce the availability of the patch on this mailing list. Walter Susan Feng <[EMAIL PROTECTED]> writes: > ISSUES > > Messages sent from Eudora client (5.1 for Windows) with "Styled and Plain" > attachment cannot be read by Euodra and Netscape clients. These two clients > only see messages headers; attachment either cannot be dowlnoaded at all, or > shows up as garbled messages. Same message is readable from Outlook, Outlook > Express, silkymail, Mulberry etc. > > ROOT OF THE PROBLEM > > We have been working with Qualcomm technical people, we reached the conclusion > that Eudora client for Windows generates MIME boundaries that aren't comply to > RFC. Here is one example: > > Content-Type: multipart/mixed; > boundary="=====================_17866911==_" > --=====================_17866911==_ > Content-Type: multipart/alternative; > boundary="=====================_17866911==_.ALT" > --=====================_17866911==_.ALT > Content-Type: text/plain; charset="us-ascii"; format=flowed > > Another test > --=====================_17866911==_.ALT > Content-Type: text/html; charset="us-ascii" > > <html> > <font size=6 color="#800080">Another test</font></html> > --=====================_17866911==_.ALT-- > --=====================_17866911==_ > Content-Type: application/octet-stream; name="SOC edits.doc" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; filename="SOC edits.doc" > > [snip attachement data] > --=====================_17866911==_ > Content-Type: text/plain; charset="us-ascii"; format=flowed > > --=====================_17866911==_-- > > It seem that the problem is with the boundary numbers, they are all the same > for different MIME parts. > > CURRENT STATUS > > Qualcomm fixed future release (5.1.1) so Eudora for Windows will generate > proper boundaries, but it is only fixed in "sending" part. Reading code is not > changed, which means we will still face problem if a message is sent from old > Euodra 5.1. > > I posted this message here hoping that this is some thing can be patched or > fixed at the Cyrus server side. Here is an email from Qualcomm: > > I asked: > > >1. Is the problem fixed in both the receiving code or sending code, or both? > > Reply from Qualcomm: > > Sending. > > The IMAP server is the problem in interpreting the current headers. > Yes, they are technically illegal boundaries and we are correcting > them. However, their meaning is quite plain and unmistakable, and it > is well within the bounds of a robust MIME parser to deal with them. > The only time the violated rule really is needed is if you are using > a Content-Transfer-Encoding of "binary". > > I suggest that you work with Cyrus to enhance their parser to deal > with the illegality. Then all copies of Eudora will be fine. > > So what's the take? Any chance this can be "fixed" at the server side? > > We have been working on a project to provide IMAP service for Stanford > University, this Euodra attachment problem becomes a major obstacle. Any > suggestions or help you can provide would be much appreciated. > > Thanks, > > Susan Feng > > ITSS > Stanford Unviersity
