[exim-dev] [Bug 1840] New: Exim does not log a Message-ID it…

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: admin
Ημερομηνία:  
Προς: exim-dev
Καινούρια Θέματα: [exim-dev] [Bug 1840] Exim does not log a Message-ID it generates to fix up a missing one, [exim-dev] [Bug 1840] Exim does not log a Message-ID it generates to fix up a missing one, [exim-dev] [Bug 1840] Exim does not log a Message-ID it generates to fix up a missing one, [exim-dev] [Bug 1840] Exim does not log a Message-ID it generates to fix up a missing one, [exim-dev] [Bug 1840] Exim does not log a Message-ID it generates to fix up a missing one, [exim-dev] [Bug 1840] Exim does not log a Message-ID it generates to fix up a missing one, [exim-dev] [Bug 1840] Exim does not log a Message-ID it generates to fix up a missing one
Αντικείμενο: [exim-dev] [Bug 1840] New: Exim does not log a Message-ID it generates to fix up a missing one
https://bugs.exim.org/show_bug.cgi?id=1840

            Bug ID: 1840
           Summary: Exim does not log a Message-ID it generates to fix up
                    a missing one
           Product: Exim
           Version: 4.87
          Hardware: x86
                OS: All
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Logging
          Assignee: nigel@???
          Reporter: mike.brudenell@???
                CC: exim-dev@???


When a message arrives over SMTP with submission mode set and has no
"Message-ID:" header, Exim generates a message-id and adds the header line to
the message. This is documented in section 47.1 of the Exim Specification.

However the generated message-id does not get recorded anywhere in the log
files (eg, mainlog). This makes it impossible to supply the Message-ID to the
postmaster of the next-hop mail server to ease tracing a message.

The fault lies in the receive.c file within the receive_msg() function.

After reading and parsing the incoming headers Exim reaches a section of code
that checks whether the msgid_header variable is NULL and, if submission mode
is set, generates a message-id then uses header_add_at_position() to add the
    Message-Id: messageidvalue
line to the message.


However this code does not record the generated value in the msgid_header
variable.

Further down the function is the logging code that forms and outputs the
incoming "<=" log line. This checks msgid_header, finds it still NULL, so
having nothing to log does not add the "id messageidvalue" text to the log line
being built.

A possible solution is to modify the code that generates the value for a
missing message-id to also store the generated value in msgid_header. This
would give it a value so that when the logging code is reached it is output.

A potential drawback is that there would be no indication the value logged was
generated by the receiving Exim rather than arriving with the message itself.
This could conceivably lead to a postmaster quoting a (generated) message-id to
an upstream postmaster in an effort to help them trace a message back. Of
course as Exim generated the message-id it would not be known as that on the
upstream system.

However submission mode is generally expected to be used with MUAs, most of
which will generated message-ids; it is highly unlikely that a postmaster would
need to contact an upstream postmaster regarding a message for which the
receiving Exim was using submission mode and had to generate a message-id.

I'd therefore suggest the easy/straightforward solution of recording the
generated value in msgid_header so that the logging code picks it up is likely
satisfactory.

Cheers,
Mike Brudenell

--
You are receiving this mail because:
You are on the CC list for the bug.