Husk is a milter ("mail filter"). When registered with an MTA every passing email is forwarded to the milter, which can modify its content before giving it back to the MTA for further processing.
For each email passing, Husk will check the recipients of that email and when it finds a valid and authenticated certificate, it will encrypt that email.
Husk uses OpenPGP and leverages its features. Husk avoids maintaining an own set of metadata of its certificates.
An authenticated certificate is a certificate with User IDs which are valid, meaning that the certificate actually belongs to the User ID and is not an impersonation.
To persist the information about authenticity, a certificate gets certified by another certificate, which means that the keyholder of that other certificate vouches for its authenticity. This certification becomes part of the vouched certificate and is published with it.
As the keyholder of the certified certification can use that certificate to certify other certificates a chain gets created. The certificates are the nodes, the certifications are the edges between these nodes. These edges have attibutes which further classify the relationship of the nodes connected by this edge:
A certificate is considered authenticated if there is a path from a trusted certificate to that certificate. The trusted certificate can be any certificate, but usually it's a dedicated "special" certificate (the local trust root).
The traversal of the path starts with a certain thrust depth - usually the highest possible value. With each edge the trust depth is decreased by one and compared with the trust depth of the certification - the minimum of these two values will be used from there on. The traversal ends when a trust depth of zero or the certificate in question is reached.
If a path can be established, the minimum value of all trust amounts of the edges is taken, for a certificate to be considered, the resulting trust amount has to be higher than a predefined threshold. If there are a couple of independent paths, the one with the highest trust amount is used.
Edges on the path can have a regular expression. If a certificate is encountered which has no User ID matching this regular expression, the traversal ends. That way a certification can be limited to a set of domains.
Certifications usually carry a trust depth of zero, meaning that the certificate on the other end of an edge is authenticated, but certificates further down the path are not.
Certifications carrying a trust depth of one are creating trusted introducers, as the certifications made by the certificate of the other end of the edge will be taken into consideration.
Husk uses the concept of trusted introducers combined with regular expressions to delegate the authentication, thus reducing the maintenance effort needed to establish a larger set of usable certificates. Idealy an administrator only has to configure a set of trusted introducers.
For each recipient of an email processed Husk checks if there an authenticated locally available. If not, but a trusted introducer for the domain of the recipient exists, Husk queries the internet (Keyservers, WKD, DANE) for certificates of that recipient - if a certificate is returned which is certified by the trusted introducer, it will be stored locally and used for this and future emails.
If for all recipients an authenticated certificate is available, the email will be encrypted and passed back to the MTA. If no certificate is found, the email will not be modified - Husk implements opportunistic encryption.
If only for a subset of recipients certificates can be found, Husk will produce a second email for all recipients where encryption is not available.