CiviMail 2.2: Changes for third-party developers

Along with the introduction of CiviMail Processor as the new supported return email hander, we’ve made three changes that are relevant for third-party CiviMail developers in CiviCRM 2.2. Unified email formats From CiviCRM 2.2 on, we’ve unified the format of the ‘action’ email addresses used in CiviMail. The new format is a.1.2.1234567890123456, where a is a one-letter symbol for the action to be performed (b for bounce, c for confirm, e for resubscribe, o for opt-out, r for resubscribe and u for unsubscribe), followed by two ids relevant to the action, followed by the 16-digit hex hash – all separated by dots. This means that all CiviMail-bound emails might should now match (b|c|e|o|r|u)\.(\d+)\.(\d+)\.([0-9a-f]{16})@ Note 1: In the case of the subscribe action, which only takes the group id, the format will be s.7.0.0000000000000000@ Note 2: We dropped the VERP-encoded receiver address (sitting previously between the hash and the @) as both unnecessary and sometimes causing the whole action address to exceed the allowed limits. Note 3: When constructing your own regular expressions, remember that the action can be now prepended with localpart (more below). If you have any questions on how the formats relate to each other, please ask away and refer to the way CiviMail Processor handles both old and new address formats in bin/CiviMailProcessor.php. Localpart support CiviMail 2.2 also introduces localpart support. Most email servers can be configured (or are by default – like Postfix and whatever Gmail uses) to treat emails addressed to address+anything@example.com as if they were addressed to address@example.com. This means that instead of hacking your own Postfix install, you can now use any such account and simply configure CiviMail to have a localpart of address+ – this way bounces will be directed to address+b.7.9.1234567890123456@example.com and will simply end in the address account, to be handled by the return channel handler (be it CiviMail Processor or imap2soap). Reply handling To address CRM-2959 we’ve created a new parameter to the reply handling API and SOAP calls. If instead of the text and HTML body parts (fourth and sixth parameter, respectively) a new, seventh parameter is passed to the call, it will be treated as the full body of the email to forward. This is desirable as it both fixed the above bug and properly forwards attachments, etc. Fortunately, PHP has this interesting idiosyncrasy of ignoring tailing arguments to function calls which do not expect them, so this parameter can be also safely passed to pre-2.2 CiviCRM instances (which will simply use the text and HTML parts instead of the full body until upgraded).

Filed under

CiviCRM

CiviMail

Comments

Elegant solution, but ...
* what's the limit on email size?
* does this expose CiviCRM to buffer overflow attacks?

Ken

to handle all incoming email, so this might be a better question on thier forums (ez.no)

also buffer overflow is typically a compiled language issue. most scripting languages are insulated from memory issues

lobo

Use CiviCRM? Like CiviCRM? Then show your appreciation and <a href="http://civicrm.org/donate">donate to CiviCRM</a>

Contrary to the post, in my experience, postfix does NOT default to allowing a localpart username combo address.

I had to edit

/etc/postfix/main.cf

and uncomment:

recipient_delimiter = +

YMMV.