John Schmerold wrote: > That, of course is one of the reasons I wrote, I suspect we could do > better. An obvious area for our situation is to deny based on > recipient email address (if we don't exist, why are we accepting mail > for them). >
That IS a big one, yes... > This box is a filter for several clients using mail servers that > include Exchange, cPanel, Groupwise & Vmailmgr, so configuring > recipient addresses is easier said than done. > But well worth it... We use a single DB instead of a complex verify-mode router-walk. Arguably less efficient to do an SQL call than walk Exim routers, BUT - there is just ONE place to look or 'maintain' (even 'postmaster' has an entry there, as do our valid MLM input addresess). ..and there are *many* ways to grab the data from all manner of disparate input sources and formats and suck it into the DB. > We're using several (probably too many) rbls, that helps, guess > greylisting is next. > BT, DT, GGTS. But a simple 15-second delay whenever a 'fault' is hit (else NOT) has been just as effective, and with no discernable delay on decent traffic.. Seems a goodly number of 'modern' zombots are programmed to not waste 'their' time on recalitrant victims.... W/R rDNS fail, HELO mismatch, RBL 'hit', header format and mime faults - generally too much 'falsing' if used as pure go no-go. Instead, you can give these each weighted 'demerit' scores based of severity, carry them about in bespoke and/or cumulative acl_c(n), transfer to acl_m(n), do gt/lt/eq testing against system-wide, per-domain, or per-user tolerance levels. HTH, Bill -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
