[Lift] Re: Ticket #19 (mail and character encoding)

2009-03-18 Thread Derek Chen-Becker
OK, I tested locally and it works for me. I just pushed to master and it should show up in Hudson soon. Derek On Tue, Mar 17, 2009 at 1:52 PM, Derek Chen-Becker wrote: > OK, new code is checked in on wip-dcb-mailer-charset branch. Does anyone > have time to test? > > Derek > > > On Tue, Mar 17,

[Lift] Re: Ticket #19 (mail and character encoding)

2009-03-17 Thread Derek Chen-Becker
OK, new code is checked in on wip-dcb-mailer-charset branch. Does anyone have time to test? Derek On Tue, Mar 17, 2009 at 2:39 PM, Derek Chen-Becker wrote: > This is strictly MIME, so the plain text "part" of the message will have an > explicit charset associated with the text. The JavaMail fram

[Lift] Re: Ticket #19 (mail and character encoding)

2009-03-17 Thread Derek Chen-Becker
This is strictly MIME, so the plain text "part" of the message will have an explicit charset associated with the text. The JavaMail framework is very flexible in terms of what you can send, how it's encoded, etc, but Lift's interface only exposes a small subset appropriate for sending either text e

[Lift] Re: Ticket #19 (mail and character encoding)

2009-03-17 Thread Marc Boschma
It depends upon what is meant by "plain". According to RFC 2045 (5.2) the default character encoding for a non-MIME message is us-ascii and the transfer encoding would be 7bit. Given that I think we are speaking of MIME encoded messages I think that the default of UTF-8 is ok in a lift conte