On 07/20/2011 12:21 PM, xrg wrote:
> Two comments:
> 1. I wish all this (added) code could be in an addon, rather than the
> server.
> Shouldn't we try to keep the amount of server code minimal?
My "bzr lp-propose" test didn't work as expected, or I would have
included the summary of the changes and the rationale in the MP
description. (this is a WIP MP, remember)
Roughly, the idea of the refactoring is to clean up our various stack of
emails. There is a corresponding branch for addons of course.
Currently we have:
- low-level code for sending emails in server (tools.email_send),
depending on global config parameters for the SMTP params (no per-db
settings)
- code for sending and storing emails in mail_gateway module, using the
low-level code of the server for sending, and custom code for receiving
- code for sending (using queuing and a scheduler) and storing emails in
email_template module, using custom, configurable, per-db SMTP settings,
and a separate model for storing them
- lots of different mail-sending wizards for in addons: crm,
mail_gateway, email_template, etc...
So our goal is to achieve the following:
- one unified way of sending and storing messages across all addons
- possibility to have per-db SMTP settings, used by all addons
- features would be provided incrementally by higher-level addons:
+ basic server support (SMTP config and direct send, no storage/queue)
+ 'mail' addon adds common mail storage, generic composition wizard,
generic mail storage, and scheduler for queuing outgoing mails
+ 'email_template' adds templates but reuses the other's features for
sending,storing,queuing. Extends composition wizard with templates.
+ other mail-conscious modules like 'crm' add their own extensions
and/or inherit the composition wizard for their own needs
(The above should have been part of the description of this MP)
> 2. Please avoid utf-8, especially at header (email address) fields.
> Transport
> agents like Postfix (yes, that one) do bad things when they need to deal with
> split lines, and escaping utf-8 makes that even more possible. Instead, a
> "local" charset should be tried first (like iso8859-1 in your case, -7 in my
> case). 8-bit encodings tend to work much better (and make readable mails)
> than
> escaped utf-8.
I agree that we need to be more careful when setting the values of the
various email headers, not just the subject. RFC2822 assume headers are
7-bit only, so we *need* to properly encode non-ASCII content as 7-bit.
The default RFC2047 behavior of Python's email.header module seems fine
for this task [1]. RFC2047 is relatively old and well supported by most
software, including Microsoft's Exchange and Outlook.
Still, I would prefer to only use RFC2047 encoding when there is
non-ASCII content in a header, and currently the email.header.Header()
class with use RFC2047 encoding all the time, giving for example:
Subject: =?utf-8?q?hello?=
That should not cause trouble, and it takes the precautions to perform
appropriate line folding, but still seems useless.
Any suggestion on how to smartly detect that we have a string
representing non-ASCII characters, except via a dumb try/except that
relies on the fact that we use utf-8 strings exclusively and that utf-8
encoding is identical to ASCII for 7-bit values?
try:
header_text.decode('ascii')
return True
except UnicodeDecodeError:
return False
As for using 8-bit local encodings in headers, that really looks like a
bad idea, as it's not allowed by RFC2822, and would work only if _all_
the MTA/MTA support that encoding in headers, up to the final recipient.
Email recipients are not limited to parts of the world who use the same
default local encoding as you, so I don't see the point of having that
heuristic for something that will fail in many cases.
Or did you mean this in another sense?
BTW, when you write 'escaped utf-8', do you actually mean
RFC2047-encoding using UTF-8 encoding?
Finally, having all that code factored out in ir.mail_server will make
it a breeze to maintain and fix encoding issues in one single place! :)
[1] http://docs.python.org/library/email.header.html#module-email.header
--
https://code.launchpad.net/~openerp-dev/openobject-server/emails-framework/+merge/68500
Your team OpenERP R&D Team is subscribed to branch
lp:~openerp-dev/openobject-server/emails-framework.
_______________________________________________
Mailing list: https://launchpad.net/~openerp-dev-gtk
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openerp-dev-gtk
More help : https://help.launchpad.net/ListHelp
