> Am 13.09.2016 um 16:51 schrieb Wietse Venema <wie...@porcupine.org>: > > Christian Ro??ner: >> Hi, >> >> I just looked into the socketmap_table man page. I try to understand several >> things: >> >> First: Is it correct that request and response are not terminated by newline? > > I think that is the least of your problems. > > This is not a text-based protocol where messages are terminated > with some end-of-line character. > > Instead this uses netstrings, which encode message boundaries with > byte counts. You may have some additional coding ahead of you. > >> Second the respone: >> >> OK <space> data >> The requested data was found. >> >> NOTFOUND <space> >> The requested data was not found. >> >> TEMP <space> reason >> >> TIMEOUT <space> reason >> >> PERM <space> reason >> The request failed. The reason, if non-empty, is descriptive >> text. >> >> Which of these return values do work with postscreen_access_list? > > None of them. The OK, NOTFOUND, etc. are part of the socketmap > protocol. They are never visible to the postscreen_access_list. > >> Could someone give me an example please :-) ? > > You need ti distinguish between: > > 1 - Table-driven mechanisms, for example, transport_maps or > postscreen_access_list. These use simple key-value API that > is exposed by things in [2]. > > 2 - Table lookup mechanisms, for example, hash, mysql, or socketmap. > These expose a simple key-value API that is used by things in [1]. > > Under the covers, table lookup mechanisms encapsulate those > keys and values as "name <space> key" or "SELECT 'foo' FROM > bar" depending on whether they talk to a socketmap server or > to an SQL server, but that is never visible to things in [1]. > >> As the response tokens are not described in detail, I ask for help here. > > They are. You just need to combine the postcreen_access_list > documentation with the socketmap encapsulation. > >> OK <space> permit (or dunno) >> NOTFOUND <space> >> TEMP <space> What is done with this reason? > > It is up to the table-driven mechanism to report it as a warning > or to report it as a fatal error.
The background to my question is that I already implemented a fully working tcp-map-driven service for postscreen and I just thought about switching it to socketmap, if socketmap would give me more choices for replying. But as I guess that "reject", "permit" and "dunno" are the only possible results, this switch seems useless. What I miss is something like "defer" Thanks anyways for helping me to understand this map. Christian -- Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345 USt-IdNr.: DE225643613, https://www.roessner-network-solutions.com
smime.p7s
Description: S/MIME cryptographic signature
