Stan Hoeppner:
> It appears I did understand Giovanni's need correctly. He should be
> able to use Sahil's checkdbl.pl daemon with some modifications. He'd
> simply check that X-custom-header exists. If it doesn't,
Wietse:
> header_checks can't detect missing headers.
Stan Hoeppner:
> The headers are sent to the TCP server daemon one line at a time, IIRC.
> Is it not possible to simply code the daemon to a set variable, say
> our_custom_header=0, and increment it if the header exists? After
> processing all headers, if our_custom_header=0, then haven't we detected
> the absence of the header?
header_checks sends one query per header.
header_checks sends no query for non-headers including the body
text that follows after the last header.
There are two levels of abstraction in Postfix table lookups
that you appear to overlook.
Postfix is table driven, meaning it has table-driven mechanisms
such as header_checks or aliases, and it has table lookup mechanisms
such as hash and pcre.
This is possible because table lookup is based on a simple (key,
value) interface, and because the same interface can be used with
all table mechanisms: hash, btree, pcre, cidr, tcp, ldap, *sql.
- The key is the search string.
This key either used "as is" with hash, btree, pcre, cidr, tcp;
or it is embedded in some blob as with ldap, *sql, but that
happens under the universal (key, value) interface level, and is
invisible for table-driven mechanisms header_checks or aliases.
- The value is the result or an error (not found, database error).
So yes, you can implement counters in the code that receives the
query, but there exists no query that will retrieve that counter,
or that will reset it. Again, Postfix table driven mechanisms must
use the same table lookup interface regardless of the underlying
table implementation, or else the whole thing is worthless.
Wietse
