On Saturday 10 October 2009 10:44:02 Murray S. Kucherawy wrote:
> Realizing that policy decisions may become more complex as time goes on
> and DKIM grows, I'm concerned that our current model of fixed lists or
> add-on databases may not scale.
I've only considered verification policy in the below. I don't know if signing
policy is really an issue.
> I'm investigating LUA as a scripting language that could be built in to
> opendkim. I envision the filter making available to the script all the
> details about all of the signatures (if any) in a message, kind of like
> the libopendkim callback facility we have now, and then provide primitives
> like "retrieve MTA macro", "retrieve signature property", "perform policy
> query", etc.
>
> First, is this a crazy idea?
I don't think so.
Is the plan to migrate the existing policy decisions to a reference script?
> Second, anyone on the list have experience using LUA with C?
I have no experience with LUA at all. Though the testimonials of C/LUA
interface seem good.
I'm slightly concerned that the LuaSQL seems rather stagnant with the last
commits about 6 months ago with some google SOC support for firebird going on.
http://www.keplerproject.org/luasql/
Some questions about the LUA choice.
why lua?
why tie into a language? perhaps a socket interface through unix/tcp sockets
Something like:
http://www.postfix.org/SMTPD_POLICY_README.html#protocol
opendkim provides via name,value pairs into socket as they become available:
sender IP
envelope from/to
header field from/to
Message-ID
queue-id
AH results (all in email)
DKIM-signatures:
policy service reports a single response:
reject
tempfail (e.g. awaiting user whitelist response, temp database or reputation
lookup failure)
accept
redirect to mailbox
quarantine
drop
what platforms do people want to maintain support for?
what performance criteria is desirable?
what language features are required?
my answers to the prior 3 questions:
platforms: Linux, FreeBSD
performance: honestly not that concerned here. I suspect most delays are going
to be retrieval of information to support policy choices.
language features:
good database support (sqlite, mysql, postgres, MySQL, MSQL)
good client email support - generating user confirmation emails
good DNS support - blacklists
good client http/https/xmlrpc support - reputation services or other
webservices
good http server support - sending internal user's web links to whitelist
specific email lists/third party senders
async implementations on DNS/http information highly desirable.
async database support desirable too
Received on Sat Oct 10 2009 - 05:45:08 PST