Am 09.01.2014 06:48, schrieb Eric Faurot:
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.
So FETCH returns the IP addresses used in "listen on" ?
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" }
That is exactly what I wanted to accomplish, but I was unsure if the
K_SOURCE service is related to the reject from "source".
The only issue is that filtering occurs at SMTP transaction time, not at
connection time.
But that's probably a good compromise.
I think filtering is the way to go as it can do much more than just
simple address checks.
Thanks for you answers.
Regards,
Michael
--
You received this mail because you are subscribed to [email protected]
To unsubscribe, send a mail to: [email protected]
