Re: Turning of milter checks
On Fri, Apr 24, 2009 at 6:48 AM, Wietse Venema wie...@porcupine.org wrote: FYI, The header_checks parameter does not control whether or not Milter operation is invoked, so your observations are incorrect. If you want to pursue this further, show a telnet mail submission and the corresponding logging. Also, instead of it does work and it does not work please describe what happens and what you expected to happen. Wietse Well, today the milter checks are not happening, which is correct. It doesn't make any sense to me. My best guess is there was a typo somewhere, though I checked that and did not find one. I'm sorry for wasting your time, I thought I tried everything (twice) before posting. The ps/pgrep output is still perplexing. If I have just -o receive_override_options=no_milters the pgrep output is: 92212 smtpd -n 2525 -t inet -u -o stress= -o content_filter= -o receive_override_options=no_milters -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks= 127.0.0.0/8,xx.yy.zz.0/24 If I have -o receive_override_options=no_header_body_checks,no_milters pgrep output is: 91904 smtpd -n 2525 -t inet -u -o stress -o content_filter -o receive_override_options -o smtpd_sender_restrictions -o smtpd_recipient_restrictions -o mynetworks
Re: Turning of milter checks
Dan Lists: The ps/pgrep output is still perplexing. If I have just -o receive_override_options=no_milters the pgrep output is: 92212 smtpd -n 2525 -t inet -u -o stress= -o content_filter= -o receive_override_options=no_milters -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks= 127.0.0.0/8,xx.yy.zz.0/24 This information is taken from in the kernel address space. If I have -o receive_override_options=no_header_body_checks,no_milters pgrep output is: 91904 smtpd -n 2525 -t inet -u -o stress -o content_filter -o receive_override_options -o smtpd_sender_restrictions -o smtpd_recipient_restrictions -o mynetworks This information is taken from the process address space. While parsing -o name=value, smtpd will split the name=value by overwriting the = with a null byte (which is used as string terminator). Therefore, the output above only shows -o name. Why one command takes the information from the kernel, and the other from the process, is a question that your vendor can answer. Wietse
Turning of milter checks
I'm running postfix 2.5.6, and I'm using amavis through the milter interface by setting 'smtpd_milters= inet:[127.0.0.1]:10023'. I'm trying to set up a different port for skipping amavis checks on email that has already been checked. In master.cf I have: 2525inetn - n - - smtpd -o content_filter= -o receive_override_options=no_milters -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks=127.0.0.0/8,xx.yy.zz.0/24 It is still being handed off to amavis via the milter interface. I tried adding '-o smtpd_milters=' but that didn't stop it either. The above worked in postfix 2.4.6. Any idea why this isn't working? Thanks, Dan
Re: Turning of milter checks
Dan Lists: I'm running postfix 2.5.6, and I'm using amavis through the milter interface by setting 'smtpd_milters= inet:[127.0.0.1]:10023'. I'm trying to set up a different port for skipping amavis checks on email that has already been checked. In master.cf I have: 2525inetn - n - - smtpd -o content_filter= -o receive_override_options=no_milters -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks=127.0.0.0/8,xx.yy.zz.0/24 It is still being handed off to amavis via the milter interface. I tried adding '-o smtpd_milters=' but that didn't stop it either. The above worked in postfix 2.4.6. Any idea why this isn't working? First, show that Postfix receives mail via port 2525. This requires a transcript of a telnet session, and the Postfix logging for the corresponding email delivery. Second, show with ps command output that port 2525 actually has receive_override_options=no_milters. It won't have this unless you do postfix reload. Wietse
Re: Turning of milter checks
On Thu, Apr 23, 2009 at 6:14 PM, Wietse Venema wie...@porcupine.org wrote: First, show that Postfix receives mail via port 2525. This requires a transcript of a telnet session, and the Postfix logging for the corresponding email delivery. Second, show with ps command output that port 2525 actually has receive_override_options=no_milters. It won't have this unless you do postfix reload. Wietse I misspoke slightly. I actually have this in master.conf: 2525inetn - n - - smtpd -o content_filter= -o receive_override_options=no_header_body_checks,no_milters -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks=127.0.0.0/8,xx.yy.zz.0/24 The pgrep output is: 91904 smtpd -n 2525 -t inet -u -o stress -o content_filter -o receive_override_options -o smtpd_sender_restrictions -o smtpd_recipient_restrictions -o mynetworks If I remove no_header_body_checks (-o receive_override_options=no_milters) it works: 92212 smtpd -n 2525 -t inet -u -o stress= -o content_filter= -o receive_override_options=no_milters -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks= 127.0.0.0/8,xx.yy.zz.0/24 If I have just no_header_body_checks (-o receive_override_options=no_header_body_checks) it does not work: 92553 smtpd -n 2525 -t inet -u -o stress -o content_filter -o receive_override_options -o smtpd_sender_restrictions -o smtpd_recipient_restrictions -o mynetworks I believe that the ps output is sufficient to see the problem, but if you still want the telnet transcript, I can provide that. Here is log entries showing no errors (I didn't do a full session, just enough to get a ps): Apr 23 19:31:24 mail5 postfix/master[940]: reload configuration /usr/local/etc/postfix Apr 23 19:31:32 mail5 postfix/smtpd[93895]: connect from server.example.net [xx.yy.zz.140] Apr 23 19:32:33 mail5 postfix/smtpd[93895]: timeout after CONNECT from server.example.net[xx.yy.zz.140]
