"Jason R. Mastaler" <[EMAIL PROTECTED]> writes: > 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.
True. Well, since I think anything along the lines of this is really flawed, we seem to be in consensus. All deliveries must be made, somehow. > > 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 agree. I was just trying to cover the bases. This is nasty and is code that already exists (and works) in MTAs. > > 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? When I wrote the previous message, I had given it no thought other than to wonder if a good, cryptographic fingerprint/hash of the message might be enough to identify it. If so, then it's just a lookup in a file (DBM?) to find the name of a file (in the ~/.tmda/ hierarchy) that contains a list of the delivery instructions for that message. The file would be written the first time the message came through, if and only if one or more deliveries failed. Like I said, I haven't really pondered it much, there may be problems with that approach, although it seems reasonably robust... MD5 is the basis of the security of the entire *BSD ports system (verifying that the downloaded .tar.gz file is the correct one...). > 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. I find this grotesque. If I'm gone for a few days, I could have large numbers of messages delivered. Assuming this could be a problem with a commonly used mailbox, every incoming message to that box would be delivered multiple times. This "strategy" also plays hell with quotas, potentially rejecting important mail at the expense of multiple copies of something cute but useless that a friend forwarded. I really think we need to explore something better. I'm curious about your thoughts on a good hash (MD5/SHA1) for message identification.... Tim _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
