Hi Erik, Andy,

Thanks for the suggestions! Let me check out some other options too. I am quite hesitant to modify the users' e-mails though (adding Received: lines not counted! :P ) but may end up doing so if I am left with no choice.

Cheers.

On Mon, 16 Jul 2007, Erik Kangas wrote:

Hello,

For messages with missing "MIME-Version:" you could also just detect this and add that header via procmail before message delivery to the folders --- if you use procmail. This is what we do at LuxSci.com for this case.

-Erik Kangas

Andy Lyttle wrote:
Tan,

You may be interested in a piece of software called MIMEDefang (http://www.mimedefang.org/). It basically interfaces with your SMTP server (Sendmail etc.) and automatically fixes broken stuff for you as the messages arrive, so imapd shouldn't ever see messages that don't obey the RFCs. I think the main goal is so maliciously crafted messages can't exploit a security hole in your MUA, but it might solve your problem as well, and if you know perl, it's very customizable and can do all kinds of crazy things.

Hope this helps!

~ Andy


On Jul 15, 2007, at 1:13 AM, Tan Shao Yi wrote:

On Sat, 14 Jul 2007, Mark Crispin wrote:

On Fri, 13 Jul 2007, Tan Shao Yi wrote:
Content-Type: text/html; "charset=iso-8859-1"
...........................^..................^

Those double quotes are the problem. They are completely bogus syntax, and prevent the parsing of the CHARSET attribute.


Hi Mark,

I removed the double-quotes and the e-mail is still not displayed correctly. However, with the "MIME-Version: 1.0" added, the e-mail displays correctly in both IMP and Pine.

Is there something I am doing wrong?


Assuming that you actually care about reading those messages, and they are not spam, the only reasonable recourse is to tell the individuals who manage the optionetics.com system that they need to comply with the published MIME protocol specifications and not guess at what constitutes valid MIME.

On a practical basis, it is impossible to make a parser comprehend every possible invalid syntax that is dreamed up by some lazy individual who refuses to follow the specifications. Equally important, well-intentioned code to parse some invalid syntax is likely to have the unexpected side effect of mis-parsing valid syntax.


The difficulty that I am facing is that there are many of such broken mailers around (most of them appear to be newsletter applications) making it almost impossible for us to request them to fix their applications.

What makes it even more difficult is that usually other e-mail clients like Outlook Express, Thunderbird and even Gmail are able to parse them correctly. This makes it extremely difficult to convince these individuals to comply with the published MIME protocol specifications, and we usually get a retort like: "It works in (client X) but not yours, so it's clearly your problem." :(

Cheers,
Tan Shao Yi
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw


_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

Reply via email to