Re: [imp] 8-bit transfer (was: IMP, Outlook and Hotmail)

Quoting Joseph Brennan <[EMAIL PROTECTED]>: >> Read RFC 2822 > > OK. Sec 2.1, second para, says > >Note: This standard specifies that messages are made up of characters >in the US-ASCII range of 1 through 127. There are other documents, >specifically the MIME document series [RFC2045

Re: [imp] 8-bit transfer (was: IMP, Outlook and Hotmail)

Quoting Tim Bannister <[EMAIL PROTECTED]>: >> Quoting Otto Stolz <[EMAIL PROTECTED]>: >>> Michael M Slusarz schrieb: >>> Have to laugh at this one because *this* message is broken. 8bit transfer encoding is not allowed by RFC. >>> >>> 8bit transfer encoding is allowed per RFC 1652 >>> <

Re: [imp] 8-bit transfer (was: IMP, Outlook and Hotmail)

> Read RFC 2822 OK. Sec 2.1, second para, says Note: This standard specifies that messages are made up of characters in the US-ASCII range of 1 through 127. There are other documents, specifically the MIME document series [RFC2045, RFC2046, RFC2047, RFC2048, RFC2049], that extend th

Re: [imp] Latest RC testing with DIMP

Quoting Michael M Slusarz <[EMAIL PROTECTED]>: > Quoting "John H. Bennett III" <[EMAIL PROTECTED]>: > >> In testing the latest RC candidates, I've run across three things that >> I would like others to verify before opening bug reports. >> >> In all of my application/conf.php files, I have this li

Re: [imp] problem with attachments in unicode (UTF16)

Hello, is it a solution to map certain extensions to the correct mime types (not perfect but enough for me). e.g.: .rdp --> Content-Type: text/plain; --> Content-Transfer-Encoding: base64 .sav --> Content-Type: text/plain; --> Content-Transfer-Encoding: base64 best solution: via a co

Re: [imp] 8-bit transfer (was: IMP, Outlook and Hotmail)

> >> Have to laugh at this one because *this* message is broken. 8bit > >> transfer encoding is not allowed by RFC. > Quoting Otto Stolz <[EMAIL PROTECTED]>: > > 8bit transfer encoding is allowed per RFC 1652 > > , > > combined with RFC 2045, section 2.8 > >