Ldap query source ip selection
Hello, Is there any way to choose source IP address for LDAP query in postfix? We have a multi-instance setup where one instance need to use a specific source ip address in the system because LDAP queries must go trough a VPN IPsec connection. I can setup source ip address for smtp connections but I can't find anything similar for LDAP queries. Regards, Carlos Velasco
recipient bcc at which point does the mail get duplicated
Hi, i have a postfix implementation where i use recipient_bcc maps to duplicate messages which are from users which are on my exchange server. This is needed because users still want to be able to read there mail with the conventional imap system ( so forwarding is no solution ). The problem is that postfix seems to generate the bcc message before the spamfilter and then send it without checks to the exchange. How can i change that behavior ? I would like that postfix does the bcc after the spamfilter(amavis) has been run. for any hints i would be grateful. Frank -- Frank Doege
Re: Ldap query source ip selection
On 09/05/2010 11:02 AM, Carlos Velasco wrote: Hello, Is there any way to choose source IP address for LDAP query in postfix? We have a multi-instance setup where one instance need to use a specific source ip address in the system because LDAP queries must go trough a VPN IPsec connection. I can setup source ip address for smtp connections but I can't find anything similar for LDAP queries. Regards, Carlos Velasco You can use source routing on the host machine to make sure any queries to that LDAP server originate from a specified IP: ip route add [via ] src This will always assign that interface's IP as the source. J.
Re: recipient bcc at which point does the mail get duplicated
On 09/05/2010 02:52 PM, Frank Doege wrote: Hi, i have a postfix implementation where i use recipient_bcc maps to duplicate messages which are from users which are on my exchange server. Don't you mean sender_bcc_maps in that case ? This is needed because users still want to be able to read there mail with the conventional imap system ( so forwarding is no solution ). The problem is that postfix seems to generate the bcc message before the spamfilter and then send it without checks to the exchange. The first is correct, the second is highly unlikely. recipient_bcc_maps is parsed by cleanup(8), duplicating the message before it hits the incoming queue. If you use the normal after-queue content_filter as your spam filter, then both messages will be processed by it. You'd have to show logs of this happening to convince me that a bcc'd message bypasses the content-filter. Of course, since you're not sharing what this "spamfilter" actually is, GIGO. How can i change that behavior ? I would like that postfix does the bcc after the spamfilter(amavis) has been run. You could move the duplication to virtual_alias_maps: incom...@domain.commail...@delivery.com bcc_addr...@somehwere.com For more details, refer to http://www.postfix.org/ADDRESS_REWRITING_README.html#auto_bcc and http://www.postfix.org/FILTER_README.html J.
Re: recipient bcc at which point does the mail get duplicated
Hi Jeroen, i just checked again and now its run before the duplication, i still have to investigate how this mail (the reason i started to investigate) slipped through. Working now as expected. thanks for your help Frank
Re: recipient bcc at which point does the mail get duplicated
Frank Doege: > The problem is that postfix seems to generate the bcc message before > the spamfilter > and then send it without checks to the exchange. Look in the Postfix FILTER_README for no_address_mappings. Wietse
Re: processing time metrics for rejected connections
On 09/04/2010 10:42 PM, Stan Hoeppner wrote: Victor Duchovni put forth on 9/4/2010 7:33 AM: What do you mean by "filters"? Spam filters in the form of table lookups and dnsbl queries. I'm currently processing 12,581 CIDRs 1,568 regular expressions (PCRE) 5 dnsbl lookups per each inbound connection (assuming no hits). Obviously a hit in a table early on in the processing order is going to cut the time down. I'm just wondering how much time is being consumed by processing all of these and the lookup delays to the dnsbl servers. Is it so small it's irrelevant, or is it large enough it could become an issue as I add more tables/entries and/or dnsbls, and inbound mail volume increases? Say I add another 20k CIDR or 1,500 more PCRE entries? That should be relatively easy to determine given a few messages of which it is known where they hit the filters, and your normal delays values. If the difference shows up in the pre-queue delay at all, you can calculate stuff. If it doesn't, it means the difference is < 1ms and I wouldn't worry about it ;) For best results, try a message that hits the first filter, something in the middle, and something that doesn't hit at all. DNSBL checks are by far the biggest impact, being orders of magnitude slower than any other possible check - it has to do a DNS call and wait for the result. As for your original question, the combined processing time of all your smtpd_* checks will still be reflected in the delay-"a" value (pre-queue). Whatever time postfix itself adds for processing will be either static or insignificant (unless you have lots of expensive maps) . FYI this is an old dual CPU 500 MHz 32bit x86 machine. Now you may understand my concern about running large numbers of PCREs and CIDRs per connection. Even with these old CPUs, processing these tables may be a piece of cake, I simply don't know. That's why I'm asking. Mostly memory usage - all those are permanently loaded in memory. CIDRs are nicely compacted, and should perform equivalent to a tree search (matching closest-subnet-first). Regexen cannot be optimized much, of course, so they will by their nature be slower. Why not run a few hundred messages in debug mode and record the processing start-end times of all of those tests ? It's not as if this will fluctuate over time. Using any (or all) of the methods I mentioned should at least give you a rough indication of the time taken for CIDR checks, Regex checks, and DNSBL checks. It may be that all of this is a total non issue, and if so, I'd like to know that. Thanks.
Re: processing time metrics for rejected connections
Jeroen Geilman: > As for your original question, the combined processing time of all your > smtpd_* checks will still be reflected in the delay-"a" value (pre-queue). > Whatever time postfix itself adds for processing will be either static > or insignificant (unless you have lots of expensive maps) . The bulk of the time in smtpd_mumble_restrictions happens between these two logfile records: smtpd[pid]: connect from name[addr] (reverse/forward name lookup completed) smtpd[pid]: queueid: client=name[addr] (first recipient accepted) The delay-'a' value measures the time since the incoming queue file was created, i.e. when the first recipient was accepted. This is why most rejects are logged with NOQUEUE as the queue ID. Wietse
Re: processing time metrics for rejected connections
On 09/05/2010 04:59 PM, Wietse Venema wrote: Jeroen Geilman: As for your original question, the combined processing time of all your smtpd_* checks will still be reflected in the delay-"a" value (pre-queue). Whatever time postfix itself adds for processing will be either static or insignificant (unless you have lots of expensive maps) . The bulk of the time in smtpd_mumble_restrictions happens between these two logfile records: smtpd[pid]: connect from name[addr] (reverse/forward name lookup completed) smtpd[pid]: queueid: client=name[addr] (first recipient accepted) The delay-'a' value measures the time since the incoming queue file was created, i.e. when the first recipient was accepted. This is why most rejects are logged with NOQUEUE as the queue ID. Wietse Ack, thanks - I often wondered about that one (and the "unknown[unkown]" client conundrum - but that's probably an artifact of the socket handling code.) I guess you could try to calculate something out of the logs between those two events, but there may be a lot of noise in that (at a minimum, you'd have to match up the pids). Having a syslogd that records milliseconds would also help in that; I know rsyslogd can write ms logs, since I use that myself. J.
Trying to use different header_checks depending on TCP port for incoming mail
I'm currently trying to figure out if it is possible to use different header_checks for TCP ports 25 (mail from world) and 587 (mail submitted by authenticated users). I tried the following without success: # cat /etc/postfix/master.cf smtp inet n - n - - smtpd -o content_filter=amavis:[127.0.0.1]:10024 submission inet n - n - - smtpd -o content_filter=amavis:[127.0.0.1]:10124 -o smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot -o smtpd_sasl_path=private/dovecot-auth -o smtpd_sasl_security_options=noanonymous -o header_checks=pcre:/etc/postfix/submission_header_checks [...] # postconf header_checks header_checks = pcre:/etc/postfix/header_checks # cat /etc/postfix/submission_header_checks /^Received: from server\.domain\.tld\b/ WARN GOTCHA-submission_header_checks # cat /etc/postfix/header_checks /^Received: from server\.domain\.tld\b/ WARN GOTCHA-header_checks The mail log file reads: # cat /var/log/mail postfix/smtpd[14836]: connect from p57A8518F.dip.t-dialin.net[87.168.81.143] postfix/smtpd[14836]: setting up TLS connection from p57A8518F.dip.t-dialin.net[87.168.81.143] postfix/smtpd[14836]: Anonymous TLS connection established from p57A8518F.dip.t-dialin.net[87.168.81.143]: TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits) postfix/smtpd[14836]: 099013343B8: client=p57A8518F.dip.t-dialin.net[87.168.81.143], sasl_method=PLAIN, sasl_username=foobar postfix/cleanup[14841]: 099013343B8: warning: header Received: from server.domain.tld (p57A8518F.dip.t-dialin.net [87.168.81.143]) by seth.horus-it.com (Postfix) with ESMTPSA id 099013343B8??for ; Sun, 5 Sep 2010 18:57:51 +02 from p57A8518F.dip.t-dialin.net[87.168.81.143]; from= to= proto=ESMTP helo=: GOTCHA-header_checks postfix/cleanup[14841]: 099013343B8: warning: header Received: from server.domain.tld (localhost [127.0.0.1])??by server.domain.tld (Postfix) with ESMTPS id 44F1323A10??for ; Sun, 5 Sep 2010 18:57:50 +0200 (CEST) from p57A8518F.dip.t-dialin.net[87.168.81.143]; from= to= proto=ESMTP helo=: GOTCHA-header_checks [...] If I am not mistaken, this means that although the mail is arriving via the submission port 587, /etc/postfix/header_checks matches? I was of course aiming for /etc/postfix/submission_header_checks. I've read http://www.postfix.org/FILTER_README.html (among other Postfix documentation) because I wondered if content_filter influenced header_checks, but I am none the wiser. Do I perhaps need a second cleanup service? I'd be glad if someone pointed out what I am missing in my setup... Thank you! -Ralph
Re: Trying to use different header_checks depending on TCP port for incoming mail
On 09/05/2010 07:20 PM, Ralph Seichter wrote: I'm currently trying to figure out if it is possible to use different header_checks for TCP ports 25 (mail from world) and 587 (mail submitted by authenticated users). I tried the following without success: Since header_checks is performed by cleanup(8), the submission method has no influence on them. They will be performed for all submitted mail, via any method. You'd have to run multiple postfix instances to be able to configure separate header_checks. J.
Re: Trying to use different header_checks depending on TCP port for incoming mail
Ralph Seichter: > I'm currently trying to figure out if it is possible to use different > header_checks for TCP ports 25 (mail from world) and 587 (mail submitted > by authenticated users). I tried the following without success: > > # cat /etc/postfix/master.cf > smtp inet n - n - - smtpd >-o content_filter=amavis:[127.0.0.1]:10024 > submission inet n - n - - smtpd >-o content_filter=amavis:[127.0.0.1]:10124 >-o > smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject >-o smtpd_sasl_auth_enable=yes >-o smtpd_sasl_type=dovecot >-o smtpd_sasl_path=private/dovecot-auth >-o smtpd_sasl_security_options=noanonymous >-o header_checks=pcre:/etc/postfix/submission_header_checks As documented header_checks are not implemented in smtpd(8) but in cleanup(8). If you are courageous you can implement different cleanup services: /etc/postfix/master.cf" submission . . . . . . . . . . . smtpd -o cleanup_service=cleanup_for_submission cleanup_for_submission . . . . . cleanup -o header_checks=pcre:/etc/postfix/submission_header_checks Wietse
Re: Trying to use different header_checks depending on TCP port for incoming mail
On 05.09.10 20:55, Wietse Venema wrote: > As documented header_checks are not implemented in smtpd(8) but > in cleanup(8). Yup, that's why I asked if I needed a second cleanup service. > If you are courageous you can implement different cleanup > services: > > /etc/postfix/master.cf" > submission . . . . . . . . . . . smtpd > -o cleanup_service=cleanup_for_submission > cleanup_for_submission . . . . . cleanup > -o header_checks=pcre:/etc/postfix/submission_header_checks I just tried this, but the mail log still returns "GOTCHA-header_checks" instead of "GOTCHA-submission_header_checks". postfix/cleanup[16068]: DD8413343CD: warning: header Received: from server.domain.tld (p57A8518F.dip.t-dialin.net [87.168.81.143])??by seth.horus-it.com (Postfix) with ESMTPSA id DD8413343CD??for ; Sun, 5 Sep 2010 21:12:42 +02 from p57A8518F.dip.t-dialin.net[87.168.81.143]; from= to= proto=ESMTP helo=: GOTCHA-header_checks postfix/cleanup[16068]: DD8413343CD: warning: header Received: from server.domain.tld (localhost [127.0.0.1])??by server.domain.tld (Postfix) with ESMTPS id 3424923A10??for ; Sun, 5 Sep 2010 21:12:42 +0200 (CEST) from p57A8518F.dip.t-dialin.net[87.168.81.143]; from= to= proto=ESMTP helo=: GOTCHA-header_checks Could this have anything to do with the messages passing through amavisd-new and returning via 127.0.0.1:10025 ? # cat master.cf smtp inet n - n - - smtpd -o content_filter=amavis:[127.0.0.1]:10024 submission inet n - n - - smtpd # POS1 -o cleanup_service=cleanup_submission -o content_filter=amavis:[127.0.0.1]:10124 -o smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot -o smtpd_sasl_path=private/dovecot-auth -o smtpd_sasl_security_options=noanonymous cleanup unix n - n - 0 cleanup cleanup_submission unix n - n - 0 cleanup -o header_checks=pcre:/etc/postfix/submission_header_checks # Mail returning from AMaViS 127.0.0.1:10025 inet n - n - - smtpd -o content_filter= -o local_header_rewrite_clients= -o local_recipient_maps= -o mynetworks=127.0.0.0/8 -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_milters -o relay_recipient_maps= -o smtpd_authorized_xforward_hosts=127.0.0.0/8 -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_restriction_classes= -o smtpd_sender_restrictions= -o strict_rfc821_envelopes=yes # POS2 # This does not work when placed here, either. # -o cleanup_service=cleanup_submission I also tried moving "-o cleanup_service=cleanup_submission" from the submission section (POS1) to the returning-from-AMaViS section (POS2) in master.cf, but it did no good. I always see "GOTCHA-header_checks" in the mail log. -Ralph
Re: Trying to use different header_checks depending on TCP port for incoming mail
Ralph Seichter: > On 05.09.10 20:55, Wietse Venema wrote: > > > As documented header_checks are not implemented in smtpd(8) but > > in cleanup(8). > > Yup, that's why I asked if I needed a second cleanup service. > > > If you are courageous you can implement different cleanup > > services: > > > > /etc/postfix/master.cf" > > submission . . . . . . . . . . . smtpd > > -o cleanup_service=cleanup_for_submission > > cleanup_for_submission . . . . . cleanup > > -o header_checks=pcre:/etc/postfix/submission_header_checks > > I just tried this, but the mail log still returns "GOTCHA-header_checks" > instead of "GOTCHA-submission_header_checks". > > postfix/cleanup[16068]: DD8413343CD: warning: header Received: from > server.domain.tld (p57A8518F.dip.t-dialin.net [87.168.81.143])??by > seth.horus-it.com (Postfix) with ESMTPSA id DD8413343CD??for > ; Sun, 5 Sep 2010 21:12:42 +02 from > p57A8518F.dip.t-dialin.net[87.168.81.143]; from= > to= proto=ESMTP helo=: > GOTCHA-header_checks > postfix/cleanup[16068]: DD8413343CD: warning: header Received: from > server.domain.tld (localhost [127.0.0.1])??by server.domain.tld > (Postfix) with ESMTPS id 3424923A10??for ; Sun, 5 Sep > 2010 21:12:42 +0200 (CEST) from > p57A8518F.dip.t-dialin.net[87.168.81.143]; from= > to= proto=ESMTP helo=: > GOTCHA-header_checks > > Could this have anything to do with the messages passing through > amavisd-new and returning via 127.0.0.1:10025 ? Are you running header_checks BEFORE or AFTER the external content filter, or both? See the receive_override_options discussion in the Postfix FILTER_README documentation. Wietse
Re: Trying to use different header_checks depending on TCP port for incoming mail
Le 05/09/2010 21:32, Ralph Seichter a écrit : On 05.09.10 20:55, Wietse Venema wrote: As documented header_checks are not implemented in smtpd(8) but in cleanup(8). Yup, that's why I asked if I needed a second cleanup service. If you are courageous you can implement different cleanup services: /etc/postfix/master.cf" submission . . . . . . . . . . . smtpd -o cleanup_service=cleanup_for_submission cleanup_for_submission . . . . . cleanup -o header_checks=pcre:/etc/postfix/submission_header_checks I just tried this, but the mail log still returns "GOTCHA-header_checks" instead of "GOTCHA-submission_header_checks". postfix/cleanup[16068]: DD8413343CD: warning: header Received: from server.domain.tld (p57A8518F.dip.t-dialin.net [87.168.81.143])??by seth.horus-it.com (Postfix) with ESMTPSA id DD8413343CD??for ; Sun, 5 Sep 2010 21:12:42 +02 from p57A8518F.dip.t-dialin.net[87.168.81.143]; from= to= proto=ESMTP helo=: GOTCHA-header_checks postfix/cleanup[16068]: DD8413343CD: warning: header Received: from server.domain.tld (localhost [127.0.0.1])??by server.domain.tld (Postfix) with ESMTPS id 3424923A10??for; Sun, 5 Sep 2010 21:12:42 +0200 (CEST) from p57A8518F.dip.t-dialin.net[87.168.81.143]; from= to= proto=ESMTP helo=: GOTCHA-header_checks Could this have anything to do with the messages passing through amavisd-new and returning via 127.0.0.1:10025 ? # cat master.cf smtp inet n - n - - smtpd -o content_filter=amavis:[127.0.0.1]:10024 submission inet n - n - - smtpd # POS1 -o cleanup_service=cleanup_submission -o content_filter=amavis:[127.0.0.1]:10124 -o smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot -o smtpd_sasl_path=private/dovecot-auth -o smtpd_sasl_security_options=noanonymous cleanup unix n - n - 0 cleanup cleanup_submission unix n - n - 0 cleanup -o header_checks=pcre:/etc/postfix/submission_header_checks # Mail returning from AMaViS 127.0.0.1:10025 inet n - n - - smtpd -o content_filter= -o local_header_rewrite_clients= -o local_recipient_maps= -o mynetworks=127.0.0.0/8 -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_milters -o relay_recipient_maps= -o smtpd_authorized_xforward_hosts=127.0.0.0/8 -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_restriction_classes= -o smtpd_sender_restrictions= -o strict_rfc821_envelopes=yes # POS2 # This does not work when placed here, either. # -o cleanup_service=cleanup_submission I also tried moving "-o cleanup_service=cleanup_submission" from the submission section (POS1) to the returning-from-AMaViS section (POS2) in master.cf, but it did no good. I always see "GOTCHA-header_checks" in the mail log. -Ralph add "-o syslog_name=postsubmission" to both your submission and cleanup_submission and see if it appears in your logs. make sure your amavis:[127.0.0.1]:10124 doesn't forward mail to port 25...
Re: Trying to use different header_checks depending on TCP port for incoming mail
On 05.09.10 22:07, Wietse Venema wrote: > Are you running header_checks BEFORE or AFTER the external content > filter, or both? See the receive_override_options discussion in > the Postfix FILTER_README documentation. Sorry, I re-read the FILTER_README multiple times, but I am not sure how to answer your question. I'll include my master.cf and "postconf -n" output so you can see for yourself: # postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases hash:/usr/local/mailman/data/aliases authorized_flush_users = hash:$config_directory/admins-flush authorized_mailq_users = hash:$config_directory/admins-mailq biff = no body_checks = pcre:$config_directory/body_checks command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib/postfix data_directory = /var/lib/postfix debug_peer_level = 2 defer_transports = header_checks = pcre:$config_directory/header_checks home_mailbox = .maildir/ html_directory = /usr/share/doc/postfix/html mail_owner = postfix mailbox_transport = lmtp:unix:private/dovecot-lmtp mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man message_size_limit = 31457280 mydestination = $myhostname localhost.$mydomain localhost [12.34.56.78] myhostname = server.somedomain.tld mynetworks_style = host myorigin = $mydomain newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix/readme recipient_delimiter = + sample_directory = /etc/postfix sender_canonical_maps = pcre:$config_directory/sender_canonical sendmail_path = /usr/sbin/sendmail setgid_group = postdrop show_user_unknown_table_name = no smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:$config_directory/saslpass smtp_sasl_security_options = noanonymous smtp_tls_CAfile = /etc/ssl/certs/somecafile.pem smtp_tls_cert_file = $config_directory/tls/server.crt smtp_tls_key_file = $config_directory/tls/server.key smtp_tls_loglevel = 1 smtp_tls_note_starttls_offer = yes smtp_tls_security_level = may smtpd_banner = $myhostname ESMTP smtpd_client_restrictions = check_client_access cidr:$config_directory/client_access reject_rbl_client ix.dnsbl.manitu.net reject_rbl_client zen.spamhaus.org reject_rbl_client bl.spamcop.net warn_if_reject reject_rbl_client dnsbl.sorbs.net warn_if_reject reject_unknown_reverse_client_hostname permit smtpd_helo_required = yes smtpd_helo_restrictions = check_helo_access pcre:$config_directory/helo_access reject_invalid_helo_hostname reject_non_fqdn_helo_hostname warn_if_reject reject_unknown_helo_hostname permit smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated check_recipient_access pcre:$config_directory/recipient_access check_policy_service inet:[127.0.0.1]:10023 reject_unauth_destination reject_non_fqdn_recipient reject_unlisted_recipient reject_unknown_recipient_domain reject_unauth_pipelining permit smtpd_sender_restrictions = permit_mynetworks permit_sasl_authenticated check_sender_access pcre:$config_directory/sender_access reject_non_fqdn_sender reject_unknown_sender_domain permit smtpd_tls_CAfile = $smtp_tls_CAfile smtpd_tls_auth_only = yes smtpd_tls_cert_file = $smtp_tls_cert_file smtpd_tls_key_file = $smtp_tls_key_file smtpd_tls_loglevel = $smtp_tls_loglevel smtpd_tls_security_level = may unknown_local_recipient_reject_code = 550 # cat master.cf smtp inet n - n - - smtpd -o content_filter=amavis:[127.0.0.1]:10024 cleanup_submission unix n - n - 0 cleanup -o header_checks=pcre:/etc/postfix/submission_header_checks submission inet n - n - - smtpd -o content_filter=amavis:[127.0.0.1]:10124 -o smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot -o smtpd_sasl_path=private/dovecot-auth -o smtpd_sasl_security_options=noanonymous -o cleanup_service=cleanup_submission pickupfifo n - n 60 1 pickup cleanup unix n - n - 0 cleanup qmgr fifo n - n 300 1 qmgr tlsmgrunix - - n 1000? 1 tlsmgr rewrite unix - - n - - trivial-rewrite bounceunix - - n - 0 bounce defer unix - - n - 0 bounce trace unix - - n - 0 bounce verifyunix - - n - 1 verify flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap proxywrite unix - - n - 1 proxymap smtp unix - - n - - smtp relay unix - - n - - smtp -o smtp_fallback_relay= showq unix n - n - - showq error unix - - n - - error retry unix -
Re: Trying to use different header_checks depending on TCP port for incoming mail
On 06.09.10 00:25, mouss wrote: > add "-o syslog_name=postsubmission" to both your submission and > cleanup_submission and see if it appears in your logs. I see postsubmission/smtpd in the mail log, but postsubmission/cleanup is not logged. So, I guess my cleanup_submission service is not called? > make sure your amavis:[127.0.0.1]:10124 doesn't forward mail to > port 25... I have not set a $forward_method in my amavisd.conf, and the default is "smtp:[127.0.0.1]:10025", which matches Postfix's master.cf. -Ralph
Re: Trying to use different header_checks depending on TCP port for incoming mail
Ralph Seichter: > On 06.09.10 00:25, mouss wrote: > > > add "-o syslog_name=postsubmission" to both your submission and > > cleanup_submission and see if it appears in your logs. > > I see postsubmission/smtpd in the mail log, but postsubmission/cleanup > is not logged. So, I guess my cleanup_submission service is not called? It is not called when amavisd-new injects mail back into Postfix. Wietse
Re: Trying to use different header_checks depending on TCP port for incoming mail
Ralph Seichter: [ Charset ISO-8859-1 unsupported, converting... ] > On 05.09.10 22:07, Wietse Venema wrote: > > > Are you running header_checks BEFORE or AFTER the external content > > filter, or both? See the receive_override_options discussion in > > the Postfix FILTER_README documentation. > > Sorry, I re-read the FILTER_README multiple times, but I am not sure how > to answer your question. I'll include my master.cf and "postconf -n" > output so you can see for yourself: FYI, There is an smtpd+cleanup server AFTER your content filter. See the receive_override_options discussion how to avoid doing stuff on the wrong side of the filter. Wietse
