https://bugs.exim.org/show_bug.cgi?id=2282
--- Comment #3 from Jeremy Harris <jgh146exb@???> ---
This is becoming a separate issue from supporting rspamd as a spam (or
malware?)
ACL condition. Possibly both highlevel support and toolset methods are needed.
For the "socketwrite that speaks SSL" perhaps an ssl option on the ${readsocket
}
expansion would be a good thing to have lying around?
For lowlevel ACL access to JSON, inbound: we could do json-source options on
${extract } - where the key-value variant gives access to named members of a
JSON
object, and the numbered variant gives access to members of a JSON array.
Issue: should the result of such an expansion be an Exim string, or a JSON
object? The latter means more complex usage but maintains the richness - eg.
an additional expansion could give access to the json-type of the object.
Alternate: we maintain the JSON variable type internally for the ${extract }
result, but convert to an Exim string when needed by context of usage.
Corollary:
the encoded version of a complex JSON object is just the Exim string-value for
it. Resulting issue: how do you see the encoded version of a simple JSON
datum?
Issue: do we need outbound methods, constructing complex JSON objects?
--
You are receiving this mail because:
You are on the CC list for the bug.
