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
