On 2010-10-21 13:54, [email protected] wrote: > The mail drop happened again, but it isn't a connection reset. Looks > like, for whatever reason, it tried to insert the header twice and > didn't catch the error. (I can get the mail logs and doublecheck, but I > think three duplicates came in basically together.)
This is completely unrelated to the dropped connection problem. In this particular case it's a concurrency issue: the same message is being delivered more than once simultaneously through separate lmtp connections causing key collisions on the header cache tables. This will happen if you do mailbox resolving *before* handing over the message to dbmail-lmtpd. If that is required (for whatever reason) you should narrow the width of the delivery pipe to 1 in master.cf. Then, postfix will delivery them one-by-one, rather than all together at once. lmtpd itself will happily deliver the incoming message to multiple mailboxes if that is required by the delivery address on the envelope: the raw message is stored once, and is linked to all mailboxes necessary. However, doing duplicate concurrent delivery is not something currently supported. For 2.2 it means key-collisions like you noticed. For 2.3 chances this happens are vastly reduced by the different processing model: where 2.2 uses separated pre-forked processes that will do parallel IO processing, 2.3 uses a single process/single threaded event-driven model. This means that 2.3/lmtpd will handle many incoming connections concurrently, while still handling the messages internally in a single threaded fashion, thus preventing this kind of problem. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
