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 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
Note 1: In the case of the subscribe action, which only takes the group id, the format will be
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.
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
firstname.lastname@example.org as if they were addressed to
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 <code>address+
– this way bounces will be directed to
email@example.com and will simply end in the
address account, to be handled by the return channel handler (be it CiviMail Processor or imap2soap).
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).