Fix missing newline in debug output for headers_add in a transport.

[user/henk/code/exim.git] / src / src / deliver.c

diff --git a/src/src/deliver.c b/src/src/deliver.c
index 3dffe78fef8625911b09a071e33b28a1c882f883..7dbb94fc69c9623f3269afcdc8a7a7d5bc21ff6b 100644 (file)
--- a/src/src/deliver.c
+++ b/src/src/deliver.c
@@ -1,10 +1,10 @@
-/* $Cambridge: exim/src/src/deliver.c,v 1.4 2004/12/16 15:11:47 tom Exp $ */
+/* $Cambridge: exim/src/src/deliver.c,v 1.9 2005/03/22 14:50:10 ph10 Exp $ */
 
 /*************************************************
 *     Exim - an Internet mail transport agent    *
 *************************************************/
 
-/* Copyright (c) University of Cambridge 1995 - 2004 */
+/* Copyright (c) University of Cambridge 1995 - 2005 */
 /* See the file NOTICE for conditions of use and distribution. */
 
 /* The main code for delivering a message. */
@@ -729,9 +729,27 @@ else if (driver_type == DTYPE_ROUTER)
 
 /* If there's an error message set, ensure that it contains only printing
 characters - it should, but occasionally things slip in and this at least
-stops the log format from getting wrecked. */
+stops the log format from getting wrecked. We also scan the message for an LDAP
+expansion item that has a password setting, and flatten the password. This is a
+fudge, but I don't know a cleaner way of doing this. (If the item is badly
+malformed, it won't ever have gone near LDAP.) */
 
-if (addr->message != NULL) addr->message = string_printing(addr->message);
+if (addr->message != NULL)
+  {
+  addr->message = string_printing(addr->message);
+  if (Ustrstr(addr->message, "failed to expand") != NULL &&
+      (Ustrstr(addr->message, "ldap:") != NULL ||
+       Ustrstr(addr->message, "ldapdn:") != NULL ||
+       Ustrstr(addr->message, "ldapm:") != NULL))
+    {
+    uschar *p = Ustrstr(addr->message, "pass=");
+    if (p != NULL)
+      {
+      p += 5;
+      while (*p != 0 && !isspace(*p)) *p++ = 'x';
+      }
+    }
+  }
 
 /* If we used a transport that has one of the "return_output" options set, and
 if it did in fact generate some output, then for return_output we treat the
@@ -2080,6 +2098,7 @@ while (addr_local != NULL)
     same characteristics. These are:
 
       same transport
+      not previously delivered (see comment about 50 lines above)
       same local part if the transport's configuration contains $local_part
       same domain if the transport's configuration contains $domain
       same errors address
@@ -2093,6 +2112,7 @@ while (addr_local != NULL)
       {
       BOOL ok =
         tp == next->transport &&
+        !previously_transported(next) &&
         (!uses_lp  || Ustrcmp(next->local_part, addr->local_part) == 0) &&
         (!uses_dom || Ustrcmp(next->domain, addr->domain) == 0) &&
         same_strings(next->p.errors_address, addr->p.errors_address) &&
@@ -2556,13 +2576,13 @@ also by optional retry data.
 
 Read in large chunks into the big buffer and then scan through, interpreting
 the data therein. In most cases, only a single read will be necessary. No
-individual item will ever be anywhere near 500 bytes in length, so by ensuring
-that we read the next chunk when there is less than 500 bytes left in the
-non-final chunk, we can assume each item is complete in store before handling
-it. Actually, each item is written using a single write(), which is atomic for
-small items (less than PIPE_BUF, which seems to be at least 512 in any Unix) so
-even if we are reading while the subprocess is still going, we should never
-have only a partial item in the buffer.
+individual item will ever be anywhere near 2500 bytes in length, so by ensuring
+that we read the next chunk when there is less than 2500 bytes left in the
+non-final chunk, we can assume each item is complete in the buffer before
+handling it. Each item is written using a single write(), which is atomic for
+small items (less than PIPE_BUF, which seems to be at least 512 in any Unix and
+often bigger) so even if we are reading while the subprocess is still going, we
+should never have only a partial item in the buffer.
 
 Argument:
   poffset     the offset of the parlist item
@@ -2598,7 +2618,9 @@ completed.
 
 Each separate item is written to the pipe in a single write(), and as they are
 all short items, the writes will all be atomic and we should never find
-ourselves in the position of having read an incomplete item. */
+ourselves in the position of having read an incomplete item. "Short" in this
+case can mean up to about 1K in the case when there is a long error message
+associated with an address. */
 
 DEBUG(D_deliver) debug_printf("reading pipe for subprocess %d (%s)\n",
   (int)p->pid, eop? "ended" : "not ended");
@@ -2612,7 +2634,7 @@ while (!done)
   There will be only one read if we get all the available data (i.e. don't
   fill the buffer completely). */
 
-  if (remaining < 500 && unfinished)
+  if (remaining < 2500 && unfinished)
     {
     int len;
     int available = big_buffer_size - remaining;
@@ -6335,7 +6357,7 @@ if (addr_defer == NULL)
     }
 
   /* Remove the two message files. */
-  
+
   sprintf(CS spoolname, "%s/input/%s/%s-D", spool_directory, message_subdir, id);
   if (Uunlink(spoolname) < 0)
     log_write(0, LOG_MAIN|LOG_PANIC_DIE, "failed to unlink %s", spoolname);
@@ -6346,7 +6368,7 @@ if (addr_defer == NULL)
   /* Log the end of this message, with queue time if requested. */
 
   if ((log_extra_selector & LX_queue_time_overall) != 0)
-    log_write(0, LOG_MAIN, "Completed QT=%s", 
+    log_write(0, LOG_MAIN, "Completed QT=%s",
       readconf_printtime(time(NULL) - received_time));
   else
     log_write(0, LOG_MAIN, "Completed");