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]
