Thank you all for the attention. I was able to collect the Message_Id in SEND after I put the information in the message header still in the RELAY.
Then I gathered the information as the friend informed $ h_message_id_relay: This name, message_id_relay:, was added by me in the header using a headers_add. Again, thank you for your help. * Ygor Fernandes * Suporte Técnico * at; iPORTO.COM <http://iporto.com/> - Soluções em Cloud Computing * [email protected] * iPORTO: 51 3135.7676 * Horário de Atendimento: Das 08h12 às 18h Em qui, 4 de jul de 2019 às 13:02, Jethro R Binks via Exim-dev < [email protected]> escreveu: > On Thu, 4 Jul 2019, Jeremy Harris via Exim-dev wrote: > > > On 04/07/2019 15:07, Ygor Fernandes via Exim-dev wrote: > > > I would like to know if they could help me, I have an environment > where my > > > client connects to a server that I call RELAY this authenticates the > data > > > and then fire the message to the server that I call SEND. > > > > > > The sending occurs perfectly well, however I realize that in RELAY > after > > > sending a message it generates a new ID, this new ID that SEND follows > > > using to complete the process of sending the message. > > > > > > My need would be to relate these IDs because I work with the database > in my > > > environment. I can in SEND use the variable, $ message_id, and get the > ID > > > that is currently running, however I need to relate to the ID that was > > > previously used in my RELAY. > > > > > > Would you have any suggestions? > > > > A properly-formed message should have a Message-ID: header, and this > > will be logged on all the reception lines (ones with "<=") in the "id=" > > field. Use this for tracking the message across systems. in logfiles. > > > > If you're wanting to track via some other means that you are coding > > in your configuration, use $h_Message-ID: > > > > Naturally, messages that arrive without the header make your life > > difficult. The development tip has some help for this (log_selector > > "msg_id_created"), but that probably isn't what you are running. > > I do several related things: > > 1. set localhost_number to a different integer on each of my Exim hosts; > this ensures generated Message-Ids are unique across all my servers > > > 2. fixup inbound messages without a Message Id to add one. Actually I > don't do this any more, but I used to, with something like: > > warn condition = ${if !def:header_message-id: {1}} > message = Message-ID: <E$message_exim_id@$primary_hostname> > > > 3. turn on extensive logging (disk space is cheap): > > log_selector = \ > +all \ > -queue_run \ > -ident_timeout > > which ensures that I log things like: > > a/ the report from the next hop mail relay that (might) tell me the > internal message id that system allocated to the message I just sent it: > > C="250 2.6.0 <[email protected]> > [InternalId=99649298] Queued" > > b/ the message-id header of an inbound message on the received line: > > 2019-07-04 15:53:42 1hj43K-0005e5-3X <= [email protected] > ... > id=CA+uZYF5zV8Z_G2iBktQ9hTP8m-nKQtfjTqmZ=ejb99grnzk...@mail.gmail.com.whatever > ... > > > 4. Ensure I do the same in my report back to mail servers sending to me > (not sure how much of this is included in defaults these days): > > accept > message = 250 2.0.0 OK id=$message_exim_id \ > host=$smtp_active_hostname time=$tod_log > > > Maybe there are other things too ... > > Jethro. > > . . . . . . . . . . . . . . . . . . . . . . . . . > Jethro R Binks, Network Manager, > Information Services Directorate, University Of Strathclyde, Glasgow, UK > > The University of Strathclyde is a charitable body, registered in > Scotland, number SC015263. > > -- > ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim > details at http://www.exim.org/ ## > -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
