Tim Legant <[EMAIL PROTECTED]> writes: > 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.
To me this is still losing mail. If someone specifies a delivery instruction, and the message silently does not get delivered there, that is lossage. Partial success isn't good enough. Even if the user has logging turned on (he may not), and happens to notice the failure, there is no way for him to get that message requeued and delivered the way he had intended. > Also, if we keep the copy, we're responsible for retrying it at > appropriate intervals No I wasn't suggesting this, I'd never want to get into this business. > 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. I think we need to figure it out now. Or at least have a good general idea of how we would do it. It might not even be feasible, in which case we can't consider it. Unlike an MTA, TMDA has no way of tracking messages sitting in the MTA's mailq. Each time the queue is run, TMDA sees the message as if for the first time. We can't just record successful/unsuccessful delivery instructions. We'd have to correlate this with the messages sitting in the mailq. It's not clear to me how this would be done. Did you have some ideas? I wanted to see how maildrop handled the analagous condition (a block of multiple delivery instructions) since it also exits 75 to requeue the message on error. The example I tested was two sequential delivery instructions (mbox deliveries), where the first instruction succeeds, and the second raises an error (permission denied). maildrop delivered to the first instruction, and deferred the message when it couldn't deliver to the second. When the mailq was flushed, another delivery was made to the first instruction, and the cycle repeated. Thus, the first mailbox ended up with multiple copies of the message. maildrop does the slightly annoying, but safe thing. The delivery instructions that succeed may end up with duplicates, but no mail will be lost. This is probably what I'll lobby for if we can't figure out the prefect solution, since in my mind it's the lesser of two evils. _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
