> If that (config in the database) is going to happen again, one thing
that is
> worth considering is a run-time dynamic config system, so you can
change the
> behavior of dbmail on the fly. If it's worthwhile, I'll take a crack
at it
> this weekend.
If/when this is done, please keep in mind th
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 ins
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:
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
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
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 messa
Hi
Hans-Jürgen Schönig wrote:
Folks,
I had a problem with my data structure.
Basically I had unique user_idnr values but non-unique userid values.
This led to strange problems (mails disappearing all of a sudden and so
forth).
Maybe userid should be unique.
It probably should be. I just chec
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,
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
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.
> > T
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 fi
Hi,
Leif Jackson wrote:
Attached is the new patch with the slight change I figured for now the
easiest was to just move the FreeConfig for the smtpItems to the end of
freeall:, well maybe we want to think about a struct for these items that
can be global instead of the listnodes, *shrug* let me
I'm thinking that, for example, some option that determines how messages are
delivered might be re-read by the lmtp server as each message is delivered.
That way, you just change the option in the database and it immediately takes
effect from then on. In contrast, you'd make changed to the config o
That might be cool, I think that we need to carfully look at performance
of any config related stuff. The config should be read once, and for
things like dbmail-smtp it should do as little as possible as it is read
each time. I know the lmtpd is the answer to not re-reading configs each
time but no
If that (config in the database) is going to happen again, one thing that is
worth considering is a run-time dynamic config system, so you can change the
behavior of dbmail on the fly. If it's worthwhile, I'll take a crack at it
this weekend.
-Original Message-
From: [EMAIL PROTECTED] [mai
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-useridn
Oh, I just read the patch again and now I get it :-P
Maybe a more thorough refactoring of the configuration code is in order? At
the very least, it looks like we're going to be moving a lot of the
configuration back into the database during the 2.1 development phase.
Aaron
""Leif Jackson"" <[EM
The change was more to get the lists created for the configs out of the
way for my debugging, I like the idea of not keeping stuff around any
longer than it has to... The change doesn't fix any memory leak that i can
tell as I said in the first message. I just think it looks cleaner.
*shrug*
-leif
I'm really confused about what's being freed... I haven't been seeing any
other memory leaks from dbmail-smtp except for MySQL's internal allocations.
Aaron
""Leif Jackson"" <[EMAIL PROTECTED]> said:
> All,
>
> I found one ting this breaks I will send a patch shortly.. Bascialy
> bounce.c use
Attached is the new patch with the slight change I figured for now the
easiest was to just move the FreeConfig for the smtpItems to the end of
freeall:, well maybe we want to think about a struct for these items that
can be global instead of the listnodes, *shrug* let me know.
Thanks,
Leif
p.s. I
All,
I found one ting this breaks I will send a patch shortly.. Bascialy
bounce.c uses the config as a global. I don't see that this is a great
idea? I will be moving:
field_t dbmail_from_address, sendmail, postmaster;
to be global instead, so I can still FreeConfig in the main function.
Thanks
21 matches
Mail list logo
