On 2003-12-23 21:30:36 +1100, Gavin Carr wrote: > On Sun, Dec 21, 2003 at 12:23:52AM +0100, Peter J. Holzer wrote: > [ per_recipient patches to denysoft_greylist ] > > A few comments: > > a. the per_recipient and recipient_options checks look fine and I'd > be happy to include them > > b. I won't be removing the whitelist checks just yet, since I'm still > to be convinced your recipient options is a superior solution > > c. I'm dubious about the value of client_options and sender_options > as yet
I'm dubious about the sender_options, too. The return-path is easy to
fake, and I currently can't think of a realistic example where I'd use
it. However, somebody may have a use for it, so I included it for
completeness.
(I just had a different idea: The lifetime of the
client_options is the whole connection, the lifetime of the
sender_options is one transaction. Would it make more sense to call them
connection_options and transaction_options? That would do away with the
notion that they necessarily have to depend on the client or the
return-path. A plugin in the rcpt hook could, for example set a
transaction_option which is used by another plugin in the data_post or
queue hook.)
> Re (c), I have a couple of question marks over these:
>
> - are you really going to want to change plugin options based on
> client address or sender, or are you just going to be turning
> certain plugins off i.e. whitelisting? If the latter, isn't a
> whitelisting approach simpler?
The former. A few things I would like to do:
* Selectively turn off some plugins depending on the client address.
For example, I may want greylisting off for some ISP's mail servers
because their queueing is unreliable, but I still want RBL checks for
these servers. OTOH for a DSL range with dynamic IP addresses, I may
not want RBL, because that would be useless (the "bad guys" get a new
address every few hours so the list is always out of date), but I do
want greylisting. I don't see how that can be done with the
whitelist_soft plugin. One whitelist-flag per plugin would be enough,
but that's not much simpler than setting arbitrary options.
* Set options on a per-client basis. For example, for my
check_content_type plugin it may make sense to allow some
content-types if they come from the internal network, but not if they
come from outside.
> - aren't you going to have to handle interactions between your
> various sets of options? e.g. what happens if a plugin is
> turned off for a sender but on for a recipient, or vice versa?
Yes. This is an open issue. In the case of distinct options for
client, sender, and recipient (as well as global options via the
config() method and register()) it is up to the plugin to combine them
in a useful manner. If there is an API (e.g. the $self->config() method
mentioned earlier in this thread) then that must combine possibly
conflicting options without really knowing what they mean, so that would
probably mean that options set in an inner scope override the options
set in an outer scope (i.e. recipient_options overrides client_options,
which overrides $self->qp->config()).
> - shouldn't whitelisting itself be per-recipient anyway? e.g.
> users should be able to whitelist clients and senders without
> that being a global setting.
Yes, but often it is useful to set global defaults. For example, several
ISPs and universities around here have seriously broken queueing. It
would of course be possible for every user to whitelist them
individually, but overall its much less work if we - the admins -
maintain a global whitelist of these mail servers.
> I'm offline for a couple of weeks after tomorrow,
I'll already sit in the train this evening, and probably won't return
until Jan. 4th.
hp
--
_ | Peter J. Holzer | In this vale
|_|_) | Sysadmin WSR | Of toil and sin
| | | [EMAIL PROTECTED] | Your head grows bald
__/ | http://www.hjp.at/ | But not your chin. -- Burma Shave
pgp00000.pgp
Description: PGP signature
