Sure thing, I've got about an hour of time this morning. Looks like you're burning the midnight oil over there! Yikes!
Aaron Ilja Booij <[EMAIL PROTECTED]> said: > Hi, > > I haven't been able to find the cause of the problem yet. I found some > more info in the logs though: > > Mar 4 16:55:34 test01 postfix/lmtp[21340]: 3378119F30A: > to=<[EMAIL PROTECTED]>, > relay=localhost.fastxs.net[127.0.0.1], delay=0, status=bounced (host > localhost.fastxs.net[127.0.0.1] said: 250 Recipient > <[EMAIL PROTECTED]> OK) > > apparently, postfix thinks we want to bounce the message. But why? A > previous message to the same user arrives correctly.. > > strange, looking further. Aaron, can you also take a look at this? > > Ilja > > Ilja Booij wrote: > > > OK, I've found something: > > > > It seems that Postfix sends a RSET command, when we expect to get the > > header. > > > > readheader() then waits for postfix to send more, while postfix waits > > for a '250 OK' Message from dbmail-lmtp. > > > > So, there's probably something wrong in our LMTP-logic. > > I'll take a look at it, after I've done some small scripting job here > > for a customer. > > > > Ilja > > > > Ilja Booij wrote: > > > >> OK, > >> > >> this seems to have tackled the problem of the double delivery :) > >> > >> There still is another problem though: > >> It still seems to hang for a while on every second delivery attempt to > >> the LMTP daemon. > >> > >> Can you try the following scenario: > >> > >> * configure MTA to use dbmail-lmtp for delivery > >> * send message to a recipient > >> * verify that the message is received using dbmail-lmtp > >> * send a second message. > >> > >> What I observe here is that the second message takes a lot longer to > >> be delivered than the first one. The second one is only delivered > >> after minutes. > >> > >> I have the feeling that something is not right here.. > >> > >> Ilja > >> > >> Aaron Stone wrote: > >> > >>> New versions checked in, though not extensively tested yet. > >>> > >>> Ilja Booij <[EMAIL PROTECTED]> said: > >>> > >>> > >>>> sounds ok to me :) > >>>> > >>>> Ilja > >>>> > >>>> Aaron Stone wrote: > >>>> > >>>> > >>>>> Working on it as we speak! Catch you in about an hour? > >>>>> > >>>>> Aaron > >>>>> > >>>>> > >>>>> Ilja Booij <[EMAIL PROTECTED]> said: > >>>>> > >>>>> > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Aaron Stone wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> The reason for the double deliveries in the LMTP daemon is > >>>>>>> because the old > >>>>>>> insert_messages() function used to take lists of users to > >>>>>>> directly deliver. > >>>>>>> The new insert_messages() function takes a list of dsnuser > >>>>>>> structures, and > >>>>>>> expects that *either* the useridnr field is filled (for > >>>>>>> direct-to-useridnr > >>>>>>> delivery, which isn't supported by any of the frontends, but is > >>>>>>> supported in > >>>>>>> the lower layers ;-) or the address field, which is first checked > >>>>>>> as a > >>>>>>> username and then as an alias (this allows usernames in the form of > >>>>>>> '[EMAIL PROTECTED]' to operate without requiring an alias that says > >>>>>>> '[EMAIL PROTECTED] > >>>>>>> delivers to [EMAIL PROTECTED]'). > >>>>>>> > >>>>>>> Some refactoring might be necessary, because we need to inform > >>>>>>> the MTA > >>> > >>> > >>> > >>> whether > >>> > >>>>>>> or not its envelope recipients were valid before it will send us > >>>>>>> the message. > >>>>>>> This means users need to be validated before read_header(), which > >>>>>>> is a > >>> > >>> > >>> > >>> problem > >>> > >>>>>>> because at the moment this vaildation happens in insert_messages(). > >>>>>> > >>>>>> > >>>>>> > >>>>>> OK, that's clear > >>>>>> > >>>>>> > >>>>>>> Fine and dandy in pipe land, where the MTA will send the message > >>> > >>> > >>> > >>> regardless of > >>> > >>>>>>> the disposition of the recipients, and only at the very end are > >>>>>>> error > >>>>>>> conditions returned as exit codes... in LMTP land we need to know > >>>>>>> ahead of > >>>>> > >>>>> > >>>>> > >>>>> time. > >>>>> > >>>>> > >>>>>>> I think what I'll do is move the user validation code from > >>>>>>> insert_messages() > >>>>>>> into dsn.c, perhaps calling it dsn_check_users() or > >>>>>>> dsn_prepare_deliveries(). > >>>>>>> Then, we'll have this order: > >>>>>>> > >>>>>>> For command-line and envelope-recipient deliveries: > >>>>>>> - receive addresses and store them into the dsnusers list. > >>>>>>> - dsn_prepare_deliveries() > >>>>>>> - if no deliveries are valid, return an error. > >>>>>>> > >>>>>>> - read_header() > >>>>>>> > >>>>>>> For deliver-to header deliveries: > >>>>>>> - mime_readheader() > >>>>>>> - mail_adr_list() > >>>>>>> - dsn_prepare_deliveries() > >>>>>>> - if no deliveries are valid, return an error. > >>>>>>> > >>>>>>> - insert_messages() > >>>>>> > >>>>>> > >>>>>> > >>>>>> I like the part where you say 'What I'll do' :) > >>>>>> Do you think this work will take long? I think we must really > >>>>>> release rc3 tomorrow (Friday, March 5th). This stuff really has to > >>>>>> work if we want to release. > >>>>>> > >>>>>> Ilja > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Dbmail-dev mailing list > >>>>>> Dbmail-dev@dbmail.org > >>>>>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> Dbmail-dev mailing list > >>>> Dbmail-dev@dbmail.org > >>>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >>>> > >>> > >>> > >>> > >>> > >> _______________________________________________ > >> Dbmail-dev mailing list > >> Dbmail-dev@dbmail.org > >> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > > _______________________________________________ > > Dbmail-dev mailing list > > Dbmail-dev@dbmail.org > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
