Sure, I'll get it. The function find_bounded() is currently a void, so what
I'm using to see if it found anything or not is the length parameter. It would
just need a return value to indicate if it found a nothing or a zero length
something (which is to say, it found the bounding characters, but nothing
between them).
Aaron
Ilja Booij <[EMAIL PROTECTED]> said:
> Hi,
>
> I've found another problem :)
>
> When dbmail-lmtp rejects a message (unknown user for instance), postfix
> generates a bounce message, with "MAIL FROM: <>". This is legal (normal
> for notification messages from an MTA). DBMail does not handle it,
> because it cannot find an address between "<" and ">", which results in
> a "500 No address found" from dbmail-lmtp.
>
> This happens when the bounce message is sent to a user which is handled
> by the same dbmail instance.
>
> capiche?
>
> If you have no time for this, I'll fix it tomorrow. I'm off to home now!
>
> Ilja
>
>
> Aaron Stone wrote:
>
> > 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
> >>>>>>>>>>>>>>>>>[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
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>_______________________________________________
> >>>>>>>>>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
> >>>>
> >>>>_______________________________________________
> >>>>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
>
--
