"Jason R. Mastaler" <[EMAIL PROTECTED]> writes: > Tim Legant <[EMAIL PROTECTED]> writes: > > > 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 personally vote for the whole 5+ lines for each action we take. > Yes, it's a bit redundant, but it's also more clear I think. The > above example with multiple Actn: lines is confusing to me. There are > other situations where we do multiple entries rather than combining > things into a single entry, so this would follow current behavior > better as well I think. > > TMDA has clearly outgrown the current logging format, and this > something that will be reworked in 1.1, so I don't think this is a > crucial decision at this point. If one method will make other > portions of the implementation easier for you, go with that.
If we rework logging for 1.1, then this really becomes a non-issue. I'll just go with the current style, because it requires less code change, for now. > > 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. > > This isn't good, but on the positive side, no messages will be lost. > You just may end up with duplicate deliveries. > > > 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. > > So in other words, the likelihood of a duplicate delivery will simply > be reduced, not eliminated. No... I was thinking that if at least one delivery has succeeded, then we log failure of others but we *don't* defer. So no mail is lost (a delivery had to succeed), but we don't deliver the same message numerous times (MTA-specific) before the problem is discovered. > > 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. > > Are you sure? They could also just clone the message (N delivery > instructions == N copies) so that each instance is handled like an > independent delivery. They could. I suppose it's specific to each MTA. qmail keeps one copy of the message and keeps the envelope recipients in a separate file, noting a successful delivery for each one until all deliveries have been made (or the message times out). > I wonder if there is a way for us to do the same, without triggering > every matching delivery instruction the next time the queue is run? I think keeping track of which delivery instructions have succeeded or failed a'la qmail would be the simplest. Or rather, since we really *have* to keep track of which deliveries need to be retried, the most efficient way to do that seems to be to track the deliveries, rather than making a separate copy of the message for each delivery. In other words, even if we made a separate copy, we would have to note somewhere (a temporary header?) where that particular copy should be delivered. Also, if we keep the copy, we're responsible for retrying it at appropriate intervals, whereas if we defer it (via the MTA), all we care about is identifying the message (any incoming message) and determining if there are outstanding deliveries to perform. The MTA will worry about scheduling the retry. > > Another option is to attempt all deliveries and, if at least one is > > successful, consider the message delivered. > > I don't like this one. This is just a minor variation of the "defer-if-first-delivery-fails" strategy I mentioned above. Another variation would be to keep trying until we have a success and, if there are no successes, defer, otherwise, consider it a success. I really don't like any of the variations. I think the best idea, by far, is to mimic the MTA behavior and continue to attempt failed deliveries but not re-deliver successful ones. How we do that is an implementation detail we can figure out later. Tim _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
