New to the list here. But I read over the archives regarding this
problem and I may have a little to add.
I was able to get postfix to consistently deliver via lmtp to dbmail
(even two consecutive messages to the same user) by setting the postfix
directive lmtp_cache_connection to false instead of true. This would
termintate the lmtp connection after each delivery. I assume, with
lmtp_cache_connection turned on, the connection would die after
lmtp_timeout was reached and a new connection would be established and
the mail would get sent. This may have been a "neat feature" that works
with Cyrus (postfix's preferred lmtp client) or it may be a
specification of the lmtp rfc (I have not read it). But it seems like a
simple enough fix to make it work. It would probably just involve
having the conversation status fall back to a state the postfix expects
after message delivery and waiting in that state until either the
connection terminates or the conversation picks up again. I took a
cursory glance at the lmtp.c and lmtpd.c code but did not have enough
time to really dig into it.
Good Luck. I am anxiously awaiting the 2.0 release. :)
Robert Theisen
Aaron Stone wrote:
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
[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
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
