Michael Mansour <mic@...> wrote:
> Ok, I can see there's alot I can do in this regard. None of these types of
> things (instructions or scripts or forms) are available anywhere on the net
> are they?
The man page is a good start, feel free to write an
introduction/tutorial/howto once you'll have experimented:
From greylist.conf(5):
URL checks
milter-greylist(8) is able to query external sources of
information through various URL, if it was built with
--with-libcurl. Here is an example:
urlcheck "glusr" \
"http://www.example.net/mgl-config?rcpt=%r" 5
racl greylist urlcheck "glusr" delay 15m
racl whitelist default
The trailing 5 at the end of the urlcheck definition is the
maximum number of simultaneous connexions we want to launch on
this URL. For each message, the URL will be querried, with %
format tags being sub- tituted. For instance, %r is substituted
by the recipient. See the FORMAT STRINGS section for the
complete list of substitutions.
milter-greylist(8) expects an answer containing a list of \n
terminated lines, with key: value pairs. The most basic answer to
get a match is:
milterGreylistStatus: Ok
TRUE can be used as an alias for Ok here. The answer can be
more complex, with keys that will overload the ACL settings:
milterGreylistDelay The greylisting delay to use (time unit
suffix allowed).
milterGreylistAutowhite The autowhite delay to use (time unit
suffix allowed).
milterGreylistFlushAddr The value is ignored. If this key is
present, then the IP address for the sender machine will be
flushed from greylist and autowhite databases.
milterGreylistCode The SMTP code to return (e.g.: 551).
milterGreylistECode The SMTP extended code to return (e.g.:
5.7.1)
milterGreylistMsg The string to return with SMTP codes.
milterGreylistReport The string to display in the X-Greylist
header.
milterGreylistIgnore This line will be ignored, without warnings
in the logs.
milterGreylistAction This feature is nifty but use it with
caution, as it makes the access list a bit difficult to
understand. By specifying the values greylist, whitelist, or
blacklist, it is possible to overload the ACL action itself.
The ACL will match if any of the above key is returned:
milterGreylistStatus is not mandatory.
If you use an URL check in a DATA stage ACL, you can post the
message header and body to the URL. This is done by appending
the postmsg keyword to the urlcheck statement, like in the
example above:
urlcheck "extfilter" \
"http://www.example.net/f.cgi" 5 postmsg
dacl blacklist urlcheck "extfilter" whitelist default
It is also possible to gather the properties returned by the
URL and reuse them in the ACL. This behavior is enabled by the
getprop keyword at the end of urlcheck definition. If this option
is enabled, the gath- ered properties can be accessed in the
current and following ACL by prefixing them by a dollar ($). If
the clear keyword is added, then properties will be cleaned
up before handling a new recipient. This avoids properties for
several recipients to mix. Finally, the fork keyword
instructs milter-greylist(8) to fork a separate instance of
itself for performing the queries. Use it if you encounter
thread-safety problems. fork is not compatible with postmsg.
Here is an example that will use various DNSRBL depending on
a per-recipient setting stored in the dnsrbl attribute of a LDAP
directory.
dnsrbl "RBL2" "rbl.example.net" "127.0.0.2"
dnsrbl "RBL3" "rbl.example.net" "127.0.0.3"
dnsrbl "RBL4" "rbl.example.net" "127.0.0.4"
urlcheck "userconf" \
"ldap://localhost/dc=example,dc=net?milterGreylistStatus,dnsrbl?one?mail=%r" \
5 getprop clear
racl blacklist urlcheck "userconf" \
$dnsrbl "RBL2" dnsrbl "RBL2"
racl blacklist $dnsrbl "RBL3" dnsrbl "RBL3"
racl blacklist $dnsrbl "RBL4" dnsrbl "RBL4"
Note that when matching gathered properties, format strings and
regex can be used.
> > > 4. tools to pull out relevant information from the /var/log/maillog file.
> > Did you had a look at what can be done with the stat keyword? I use
> > it to provide a web-based per-user log of what hapened to each e-
> > mail: rejected, delayed or accepted, with the sender and the reasons
> > for the decision.
> I've search through man pages for both greylist.conf and milter-greylist, I
> can't find any references to the "stat" keyword?
>
> I'm using milter-greylist 3.0
Perhaps it's time to upgrade?
From 4.0b2's greylist.conf(5)
CUSTOM REPORTS
The stat keyword can be used to specify a custom report for
milter-greylist activity. It should be supplied with an output
(either file or external command) and a format string. Here is
an example:
stat ">>/var/log/milter-greylist.log" \
"%T{%T},%i,%f,%r,%A\n"
If the output starts by >> or > then it is a file. Use >> to
append to an existing file, and use > to overwrite it. If the
output starts by a | then the output is a shell command, like in
the example below:
stat "|logger -p local7.info" "%T{%T},%i,%f,%r,%A\n"
The format string gets substituted as URL checks format string:
%r gets substituted by the recipient, %f by the sender, and so
on. See the FORMAT STRINGS section for a complete list of
available substitutions.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...