On 11/23/2017 12:28 PM, Niclas Rautenhaus wrote:
Hi list,
I am experiencing an issue with my postfix setup.
The desired results:
We use an appliance that archives all mails (incoming and outgoing) -
due to laws that have been enforced here in Germany.
The documentation of the appliance states, that the main.cf should be
updated with the following lines, which has been done
always_bcc=bcc-address@bcc-domain.local
<mailto:always_bcc=bcc-address@bcc-domain.local>
In addition to that, in the transport_maps the IP and domain name of
the appliance needs to be listed, which – again - has been done
bcc-domain.local smtp:[192.168.N.NN]:1025
So far, so good. The transport_maps file was rehashed multiple times,
and postfix got its restart.
But since I integrated the appliance into the postfix configuration, I
get the symptoms as described below
The symptoms:
I am not yet sure whether all incoming mails are affected or not, but
at least sometimes I get the following entry in my mailq (and
respecively the mail.log):
5086760443 35318 Mon Nov 13 16:04:20 u...@externaldomain.tld
<mailto:u...@externaldomain.tld>
(lost connection with 192.168.N.NN[192.168.N.NN] while sending end of
data -- message may be sent more than once)
bcc-address@bcc-domain.local <mailto:bcc-address@bcc-domain.local>
I had some similar symptom on a mail host with multiple uplink provider
setup . The problem went away by reducing the mtu on the default
interface by a litle. I don't know if that will apply to your situation
though....
Additionally, some mails are put twice in the queue, again I am not
100% sure whether all mails are affected by this or not:
7344360456 21858 Mon Nov 13 15:39:39 u...@internaldomain.tld
<mailto:u...@internaldomain.tld>
(lost connection with 192.168.N.NN[192.168.N.NN] while sending end of
data -- message may be sent more than once)
bcc-address@bcc-domain.local <mailto:bcc-address@bcc-domain.local>
bcc-address@bcc-domain.local <mailto:bcc-address@bcc-domain.local>
The configuration:
There are three filters I work with: spamassassin, clamav, KLMS
I already found out - thanks to postings on this mail list - that
when using "amavis" there are sometimes problems with the always_bcc
attribute as well, but implementing the no_address_mappings did not
resolve the issues.
Here are excerpts from my main.cf and master.cf
Output of "postconf -n"
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
always_bcc = bcc-address@bcc-domain.local
<mailto:bcc-address@bcc-domain.local>
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = klms_postfix-afterqueue:127.0.0.1:10025
daemon_directory = /usr/lib/postfix
data_directory = /var/lib/postfix
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
ddd $daemon_directory/$process_name $process_id & sleep 5
default_privs = nobody
html_directory = /usr/share/doc/postfix/html
inet_interfaces = $myhostname, localhost
inet_protocols = ipv4
local_recipient_maps = unix:passwd.byname $alias_maps
mail_owner = postfix
mailbox_size_limit = 152428800
mailbox_transport = cyrus
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
message_size_limit = 152428800
mydestination = $myhostname, localhost.$mydomain, localhost
mydomain = domain.tld
myhostname = mail.domain.tld
mynetworks = 127.0.0.0/8 192.168.0.0/16 YY.YYY.YY.YYY/32 BB.BBB.BB.BBB/32
myorigin = $mydomain
newaliases_path = /usr/sbin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix
receive_override_options = no_address_mappings
relay_domains = $mydestination
relayhost = smtp.externalhoster.tld
sample_directory = /usr/share/doc/postifx/examples
sender_canonical_maps = hash:/etc/postfix/sender_canonical
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_auth
smtp_sasl_security_options = noanonymous
smtp_tls_mandatory_protocols = !SSLv2 !SSLv3
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = may
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_tls_mandatory_protocols = !SSLv2 !SSLv3
smtpd_tls_protocols = !SSLv2 !SSLv3
transport_maps = hash:/etc/postfix/transport_maps
unknown_local_recipient_reject_code = 550
In the main.cf this entry "content_filter =
klms_postfix-afterqueue:127.0.0.1:10025" is needed for the KLMS filter
master.cf:
The excerpts displaying the three filters:
# spamassassin
spamassassin unix - n n - - pipe
user=debian-spamd argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f
${sender} ${recipient}
# AV scan filter (used by content_filter)
scan unix - - n - 16 smtp
-o smtp_send_xforward_command=yes
-o smtp_enforce_tls=no
#klms-begin-afterqueue-filter
klms_postfix-afterqueue unix - - n -
10 smtp
-o smtp_send_xforward_command=yes
127.0.0.1:10026 inet n - n - 10 smtpd
-o content_filter=
-o content_filter=scan:[127.0.0.1]:10027
-o
receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8,[::1]/128
-o smtpd_authorized_xforward_hosts=127.0.0.0/8,[::1]/128
#klms-end-afterqueue-filter
# For injecting mail back into postfix from the filter
127.0.0.1:10028 inet n - n - 16 smtpd
-o content_filter=
-o
receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_address_mappings
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks_style=host
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
Note that I did not change the master.cf and main.cf back to it's
default values speaking of the "no_address_mappings" directive.
I carefully implemented that directive at any place that seemed
logical to me, to no avail.
Debugging the issue by making the smtpd -v and -vv generated more
output that was logged, however it did not help me understand where
the issue comes from.
Could anybody shed some light on this issue?
Any help is appreciated, if more logfiles / information is needed,
just ask.
Regards,
Niclas
