Couple of days ago users came to me and asked if I could help them with an interesting case. Days passed, and I still don't have any idea.
By the way, part of this code implements AES encryption with CBC mode and padding, I would love to use AC internal functions for that, but AC doesn't support controlled AES encryption, DES only.
3. I can't use Typology Rule (Control) for this, because even at the end of analysis Delivery contains <%= recipient.email %> but not exact email. (Is MTA actually is the place where all <%= %> blocks execute?)
First of all, AES algorithm is supported through the standard Adobe Campaign API, see documentation JSAPI.chm for cryptString and decryptString, in most of objects/process of AC. And also the AESEncrypt function of the XTK, used by calculated cryptString in nms:recipient schema (see below).
Yes, you are right, 3DES is supported but deprecated.
Then, first solution of implementing a specific attribute in the custom extension of nms:recipient can be considered if your main reason is performance matter, you won't calculate again and again the AES values, such as a calculated attribute in the schema (2nd alternative below). The drawback is inserting the new values for new records, with your ETL tool or your AC workflow.
However calculated attribute works fine as well, if you consider some cases it can avoid disk consumption (but most often storage is not a problem nowadays).
And it is dynamically calculated, no script for new records to fill the attribute value. And since you don't have to search/sort/transform, etc on this kind of field/attribute, indeed, calculated value can be considered in your use case.
This method is used for nms:recipient.@cryptedId (the AES value of nms:recipient.@id), the expression in the nms:recipient schema is:
See for instance another example, nms:recipient.@domain with its expr="GetEmailDomain([@email])" in the nms:recipient schema.
You can use xpath or XTK functions to write the expr.
The third solution is to not change/extend the nms:recipient schema, but achieving your specific calculation in the workflow itself, adding extra elements/attributes to your dataset.
Eventually, the choice depends on use cases, all these 3 approaches are valuable.
Extending the schema: there are no risks at all, thanks to extension mechanism of Adobe Campaign.
By the way, I am reading just now the Adobe Campaign Classic (v6/v7) and Standard (ACS) release notes, and the decryptString function is deprecated since build 8947 (last build, released on July 2018), still usable for cryptedId to be decrypted in webApp but replaced for password use by decryptPassword (not your use case anyway).
I would be glad if Adobe Campaign R&D could read this forum post and answer by their own, perhaps there is a support elsewhere or it is planned. My own skills are limited on current documentation of Adobe Campaign 6.1.1/7.0, there are possibly other ways to achieve what you need, if calculated expression in schema AESEncrypt or JSAPI cryptString/decryptString functions are not valuable for you.