Hello Philip,
Tuesday, October 22, 2002, 11:20:03 AM, you wrote:
>> Is that possible:
>> errors_to = ${if <some-cond> {special_error@???}{} }
PH> That's not possible. Maybe it should be. I also think that forcing an
PH> expansion failure should cause errors_to to be ignored - but that
PH> doesn't currently happen. I have made a note about that.
>> What am I doing wrong?
PH> Nothing. The feature you want just isn't there because I hadn't thought
PH> about it.
Well, what do You think about generating (forcing) empty sender
addresses in routers/transports?
The idea is that complex mail systems can have some application
entities (content-scanners, etc) that administator do not want to have
an address. They can be distingueshed, for instance, by:
$originator_uid
$received_protocol set by -oMr
etc...
Mail routing should be carried out according to general site logic,
but some senders should have empty address, just like normal bounces.
So, there should be the same routers with expandable sender addresses.
Not only ingnoring errors_to should be possible, but emptying it, too.
PH> However, you can work round the problem by using another feature of
PH> errors_to. It uses the address you give it only if the address can
PH> verify successfully. Otherwise, it quietly ignore is. So, if you use
PH> something like
PH> errors_to = ${if <some-cond> {special_error@???}{junk@???} }
PH> it should do more or less what you want.
I guessed something like that, but it was too hard to dig the code
yesterday. Much easier to ask gurus :)
Accorinding to the queue_only_condition, if You don't mind.
I have a couple of hours to work on it, so I want to get Your
opinion.
Is it possible to implement WishList #78? What about compatibility?
Exim booleans have different semantics than expanded strings.
The function I want to patch is queue_check_only.
BTW, if this function checks the list for queue_only_file option, only
the last one (either for smtp or not) has effect.
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
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.
queue_check_only() sets queue_only and queue_smtp, but old-style
queue_only, queue_only_file, queue_only_load(?), and -odqs will take
precedence.
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?
I'm looking forward to avoid a lot of ugly XXXX_queue_XXXX and
smtp_accept_XXXX options. I observed the WishList and think the
following:
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;
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). Another approach is to use the mentioned above
queue_only_condition global. But there should be support for
host/domain lists, mentioned in WishList #73.
So I don't see the reason for creating different ACL for this, better
extend the syntax of ACLs.
3. Some operational parameters (like current number of queue runners
spawned by this Exim instance, current number of accepted SMTP calls)
should be made expandable. They are just int's, so comparing is
possible in generic conditions.
These will make several options obsolete, and they can be removed
from Exim5 completely ;-) This is not Exim3-to-Exim4 ACLs, of
course...
Guided with some third-party kernel accounting, it's expected to
give much more stability and robustness. Our custom kernel, for
instance, has per-user limits (total number of processes, VM, etc),
and I observe periodical resource over-utilization and crashes, which
could be avoided.
Anyway, patching queue_check_only is very straight-forward, but ACLs
are complex animals.
Thank You. Waiting for Your comments. Hope that's not too much.
--
Best regards,
Peter mailto:spam4octan@highway.ru
