On Tue, 22 Oct 2002, Peter A. Savitch wrote:
> Well, what do You think about generating (forcing) empty sender
> addresses in routers/transports?
I have noted the idea. You can already do it in filters by using the
"noerror" keyword, and you can already use "-f <>" when submitting
messages, so I see no reason why it should not also be available via
errors_to.
> Is it possible to implement WishList #78? What about compatibility?
> Exim booleans have different semantics than expanded strings.
There is no problem with queue_only_file. With queue_only I would have
to think about it. Maybe some other option will be needed. I'm afraid I
just don't have time to think about all this very much just at the moment.
> I'm going to make the following globals:
>
> queue_only_condition -- behaves like conditional queue_only
> queue_smtp_condition -- behaves like conditional -odqs
> queue_run_condition -- behaves similar to queue_run_max
I would much rather find a way of reducing the number of options. For
example, I don't think it would be difficult to extend queue_only
without adding queue_only condition. It might need a new kind of
variable ("expandable boolean") but that could be done.
You don't need queue_smtp_condition, surely? Can't you make use of
queue_smtp_domains? Expand your condition to "" or "*" as necessary.
And there's no reason why queue_run_max can't be expanded, but what
conditions are you going to put on that? I can't see anything useful
here.
> Question: can the checks against the system load average be moved into
> queue_check_only? Which checks can not be done here? I want to move
> all possible checks into single point.
I don't know, without doing some research into the code. You are
probably right in that a single checking point would improve the code.
> Question: what should be done if string expansion fails and no
> additional data is available? Exim ignores such errors for
> queue_smtp_domains, and behaves just like domain was not in list.
> The same approach could be used for conditional queueing (not to queue
> on expansion failure). Is that correct?
You can probably argue that one both ways.
> 1. Conditional accepting of SMTP could be done with either ACLs or
> global options (WishList #56). What about acl_smtp_accept? The
> differences:
> a) this ACL is handled by the main listening process (?);
> b) when undefined, this ACL could be an implicit `accept' due to
> the SMTP nature;
I don't want to add code to the main listening process if I can help it.
I would put it in the forked process.
> 2. What about smtp_accept_queue? Implementing it within the above ACL,
> one should make additional verb `queue' or something like that (see
> WishList #103).
Yes, that makes sense.
Sorry I can't think more about this now. I am overloaded.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
