"Jason R. Mastaler" <[EMAIL PROTECTED]> writes: > Tim Legant <[EMAIL PROTECTED]> writes: > > >> If they aren't using this, I could imagine cases where someone > >> would send 10 messages expecting to get back 10 confirmation > >> requests. > > > > Without responding to any of them? > > Why does it matter whether they have responded to any of them?
[I'm assuming that CONFIRM_APPEND is None in this discussion...] I'm trying to imagine a situation where the sender would send 10 messages, knowing his recipient's mail system well enough to expect 10 confirmation requests, yet not knowing his recipient's mail system well enough to know that he should respond to one or more of them. If he's not automatically added to the whitelist, how would his 11th (or 51st) message (the first with no confirmation request sent) ever get released from the queue? That's why I thought all messages should be released. Then, if he did confirm even one, wouldn't that drop the number back to 9, a second confirmation would drop it back to 8? And once it has dropped below 10, TMDA would start sending confirmation requests again... ? Which brings up the question, how does the number ever get lower? Are you planning on keeping track of the number over a certain time period, like 24 hours or something, regardless of how many responses are made? If you count all TMDA-generated messages to the sender but only decrement the count as confirmation responses come in, the number will grow endlessly, since there's no expected response to a bounce or a delivery notice. At this point I'm sure I'm missing something! You've thought about this more than I have, so I expect it will work, but, wow, I'm having difficulty seeing exactly how! > > I'm curious why you want to do it this way. I don't see the point, > > right off, of counting acceptance notices. Do we gain something > > versus counting just confirmation requests? > > Failure notices (e.g, the notice returned when the sender is > blacklisted) need to be counted, because a loop may develop there. I assume you're talking about the result of 'bounce' actions here. If so, I agree completely. If all the other 'bounces' get counted for now because distinguishing them would be difficult, so be it. > > If this requires the sender-based queue, I withdraw the suggestion. > > I wasn't thinking of that full implementation, though. > > I see very little distinction between the two. If we can't do something simple, like scanning, then there probably isn't much distinction. And if there's not that much difference, then it's not worth spending the time on. Keep it simple, right? We'd be better off spending that time on the sender-based queues later. > > Scanning all messages in pending/ would also work, but might be > > prohibitively expensive... hmmm. > > That was my thought as well. Ok, then let's postpone this until we actually do the sender queues. I think 50 is a reasonable number, since people can set it lower if they like. For instance, I never bounce blacklisted mail; I just drop it, so I might want to lower the default. For those who bounce their blacklists, the higher default would be better. Tim _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
