To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=77449
------- Additional comments from [EMAIL PROTECTED] Mon Jun 4 09:11:50 +0000 2007 ------- offapi/com/sun/star/mail/XMailMessage.idl:1.4 is vague on what format the SenderAddress string attribute must have. Lets assume it must be a single mailbox (see RFC 2822 for terminology) instead of a mailbox-list, as in the latter case the generated message would need to contain a Sender header, but XMailMessage leaves it open what that should be. Then, the format can be either a true mailbox (i.e., name-addr / addr-spec) or just an addr-spec (i.e., local-part "@" domain). 1 If the format of SenderAddress is a true mailbox, the question is how the optional display-name (in the case of a name-addr) should be represented in the string. The only reasonable format to include arbitrary Unicode strings as display-name would be strict conformance to RFC 2822 and RFC 2047. That would put the (nontrivial) burden of creating valid input on the producer of XMailMessage instances. 2 If the format of SenderAddress is just an addr-spec, the question is how the optional display-name of name-addr should be transported by XMailMessage. Adding a string attribute SenderName as done in the attached mailmerge.nonascii.patch has the minor drawback that it cannot distinguish between no sender name given (in which case the resulting mailbox would use the addr-spec format or the name-addr format without the optional display-name) or a sender name given which is the empty string (in which case the resulting mailbox would use the name-addr format with an empty quoted-string as display-name). A better solution would be to use a SenderName attribute of type com.sun.star.beans.Optional<string>. The second solution has the advantage that it puts the burden of constructing valid RFC 2822 data on the consumer rather than the producer of XMailMessage instances. (In the hopes that the consumer is some existing software entity that is already capable of constructing valid RFC 2822 data, anyway.) There are two consumers of XMailMessage instances that I am aware of: First, the JavaMail API (in StarOffice-only code). The documentation is again not too precise, but I would assume that using javax.mail.internet.InteretAddress constructor InternetAddress(msg.SenderAddress) when not msg.SenderName IsPresent or InternetAddress(msg.SenderAddress, msg.SenderName.Value) otherwise would do what we want. Second, scripting/source/pyprov/mailmerge.py:1.7. I have little knowledge of Python and no knowledge at all about the Message/MIMEMultipart/sendmail functionality used there. However, I assume that the solution in the attached mailmerge.nonascii.patch is too simplistic, in that it does not take care to format sendername into a valid RFC 2822/2047 phrase (does it also have to take care of RFC 2822 line length limits?). In case the patch needs to be corrected: tools/source/inet/inetmime.cxx:1.12 more-or-less contains the necessary logic in C++ (whether or not that is useful here), and I have no idea whether the ncessary functionality is already available in some Python library. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
