On 12/29/2010 6:06 PM, Mark Martinec wrote: > Clay, > >> I am preparing to upgrade some boxes off of 2.5.4, but have noticed a >> minor difference in the how the "%a" macro is being handled. >> >> With 2.6.4 I see the following log entry: >> >> Dec 29 08:49:21 mta-test amavis[30209]: (30209-15) Passed CLEAN, >> [192.168.76.134] [192.168.76.1]<m...@domain.tld> -> <m...@domain.tld>, > [...] > >> However, I have tried to use the same macro in 2.5.4 and am receiving >> different results. >> >> Dec 29 09:41:30 mta-test amavis[21891]: (21891-01) Passed CLEAN, >> [192.168.76.1]<m...@domain.tld> -> <m...@domain.tld>, > [...] > >> As you see above, the output for this portion of the log does not pick >> up the connecting IP this time only the origin IP. and I get a blank >> entry for received:<%a> in the log template. >> >> Both templates use %e and pick up on the origin IP without issue. >> >> Looking through the release notes, I am not seeing anything that >> indicates a fix or change in behavior, unless I am overlooking it. > > The 2.5.4 picks up a connecting client's IP address from an > ADDR field of a Postfix XFORWARD smtp command. > > The 2.6.4 does the same, but if that information turns out > not to be available, it parses a header section and picks > the IP address from the topmost Received header field. > > > amavisd-new-2.6.0 release notes : > > - in the absence of a smtp client's IP address (normally received by XFORWARD > smtp command from Postfix, or in the 'client_address' attribute of AM.PDP), > parse the topmost one or two Received header fields and use the first > valid IP address found there; based on a suggestion by Richard Bishop;
Definitely overlooked this in the docs. Thank you for pointing it out. > > >> If needed, I think I can parse the value of >> "received:<[:header_field|Received]>" in 2.5.4 and get a similar result >> as I am in 2.6.4 to help mimic the behavior and ease the transition with >> our own parsing and use of the custom log. > > So it appears that your mailer is not sending the XFORWARD command > in an smtp session to amavisd. Are you perhaps using a milter setup > or some other mailer that Postfix? If using Postfix with an SMTP > or LMTP feed to amavisd, check the smtp_send_xforward_command > option in a postfix 'smtp' service feeding amavisd, it should > be set to 'yes'. The XFORWARD is available in Postfix since its > version 2.1. This last portion may be the culprit. Thanks for bringing that to my attention. I will do some follow-up testing to see how it behaves with changes to the smtp_send_xforward_command option in Postfix. Clay ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user Please visit http://www.ijs.si/software/amavisd/ regularly For administrativa requests please send email to rainer at openantivirus dot org
