> Am 13.09.2016 um 17:11 schrieb Viktor Dukhovni <postfix-us...@dukhovni.org>: > > On Tue, Sep 13, 2016 at 05:00:01PM +0200, Christian Rößner wrote: > >>> 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. > > Don't confuse the socketmap layer protocol which can find, not find or > tempfail a lookup, with the Postfix syntax for the lookup result, which, > depending on context access(5), header_checks(5), ... > may begin with various keywords such as: > > OK > DUNNO > REJECT > DEFER > WARN > > or just some address or transport spec as with virtual(5) or transport(5).
Yes I know. But the "map"-logic must be somehow interpreted by the calling option. So for tcp-map I found out that I need to send 200 <space> dunno <newline> or 200 <space> reject <newline> to get the wanted results from postscreen_access_list I looked for the same syntax in socketmap (knowing that it needs to be encoded). But at the end I can stay with tcp-map, as the postfix option in postscreen itself does not know more than the described responses. Is there some chance that postscreen could be extended to also have "defer"? If you use a dynamic service like tcp-map, decisions might be not black or white and therefor reject or dunno (or permit) might not be enough. I use postscreen with a tcp-map, as I can quickly decide just before asking remote DNS black lists. If I had a "defer" I might have some internal TTL like greylisting capability in a tcp-map-service. Thanks 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
