Adding upstream version 3.7.10.upstream/3.7.10

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 41 insertions, 0 deletions

diff --git a/src/cleanup/bug1.in b/src/cleanup/bug1.in
new file mode 100644
index 0000000..bda18cf
--- /dev/null
+++ b/src/cleanup/bug1.in
@@ -0,0 +1,41 @@
+#verbose on
+open bug1.file.tmp
+
+# Symptom:
+#
+#    infinite loop in postcat and in delivery agents
+#
+# Cause:
+#
+#    Failure to update location info after following a pointer record,
+#    while updating a message header record
+#
+# Analysis:
+#
+# This happens with repeated updates of the same message header.
+# After the first update, the update #1 header record sits in the
+# heap at the end of the queue file, and is followed by a reverse
+# pointer to the start of the next message header record or the
+# message body, somewhere in the middle of the queue file.
+#
+# The problem started with update #2 of that same message header.
+# While following the reverse pointer record after the update #1
+# header record to find out the start of the next header or message
+# body, the header updating routine did not update its notion of
+# where it was. Thus, it believed that the next header or body record
+# was located after the reverse pointer record. That was not the
+# middle of the message, but the end of the queue file. The second
+# update would result in an update #2 header record, followed by a
+# reverse pointer to what used to be the end of the queue file, but
+# had meanwhile become the location of the update #2 header record.
+#
+# Thus, anything that tried to deliver mail would loop on the update
+# #2 header record. After update update #3 of the same header, the
+# delivery agent would loop on the update #3 record, etc.
+
+upd_header 1 Subject long header text
+upd_header 1 Subject long header text
+upd_header 1 Subject long header text
+upd_header 1 Subject long header text
+
+close