also sprach Wietse Venema <wie...@porcupine.org> [2009.05.23.1442 +0200]: > Before making architectural recommendations, it would help to step > back into the reality of how policy servers and milters work. For > one thing, policy servers don't handle message content, and for > another, Milters must be able to see every SMTP protocol step.
I didn't know that. Milters are then co-processes and smtpd proxies
the client commands to them, receives the milter decisions, and
reacts accordingly.
I assume that milters have the concept of an SMTP transactions,
meaning they would not like it a whole lot if RCPT was proxied
before EHLO and MAIL.
Then, there seem to be only two ways to whitelist hosts:
1. decide at connect() time whether the milter should be consulted
for this transaction at all, or maybe decide /which/ milters
should run. I imagine this could be done with a hash/cidr_table
lookup on the client IP, where the hash value is the set of
milters to run. $smtpd_milters would then take a list, or
a table, and an existing setup of $smtpd_milters=foo,bar could be
migrated by using e.g. a cidr_table entry like
0.0.0.0/0 foo,bar
2. Each smtpd_*_restrictions class could get an entry similar to
map_milter_decision, which is an identity map by default, but
could be overridden to make e.g. a REJECT into a DISCARD at this
stage of the SMTP transaction. Connections from whitelisted
clients could be routed to an overriding map of this kind with
smtpd_restriction_classes.
Are there other problems with these approaches I am currently not
seeing?
--
martin | http://madduck.net/ | http://two.sentenc.es/
"women, when they are not in love,
have all the cold blood of an experienced attorney."
-- honoré de balzac
spamtraps: madduck.bo...@madduck.net
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
