On Thu, Jan 09, 2014 at 01:39:27AM +0100, Michael Neumann wrote:
> Hi there,
Hi!
> I have a question regarding the table API for external services like
> Postgresql etc.
> Please correct me if I am wrong. So far I understand the purpose of the
> callbacks as follows:
>
> * UPDATE - recheck configuration file
>
> * CHECK - just check for the existence of a key. Only returns -1, 0 or 1,
> i.e. failure, not found, found.
>
> * LOOKUP - that returns actual data, e.g. "user_id:password" etc.
>
> * FETCH - *That's where I am not sure*. It caches the rows of a table within
> a dictionary (which it
> updates every once in a while) and returns tuple after tuple upon each
> call to e.g.
> table_postgres_fetch. I.e. this function is called many times. This is
> only used for K_SOURCE, i.e.
> netaddr tables. This kind of lookup fails for a large number of entries.
>
> I was planning to add support for redis tables to opensmtpd and use it to
> reject based upon the sender's IP,
> similarily to what DNSRBL is doing. But this seems to be not possible with
> netaddr tables right now, unless
> it's rewritten a bit, i.e. to first issue a CHECK to the table, followed by
> a FETCH. Would a change like that
> be accepted, is it useful?
I am not sure to understand what do you mean. FETCH is only used by
the mta to retrieve an ip address to use when connecting.
It is currently not possible to do IP filtering at the connection level.
We need finish the filter API (yeah, we slacked a bit on this).
For now, you can also solve your problem with something like:
table redis-bl redis:<redis.conf>
reject from source <redis-bl>
or
accept from source <redis-bl> for any virtual { "@" "error: 550 Sorry,
you are blacklisted" }
The only issue is that filtering occurs at SMTP transaction time, not at
connection time.
But that's probably a good compromise.
Eric.
--
You received this mail because you are subscribed to [email protected]
To unsubscribe, send a mail to: [email protected]
