On Thu, 24 Oct 2002, Nico Erfurth wrote:
> On Thu, 24 Oct 2002, Dean Brooks wrote:
>
> > I know this may seem like an odd question, but I am curious if there
> > is a way to store routing information if a message transport defers
> > for later delivery.
>
> AFAIK not.
That is correct. There is no memory between deliveries. Exim was
designed for an environment where most (> 90%) of messages can be
delivered immediately.
> > Specifically, we have a lot of local deliveries that get deferred
> > by the appendfile transport for being over quota. Sometimes we
> > have thousands and thousands on the queue.
So, in effect, you are storing messages until some condition is true.
This is the same kind of thing as storing messages until a dial-up host
connects. Exim was not designed for that environment. If the queue gets
very long (for whatever reason), Exim's efficiency will drop, because it
scans the whole queue for each queue run. That is why some large sites
use fallback delivery hosts, so the main hosts don't have long queues.
The recommendation for holding mail for dial-up hosts is to hold it off
Exim's queue. The same recommendation would work here (as was already
pointed out). Of course, you could also be harsh, and just bounce
messages immediately when users are over quota, but maybe you don't want
to do that.
An alternative would be to punt such messages to fallback hosts (based
on $message_age) and let them chew slowly through the queue every now
and again.
> > The problem is that the queue-runners are rerouting *every* single
> > message, even if its the same user over and over. Not only that, but
> > it reroutes every single message *before* it can even tell if the
> > retry time has been reached. This appears to be the cause of most
> > of our CPU load on our Exim mail servers.
>
> The queued messages should be skipped if the retry time is not reached
> yet, unless you have some configuration problem.
No, they won't be skipped, because there is no retry time for the
*routing*; the retry time will be for the delivery. The routing has to
happen first so that Exim knows what delivery to do.
> > I realize the pitfalls of this: .forward files and other routing items
> > that may have changed between the initial delivery attempt and the
> > final delivery attempt will be lost, which could be confusing to the user.
>
> That's why exim does not save the routing informations,
Indeed, that's another reason (on top of the "don't normally expect to
have to retry" reason).
> > Is it normal to reroute every single message on a queue run, even if
> > thousands of the messages are to the same person, just to find out
> > if the retry time is reached?
Yes, because Exim doesn't keep any additional information about the
contents of the queue - because it's expected to be short. Well,
actually, it does keep the list of messages routed to specific hosts.
But it uses that to find messages, not to skip them. To keep the sort of
information you are suggesting would be quite complicated, because you
have to handle the case when one message is addressed to two people,
both of whom are over quota.
As Sheldon pointed out, if you were able to keep a database of users who
are over quota, you could use a queryprogram router - or possibly just
some appropriate "condition" setting - to force a defer at routing time.
Then the retry time would kick in for routing - but Exim would still
have to examine every single message, to see who the recipients were,
before deciding not to route some of them. You might not gain very much
at all, and you wouldn't have the benefit of being able to specify a
separate "over quota" retry rule.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
