c2c-oerpscenario team mailing list archive

[xrg <xrg@xxxxxxxxx>]

Public bug reported:

Problem is that encoding the full header (comma-separated list of
email addresses) in one =?c?...?= chunk is not properly handled by
some mail transport agents[1]. Even worse, when parts cannot fit
into one 76-char line (note that utf-8 over base64 tends to be rather
long), Postfix thinks each line is another address, that it decides
to trivial-rewrite and append domain name etc.
In another case noted, invalid chars (not properly encoded) or half-
addresses were adding to the spam-score of mails.

Solution: according to RFC 2047, we can have multiple encoded-words
(the =?.?..?= part) as any whitespace-delimited part of the header.
We /cannot/ have them inside quoted strings like "=?..?=", but need
to include the quotes inside the encoded-word.
The patch splits the address tokens to their smallest allowed "words"
and then tries to encode them one by one. Hopefully, names may need the
encoding, while emails will be pure us-ascii and will be appended
verbatim. It also includes support for one 'hint' encoding (iso8859-7 in
my case, for example) that would have shorter representation than utf-8.
Saves the day for some long names.

Note: a side-effect is that we add one space /before/ the comma when
we separate multiple addresses, like ' "Me" <me@here> , "Him" <him@there>'
It should be tolerated by the protocol, AFAICT.


[1] I've experienced it all these years we've been sending Greek names
in our From/To addresses. My maildirs are full of examples.

** Affects: openobject-server
     Importance: Undecided
     Assignee: xrg (xrg)
         Status: Fix Committed


** Tags: misc

** Changed in: openobject-server
       Status: New => In Progress

** Changed in: openobject-server
     Assignee: (unassigned) => xrg (xrg)

** Branch linked: lp:~openerp-dev/openobject-server/6.0-bug-732512-xrg

** Changed in: openobject-server
       Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/732512

Title:
  tools/misc: try harder to encode smtp address headers

Status in OpenERP Server:
  Fix Committed

Bug description:
  Problem is that encoding the full header (comma-separated list of
  email addresses) in one =?c?...?= chunk is not properly handled by
  some mail transport agents[1]. Even worse, when parts cannot fit
  into one 76-char line (note that utf-8 over base64 tends to be rather
  long), Postfix thinks each line is another address, that it decides
  to trivial-rewrite and append domain name etc.
  In another case noted, invalid chars (not properly encoded) or half-
  addresses were adding to the spam-score of mails.

  Solution: according to RFC 2047, we can have multiple encoded-words
  (the =?.?..?= part) as any whitespace-delimited part of the header.
  We /cannot/ have them inside quoted strings like "=?..?=", but need
  to include the quotes inside the encoded-word.
  The patch splits the address tokens to their smallest allowed "words"
  and then tries to encode them one by one. Hopefully, names may need the
  encoding, while emails will be pure us-ascii and will be appended
  verbatim. It also includes support for one 'hint' encoding (iso8859-7 in
  my case, for example) that would have shorter representation than utf-8.
  Saves the day for some long names.

  Note: a side-effect is that we add one space /before/ the comma when
  we separate multiple addresses, like ' "Me" <me@here> , "Him" <him@there>'
  It should be tolerated by the protocol, AFAICT.

  
  [1] I've experienced it all these years we've been sending Greek names
  in our From/To addresses. My maildirs are full of examples.