Ok, then you're still up, and I just fixed the other two sections of code :-)
Aaron
Ilja Booij <[EMAIL PROTECTED]> said:
> Hi,
>
> (respone inline)
>
> Aaron Stone wrote:
>
> > In this example, there are three recipients, pat, jones and green. Following
> > the data command, there are only two acknowledgements. This is contrary to
> > my
> > understanding that each recipient had to be acknowledged:
> >
> > The LMTP protocol causes the server to return, after the final "." of
> > the DATA command, one reply for each recipient. Therefore, if the
> > queue manager is configured to use LMTP instead of SMTP when
> > transferring messages to the delivery agents, then the delivery
> > agents may attempt delivery to each recipient after the final "." and
> > individually report the status for each recipient. Connections which
> > should use the LMTP protocol are drawn in the diagram above using
> > asterisks.
> >
> > So looking at jones, it is clear why: jones failed the RCPT command, and so
> > was no longer in the recipient list when the DATA command came around. Then
>
> Clear :)
>
> > read this:
> >
> > The additional restriction is that when there have been no successful
> > RCPT commands in the mail transaction, the DATA command MUST fail
> > with a 503 reply code.
> >
> > The change is that after the final ".", the server returns one reply
> > for each previously successful RCPT command in the mail transaction,
> > in the order that the RCPT commands were issued. Even if there were
> > multiple successful RCPT commands giving the same forward-path, there
> > must be one reply for each successful RCPT command.
> >
> > I think that what the first paragraph in this quote means is not that DATA
> > is
> > failed, per se, but that the whole conversation is flagged with a 503.
> >
> > So here's what I think needs to be fixed:
> >
> > - If there are no recipients, use 503 AND NOTHING ELSE to report it,
> > which means changing this section of code to use a 503:
> >
> > if (!has_recipients)
> > {
> > trace(TRACE_DEBUG,"main(): no valid recipients found, cancel message.");
> > fprintf((FILE *)stream, "554 No valid recipients.\r\n" );
> > }
>
> Yep, change the 554 to 503
>
> >
> > - When a recipient is failed, report the error and then *remove that
> > recipient from the dsnusers list* so that after the message is
> > received, their failure is not reported a second time.
>
> Sounds good :)
> >
> > I'll get on it this afternoon, please test it in the morning, your time!
> I will.
>
> Ilja
>
> >
> > Ilja Booij <[EMAIL PROTECTED]> said:
> >
> >
> >>After some more reading of RFC 2033 I'm inclined to believe an LMTP
> >>client does not get a response after sending the DATA, except for the
> >>responses about the delivery of the message to the users.
> >>
> >>Example session from the RFC:
> >>
> >> S: 220 foo.edu LMTP server ready
> >> C: LHLO foo.edu
> >> S: 250-foo.edu
> >> S: 250-PIPELINING
> >> S: 250 SIZE
> >> C: MAIL FROM:<[EMAIL PROTECTED]>
> >> S: 250 OK
> >>
> >> C: RCPT TO:<[EMAIL PROTECTED]>
> >> S: 250 OK
> >> C: RCPT TO:<[EMAIL PROTECTED]>
> >> S: 550 No such user here
> >> C: RCPT TO:<[EMAIL PROTECTED]>
> >> S: 250 OK
> >> C: DATA
> >> S: 354 Start mail input; end with <CRLF>.<CRLF>
> >> C: Blah blah blah...
> >> C: ...etc. etc. etc.
> >> C: .
> >> S: 250 OK
> >> S: 452 <[EMAIL PROTECTED]> is temporarily over quota
> >> C: QUIT
> >> S: 221 foo.edu closing connection
> >>
> >>The important bit is after the DATA line
> >>there are two responses from the server after the data line:
> >>1. "250 OK": the message to [EMAIL PROTECTED] was delivered
> >>2. "452 <[EMAIL PROTECTED]> is temporarily over quota", the message to
> >>[EMAIL PROTECTED] was not delivered.
> >>
> >>There is no line indicating that the message was received by the server.
> >>The server should only indicate when a message was not received correctly.
> >>
> >>I'll complete remove the
> >>fprintf((FILE *)stream, "250 Message received OK\r\n"); line
> >>
> >>
> >>Ilja Booij wrote:
> >>
> >>
> >>>Hi,
> >>>
> >>>Removing the
> >>>"250 Message received OK" after having received the message takes care
> >>>of the error. I can just send several messages, with
> >>>"lmtp_cache_connection = yes" in /etc/postfix/main.cf
> >>>
> >>>I'm starting to wonder whether LMTP requires us to send a message if the
> >>>message was received OK by the server.
> >>>
> >>>Ilja
> >>>
> >>>Ilja Booij wrote:
> >>>
> >>>
> >>>>Hi,
> >>>>
> >>>>with some help from a guy on [EMAIL PROTECTED] I found something:
> >>>>
> >>>>The "250 Recipient <[EMAIL PROTECTED]> OK" message from
> >>>>dbmail-lmtp is out of sync. The postfix/lmtp program stores this
> >>>>message until the next message is sent, causing the messages between
> >>>>postfix and dbmail-smtp to be horribly out-of-sync.
> >>>>
> >>>>I guess this should be quite easy to fix. I'll see if I have some time
> >>>>to do it this weekend. Otherwise I'll do it on Monday. Unless anybody
> >>>>else wants to do it of course ;)
> >>>>
> >>>>I'll be off in a few minutes. First a beer, then it's off to home :)
> >>>>
> >>>>Have a nice weekend!
> >>>>
> >>>>Ilja
> >>>>
> >>>>
> >>>>Ilja Booij wrote:
> >>>>
> >>>>
> >>>>>Hmm, I still don't really understand the problem. I've done some
> >>>>>ngrep-ing, to see what goes over the network.
> >>>>>
> >>>>>This is a session that's OK:
> >>>>>
> >>>>>T 2004/03/05 13:45:46.324232 127.0.0.1:10024 -> 127.0.0.1:46715 [AP]
> >>>>> 220 test01 DBMail LMTP service ready to rock..
> >>>>>##
> >>>>>T 2004/03/05 13:45:46.324696 127.0.0.1:46715 -> 127.0.0.1:10024 [AP]
> >>>>> LHLO test01.office.fastxs.net..
> >>>>>##
> >>>>>T 2004/03/05 13:45:46.324900 127.0.0.1:10024 -> 127.0.0.1:46715 [AP]
> >>>>> 250-test01..250-PIPELINING..250-ENHANCEDSTATUSCODES..250 SIZE..
> >>>>>#
> >>>>>T 2004/03/05 13:45:46.325306 127.0.0.1:46715 -> 127.0.0.1:10024 [AP]
> >>>>> MAIL FROM:<[EMAIL PROTECTED]> SIZE=866..RCPT
> >>>>>TO:<[EMAIL PROTECTED]>..DATA..
> >>>>>#
> >>>>>T 2004/03/05 13:45:46.325479 127.0.0.1:10024 -> 127.0.0.1:46715 [AP]
> >>>>> 250 Sender <[EMAIL PROTECTED]> OK..
> >>>>>##
> >>>>>T 2004/03/05 13:45:46.365648 127.0.0.1:10024 -> 127.0.0.1:46715 [AP]
> >>>>> 250 Recipient <[EMAIL PROTECTED]> OK..354 Start mail
> >>>>>input; end with <CRLF>.<CRLF>..
> >>>>>##
> >>>>>T 2004/03/05 13:45:46.365974 127.0.0.1:46715 -> 127.0.0.1:10024 [AP]
> >>>>> Received: from earthquake.office.fastxs.net
> >>>>>(earthquake.office.fastxs.net [10.0.1.15])...by test01.office.fastxs.n
> >>>>> et (Postfix) with ESMTP id 394DD19F30A...for
> >>>>><[EMAIL PROTECTED]>; Fri, 5 Mar 2004 13:45:46 +0100 (C
> >>>>> ET)..Received: from earthquake.office.fastxs.net (localhost
> >>>>>[127.0.0.1])...by earthquake.office.fastxs.net (Postfi
> >>>>> x) with ESMTP id 405D4375FE...for
> >>>>><[EMAIL PROTECTED]>; Fri, 5 Mar 2004 13:49:12 +0100
> >>>>>(CET)..Receiv
> >>>>> ed: (from [EMAIL PROTECTED])...by earthquake.office.fastxs.net
> >>>>>(8.12.9/8.12.9/Submit) id i25CnCo0005116...for target@
> >>>>> test01.office.fastxs.net; Fri, 5 Mar 2004 13:49:12 +0100
> >>>>>(CET)..Date: Fri, 5 Mar 2004 13:49:12 +0100 (CET)..From:
> >>>>> Ilja Booij <[EMAIL PROTECTED]>..Message-Id:
> >>>>><[EMAIL PROTECTED]
> >>>>> net>..To: [EMAIL PROTECTED]: 5-3
> >>>>>27......27.....
> >>>>>##
> >>>>>T 2004/03/05 13:45:46.568851 127.0.0.1:10024 -> 127.0.0.1:46715 [AP]
> >>>>> 250 Message received OK..
> >>>>>##
> >>>>>T 2004/03/05 13:45:46.608610 127.0.0.1:10024 -> 127.0.0.1:46715 [AP]
> >>>>> c..
> >>>>>
> >>>>>
> >>>>>
> >>>>>If another message is sent (over the same connection):
> >>>>>
> >>>>>
> >>>>>##
> >>>>>T 2004/03/05 13:46:01.879964 127.0.0.1:46715 -> 127.0.0.1:10024 [AP]
> >>>>> RSET..
> >>>>>##
> >>>>>T 2004/03/05 13:46:01.880127 127.0.0.1:46715 -> 127.0.0.1:10024 [AP]
> >>>>> MAIL FROM:<[EMAIL PROTECTED]> SIZE=858..RCPT
> >>>>>TO:<[EMAIL PROTECTED]>..DATA..
> >>>>>##
> >>>>>T 2004/03/05 13:46:01.880368 127.0.0.1:10024 -> 127.0.0.1:46715 [AP]
> >>>>> 250 OK..
> >>>>>##
> >>>>>T 2004/03/05 13:46:01.880460 127.0.0.1:10024 -> 127.0.0.1:46715 [AP]
> >>>>> 250 Sender <[EMAIL PROTECTED]> OK..
> >>>>>##
> >>>>>T 2004/03/05 13:46:01.883495 127.0.0.1:10024 -> 127.0.0.1:46715 [AP]
> >>>>> 250 Recipient <[EMAIL PROTECTED]> OK..
> >>>>>##
> >>>>>T 2004/03/05 13:46:01.883541 127.0.0.1:10024 -> 127.0.0.1:46715 [AP]
> >>>>> 354 Start mail input; end with <CRLF>.<CRLF>..
> >>>>>##
> >>>>>T 2004/03/05 13:47:41.920055 127.0.0.1:46715 -> 127.0.0.1:10024 [AP]
> >>>>> RSET..QUIT..
> >>>>>###
> >>>>>T 2004/03/05 13:52:41.875033 127.0.0.1:10024 -> 127.0.0.1:46715 [AP]
> >>>>> 500 Error reading header...
> >>>>>#
> >>>>>
> >>>>>You can see that the client (postfix) starts with an RSET command,
> >>>>>and starts sending MAIL_FROM, RCPT and DATA.
> >>>>>The server responds with 250 OK to the reset, and 250 Sender OK and
> >>>>>250 Recipient OK, and lets the client start sending (354 Start mail
> >>>>>input).
> >>>>>
> >>>>>The problem is that Postfix detects that it should not send data,
> >>>>>because the message is supposedly bounced by dbmail.. But why?
> >>>>>
> >>>>>Ilja
> >>>>>
> >>>>>Ilja Booij wrote:
> >>>>>
> >>>>>
> >>>>>>Hi,
> >>>>>>
> >>>>>>Robert, thanks for your suggestion. It seems to work perfectly here.
> >>>>>>Messages now get delivered to users without a problem.
> >>>>>>
> >>>>>>I'll take a look at lmtp.c to see if I can spot the difference
> >>>>>>between the server getting a QUIT from the client and a reconnection
> >>>>>>on a new message, and a cached connection.
> >>>>>>
> >>>>>>Ilja
> >>>>>>
> >>>>>>
> >>>>>>Robert Theisen wrote:
> >>>>>>
> >>>>>>
> >>>>>>>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
> >>>>>>>>>>>>>>>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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>_______________________________________________
> >>>>>>>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
> >>
> >>_______________________________________________
> >>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
>
--
