Some comments on Lua API and a key addressing scheme (in v2.0.0.Beta0)

From: Mark Martinec <>
Date: Wed, 10 Feb 2010 21:14:56 +0100

Here are some comments based on the opendkim-lua man page, but potentially
influencing the LDAP schema. I'll concentrate mainly on the LUA API here,
but looking forward to extend the topic onto LDAP in the future.

> odkim_get_clienthost(ctx)

Having access to the client's IP address (unresolved) would be useful too.

> odkim_check_popauth(ctx)
> odkim_internal_ip(ctx)
> odkim_get_mtasymbol(ctx, name)

It could make script's decisions easier if instead (or in addition to)
these partial pieces of information the main code would already digest
available information and provide information on whether a message
is originating from our users, or is inbound. Typically a message
can be considered originating if a SMTP client is authenticated
(like by SASL, POP-before-SMTP, TLS certificate), or mail is coming from
internal networks (which might be based on a list of internal networks,
or perhaps on some MTA macro/symbol), or is submitted locally at the
MTA host. I suggest something like: odkim_originating(ctx) .
An 'originating' message covers both outgoing and internal-to-internal
mail, its opposite is an inbound message. Typically only originating
messages are expected to be signed.

> odkim_get_header(ctx, name, n)
> Retrieves the string contained in instance n of the header field
> called name from the message represented by ctx, or the Lua con-
> stant "nil" if there was no such header field. Header field
> numbering starts at 0, so use 0 for the first instance, 1 for
> the second, etc. For example:
> fromaddr = odkim_get_header(ctx, "From", 0)
> This will return the value of the first (and hopefully only)
> "From" header field.

I consider the proposed indexing leading to sloppy/improper lua scripts.
There should be a way to address header fields in a bottom-up way,
instead of, or in addition to top-down indexing. Perhaps indices
-1, -2, -3, ... could be used for indexing in a bottom-up fashion.

The reason for my belief is that DKIM searches for field names
listed in the 'h' tag in a bottom-up direction. For example, consider
a malicious intercepting third party, prepending an extra From or Subject
header field. If an 'h' tag lists 'from' or 'subject' only once, the
DKIM signature only covers the bottommost occurrence of such header
field, and the signature would not be invalidated by prepending additional
occurrences. So, only the bottommost from/subject is protected by a
DKIM signature, therefore it makes most sense to base further script
decisions on such protected header field, not on the first one from
the top.

> odkim_sign(ctx, domain, selector, keyname)
> Requests that the filter sign the message represented by ctx
> using the specified domain and selector and the private key
> named by keyname. The key name will be translated into an
> actual private key via a query to the KeyTable (see the opend-
> kim.conf(5) page for details).

While the indirection through keyname seems neat, I think that inventing
a keyname is redundant, because as per DKIM definition public keys are
naturally and uniquely addressed by a selector and domain (through DNS).
As there is a one-to-one relationship between public and private keys,
I think that what is now referred as keyname can just as well be
represented by a "selector:domain" or some such string, taking away
the redundancy.

Giving an admin the power to specify a signing key independently from
a (selector,domain) pair can lead to generating signatures with no
matching published public keys. Rather than providing some additional
safeguards and tests against this happening, it is preferable to
devise an API and/or a database schema in such a way that the situation
cannot occur at all.

So I propose that the mapping goes like this:
  author address -> (selector,domain) -> private key -> signature
instead of:
  author address -> keyname -> private key

Having signing keys in a database indexed by their (selector,domain)
pairs also naturally leads to ability to generate a DNS zone representation
of public keys from the same database, without risking 'dangling references'.

> odkim_sig_ignore(sig)
> Instructs the verification code to ignore completely the signa-
> ture specified by sig, previously returned by a call to
> odkim_get_sighandle(). Any pending verification of the message
> will act as if that signature was not present on the message.

I don't see a purpose in this. A missing (ignored) signature is
equivalent to a failed signature. What good does it do to ignore
a signature? I can understand it makes perfect sense to ignore
(or override) an ADSP result, but why invalidate a signature?
If some signature has no reputation value to a signer, it just
does not use such reputation in its reputation decisions.

> odkim_add_rcpt(ctx, addr)
> odkim_del_rcpt(ctx, addr)

I understand this maps directly to how a milter protocol works,
but if there is any chance of being able to replace/rewrite a recipient
address in place, keeping it in its current position in the list,
it would facilitate reliably redirecting deliveries (given a possibility
of having the same recipient address listed more than once, and also
avoiding reordering).

> odkim_get_policy(ctx)
> Returns the discovered Author Domain Signing Practices (ADSP)
> policy, if one was published and could be retrieved.

Keep in mind that a message with multiple author addresses in a From
header field has multiple ADSP policies.

> odkim_get_policy(ctx)
> odkim_get_presult(ctx)

These two could be merged into one, returning one of

> setup The setup script is run after all headers for the message have
> been received but before any DKIM operations have started. At
> this point the user can examine the available header fields to
> decide whether the message should be signed or verified (or
> both) and, if signing, which key(s) should be used to add signa-
> tures and which signature features are desired.

Somehow this need to decide aforehand whether a message will be signed
or verified (or both) rules out the possibility of making a signing
decision based on results of verification on existing signatures.
This would be handy with remailers / mailing lists.

Received on Wed Feb 10 2010 - 20:15:12 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:19:46 PST