"Jason R. Mastaler" <[EMAIL PROTECTED]> writes:
> Tim Legant <[EMAIL PROTECTED]> writes:
>
> > The next step is to make tmda-rfilter process multiple actions and
> > then, finally, to make this whole thing work with DELIVERY.
>
> Yeah, I'll be interested to see how you do this. I can imagine some
> complications, but again I'm probably being pessimistic. :-)
First issue... logging. When we had only one possible action, we
logged it. Now that we have more than one possibility, do we want to
log the whole 5+ lines for each action we take, or is one log entry
with a line for each delivery action enough? Something like this:
Date: Sat Nov 8 13:11:00 CST 2003
From: Dr. Seuss <[EMAIL PROTECTED]>
To: Tim Legant <[EMAIL PROTECTED]>
Subj: Star-bellied Sneetches!
Actn: OK (from [EMAIL PROTECTED] ok, deliver=&[EMAIL PROTECTED])
Actn: DELIVER (from [EMAIL PROTECTED] ok, deliver=&[EMAIL PROTECTED])
I'm inclined to go with the latter, but that leaves us with at least
one question. We currently log before attempting the delivery, which
means we may log a successful delivery, fail and defer the message.
Assuming the problem gets fixed, we'll later log the same delivery
again, this time delivering the message.
The reason for that was that, in the "only one delivery" scenario,
tmda-rfilter just quit after a successful delivery. The various MTA's
deliver() functions (MTA.py) didn't return, so logging couldn't occur
after delivery. This has to change in order to support more than one
delivery, so we could conceivably log delivery successes and failures.
Second issue... What happens when we make a successful delivery but a
subsequent delivery fails? If we defer the message like we do now,
then the successful delivery will happen again, and again... until the
problem with the failed delivery is cleared up. That's not good.
We could write this so that if the first delivery attempt fails, i.e.,
if there have been no successful deliveries, we defer as we do now.
The problem only arises with a failure after a success.
MTAs keep a message in the queue until it has been sent to all
recipients or has timed out. Obviously, they keep track of which
recipients have yet to accept the message. Do we want to do the
equivalent of that? We could, using DBM files or somesuch, but that's
a lot of work for right now.
Another option is to attempt all deliveries and, if at least one is
successful, consider the message delivered. The logs would then show
which one(s) failed and, hopefully, the reason why. In the log
example I gave above, with the entire rule listed for each Actn: line,
there is no information to distinguish between two actions that both
deliver to a destination (deliver=/var/spool/shared,
deliver=~/Maildir/). If we go that route, we'll need a way to
identify each Actn: line and also a way to indicate success/failure.
Anyhow, that's what I'm thinking about now.... Any feedback would be
appreciated on these issues.
Tim
_________________________________________________
tmda-workers mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-workers
