Actually, I think it's going to be easier to leave the function prototype
as-is and instead have it return a string of length 1 (nul terminator only) as
the found-part of "MAIL FROM <>" ... this minimizes the number of new tests
needed to handle the different possible combinations of factors.
Aaron
""Aaron Stone"" <[EMAIL PROTECTED]> said:
> 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
> > >>>>>>>>>>>>>>>>>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
> > >>
> > >
> > >
> > >
> > >
> > _______________________________________________
> > 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
>
--
