Hi there, Thanks for the reply. I'm not having performance issues, but this is messing my logs and statistics only. Any work around to get this verification only once? Thanks in advance. BR, Rafael
Em sex., 17 de out. de 2025 às 17:55, Wietse Venema via Postfix-users <[email protected]> escreveu: > > Rafael Azevedo via Postfix-users: > > In my milter logs I see success for every request postfix makes. > > > > I sent only two emails and this is what my milter gets: > > > > recipients: > > [email protected] > > [email protected] > > I assume that each message ad one recipient. > > > logs: > > > > [2025-10-17 10:31:42] [INFO] [PID:188081] >>> processRequest START: [get *] > > [2025-10-17 10:31:42] [INFO] [PID:188081] Parts: ["get","*"] > ... > > [2025-10-17 10:31:42] [INFO] [PID:188081] >>> processRequest START: [get *] > > [2025-10-17 10:31:42] [INFO] [PID:188081] Parts: ["get","*"] > .. > > Here, the trivial-rewrite address resolver is intializing for > > - "normal" routing, which uses transport_maps, default_transport, > and so on. > > - "address verification" routing, which uses address_verify_transport_maps, > address_verify_default_transport, and so on. > > transport_maps and address_verify_transport_maps may be different, > therefore the trivial-rewrite initialization code makes one "*" > query for each table. The code does not try to be clever when > 'normal" and "address verification" settings have the same value. > The "*" result is cached in-process for 30 seconds. > > First message: > > > [2025-10-17 10:31:42] [INFO] [PID:188081] >>> processRequest START: > > [get [email protected]] > > That is the MAIL FROM command parser making sure that the sender > addess is well-formed, which involves the address resolver. The > request goes from the Postfix SMTP server through a trivial-rewrite > process to the tcp_table server. The result will be reused in the > same SMTP server process when evaluating smtpd_xxx_restrictions. > > The Postfix SMTP daemon process caches the result, so that it > will not make that query another time. > > > [2025-10-17 10:31:42] [INFO] [PID:188081] >>> processRequest START: > > [get [email protected]] > > That is the RCPT TO command parser making sure that the recipient > addess is well-formed, which involves the address resolver. The > request goes from the Postfix SMTP server through a trivial-rewrite > process to the tcp_table server. The result will be reused in the > same SMTP server process when evaluating smtpd_xxx_restrictions. > > > [2025-10-17 10:31:42] [INFO] [PID:188081] >>> processRequest START: > > [get [email protected]] > > That is while scheduling delivery. The request goes from the Postfix > queue manager through a trivial-rewrite process to the tcp_table server. > > The second message causes no 'get [email protected]' event > because the result is still cached in the SMTP server process. > > > [2025-10-17 10:31:42] [INFO] [PID:188081] >>> processRequest START: > > [get [email protected]] > > That is the RCPT TO command parser making sure that the recipient > addess is well-formed, which involves the address resolver. The > request goes from the Postfix SMTP server through a trivial-rewrite > process to the tcp_table server. The result will be reused in the > same SMTP server processs when evaluating smtpd_xxx_restrictions. > > > [2025-10-17 10:31:43] [INFO] [PID:188081] >>> processRequest START: > > [get [email protected]] > > That is while scheduling delivery. The request goes from the Postfix > queue manager through a trivial-rewrite process to the tcp_table server. > > This is why every recipient is logged twice: once when the SMTP > server ensures that the address is well-formed, and once while the > queue manager is scheduling delivery. If this is causing performance > problem then yiou have a bigger problem. > > Wietse > _______________________________________________ > Postfix-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Postfix-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
