Thanks to your help, I think I have found where DSPAM should get called for my setup: in the postfix before-queue content filter. I found the following documentation on postfix which explains quite well how to set this up:
http://www.postfix.org/SMTPD_PROXY_README.html they also state that it should work with any content filter as long as it speaks SMTP. What do you think? I have the feeling that's exactly what we need for our similar setup. On Monday, June 9, 2014 11:38 AM, Reindl Harald <h.rei...@thelounge.net> wrote: Am 09.06.2014 11:13, schrieb ML mail: > In my understanding content filtering such as dspam should > also happen before the transport table/map is being checked > for relaying the mail to the backend mail server but then I must > be missing a parameter again for that which is not explained in > the doc/relay.txt of the dspam package. The documentation only > mentions using virtual transport which I also have configured. uhm - as said - i consider using dspam and only a heavy postfix user but until now not for mail-filter-gateways with multiple destination servers at least "transport_maps" and "virtual_transport" combined may not work as expected because whatever the first transport is wins - in my understanding dspam needs to work inside of smtpd_*_restrictions and any transport happens if a message passes all filters and restricitions however - *how* can dspam work as *pre-queue* filter in context of lmtpd? does it receive the whole message, let the connection open due scanning and if it is spam rejects it? pre-queue is important to not get a backscatter please consider asking that in detail on the postfix-uers list because there are a lot of expierienced users, i am not at the point testing this since i wait for CentOS7 and in general your goal is very similar to my plans > Below is the output of y postconf -n: > > alias_database = hash:/etc/aliases > alias_maps = hash:/etc/aliases > append_dot_mydomain = no > biff = no > config_directory = /etc/postfix > inet_interfaces = allowed > mailbox_command = procmail -a "$EXTENSION" > mailbox_size_limit = 0 > mydestination = mx.domain.tld, debian, localhost.localdomain, localhost > myhostname = debian > mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 > myorigin = /etc/mailname > readme_directory = no > recipient_delimiter = + > relayhost = > smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache > smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) > smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem > smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key > smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache > smtpd_use_tls = yes > transport_maps = hash:/etc/postfix/transport > virtual_mailbox_domains = mydomain.com > virtual_mailbox_maps = pgsql:/etc/postfix/vmailbox.cf > virtual_transport = lmtp:unix:/run/dspam.sock > > On Monday, June 9, 2014 10:17 AM, Reindl Harald <h.rei...@thelounge.net> > wrote: > Am 09.06.2014 09:50, schrieb ML mail: >> I was assuming that this relay guide was a full howto, my bad. >> >> Now as pointed out by yourself and Reindl I have added a transport table to >> my postfix >> configuration in order to relay the mails to the backend server. For that >> purpose I >> have added the following configuration to postfix: >> >> transport_maps = hash:/etc/postfix/transport >> >> The content of my transport file looks like this: >> >> mydomain.com smtp:mybackendserver.domain.tld >> >> >> The problem here with this new configuration is that my postfix does not >> pass the mail >> to dspam anymore for scanning, so the mail simply goes through directly >> unscanned to >> the backend server. Am I missing something else? > > i am currently not a dspam user but considering it in exactly such a setup > and would expect it to work a *pre-queue* filter which is the only correct > way of reject spam which normally means the transports after the spamfiler > because the filter belongs in smtpd_*_restricitions somehow > > maybe the output of "postconf -n" could help to fugure out your setup > > the reason why i plan such a setup is: > > * dedicated MX as filter repalcing a Barracuda Networks appliance > * different target servers per domain solved with a transport table > * the final destinations are dbmail and so all infos already in mysql > * a simple script should maintain the local users table and transports > > my planned order: > > * postscreen / rbl scoring > * maybe greylisting > * clamav > * DNS whitelists to bypass contentfilter > * contentfilter (dspam, spamassassin...) > * transport table to deliver ham to final destiantion ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://www.hpccsystems.com _______________________________________________ Dspam-user mailing list Dspam-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-user ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://www.hpccsystems.com _______________________________________________ Dspam-user mailing list Dspam-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-user
