Tim Legant <[EMAIL PROTECTED]> writes: > I'd go with something around 10, but see below. If a real person > sends me 10 email messages in a row without confirming one, sending > 40 more confirmations (assuming s/he keeps sending mail) probably > won't make a confirmation response any more likely.
This rests on the assumption that the TMDA user is using CONFIRM_APPEND though, correct? If they aren't using this, I could imagine cases where someone would send 10 messages expecting to get back 10 confirmation requests. Also, this limit is for _all_ auto-responses (confirm requests, confirm accepts, and bounces all add to the total). So, a limit of 10 would be reached after a sender confirmed only 5 messages (5 confirmation requests + 5 confirmation acceptance notices returned). Also consider shared setups where multiple recipients share the same TMDA configuration and queues (such as under a qmail virtualdomain, vpopmail, etc). This would raise the necessary limit slightly. This is why I thought of 50 -- it seems excessive at first glance, but it will stop a mail loop which is its intention, while at the same time (hopefully) not impeding any legitimate traffic. > If, upon receipt of a single confirmation message, all messages for > that sender are released, the need for a high threshold is reduced, > it seems to me. The later messages, for which a confirmation wasn't > sent, will still be successfully delivered. This sender-based pending queue is an independent idea, and one which will require quite a bit more time to design and implement. The queue would have to be carefully redesigned, and related tools like tmda-pending would have to be trained to accommodate. _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
