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

From: SM <>
Date: Wed, 10 Feb 2010 22:43:54 -0800

Hi Mark,

Thanks for the comments.

At 12:14 10-02-10, Mark Martinec wrote:
> > odkim_get_clienthost(ctx)
>Having access to the client's IP address (unresolved) would be useful too.

You can access that information with 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.

These functions provide fine-grained information. It would be easier
for the user to have a function that flags whether the message's
origin is internal or not. That could also be done by providing a
sample Lua script that processes the information from
odkim_check_popauth(ctx), odkim_internal_ip(ctx) and
odkim_get_mtasymbol(ctx, name).

IIRC, there is a flag in opendkim that is used to determine signing
v/s verification. That value could be exposed through a function.

>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.

The latest code has odkim_sign(ctx, keyname). "Selector/domain" is
used in the KeyTable mapping. Yes, it would be redundant to have
keyname in that function.

>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.

Yes. We came across a few cases like that. If we key on the
selector/domain, we can avoid such mistakes.

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

If I am not mistaken, OpenDKIM will be doing mapping through selector/domain.

>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'.

Yes, that was the rationale for the change.

>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).

BTW, the MTA would drop the duplicate addresses on delivery. Please
correct me as I may have got this wrong.

>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.

OpenDKIM has a RESIGN feature which can be put to use by forwarders
and mailing lists.

Received on Thu Feb 11 2010 - 06:44:33 PST

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