I know this is SO last week, but I missed this message... This DATA...RSET situation does not seem to be one that we can handle directly. Checking for "RSET" as the first line of a set of headers, while unlikely and non-RFC to occur, would probably be, at best, a really bad hack. Once the DATA command has been sent, I think that the only correct behavior is to wait for "\ r\n.\r\n" or a timeout.
It's good to hear that the timeout is handled correctly on both ends, though! However, I'd put money on a memory leak because there is no call to lmtp_reset() from the SIGALRM handler... If we do refactor the server code during 2.1 or 2.2, I think that it would make a lot of sense to have a single common server base and use function pointers to register each protocol's handler functions with the common server code base. This way, we won't have to hack up the server "template" to include calls to cleanup functions specific to each protocol. Aaron Ilja Booij <[EMAIL PROTECTED]> said: > 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 > >>>>> [email protected] > >>>>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >>>>> > >>>> > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> Dbmail-dev mailing list > >>> [email protected] > >>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >>> > >> > >> > >> > >> > > _______________________________________________ > > Dbmail-dev mailing list > > [email protected] > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > --
