January 25, 2010 -
This will just explain the configuration files needed for Postfix to check against the LDAP server.
We want to be able to send emails to username@domain.tld
We also want to have aliases for our users, for example : firstname.lastname@domain.tld pointing to username@domain.tld
Finally, we want groups to act as a mailing list, forwarding emails to members of the group, for example : support@domain.tld
LDAP tree
dc=domain,dc=tld
|-------ou=Aliases,dc=domain,dc=tld
|---------------cn=support,ou=Aliases,dc=domain,dc=tld
|
| cn : support
| description : alias support
| gidNumber : 50000
| mailRoutingAddress : support@domain.tld
| memberUid : it (this is a group with a inetLocalMailRecipient class and a mailRoutingAddress field defined)
| memberUid : username3 (this is a user account)
|
|-------ou=Groups,dc=domain,dc=tld
|---------------cn=it,ou=Groups,dc=domain,dc=tld
|
| cn : it
| description : IT dept group
| gidNumber : 40000
| mailRoutingAddress : it@domain.tld
| memberUid : username1
| memberUid : username2
|
|-------ou=Users,dc=domain,dc=tld
|---------------uid=username1,ou=Users,dc=domain,dc=tld
cn : username1
gecos : John Doe
gidNumber : 10000
homeDirectory : /home/username1
mail : john.doe@domain.tld
mailLocalAddress : john.doe
uid : username1
[...]
Postfix configuration
For this to work, we must define “append_at_myorigin = yes” in main.cf
For group/alias emails to work, the group must have the inetLocalMailRecipient class and mailRoutingAddress defined
So we basically add in main.cf :
virtual_alias_maps = ldap:/etc/postfix/ldap-account.cf, ldap:/etc/postfix/ldap-group.cf, ldap:/etc/postfix/ldap-alias.cf
It means that Postfix will check ldap-account.cf first, then ldap-group.cf and finally ldap-alias.cf.
So we create those files :
ldap-account.cf (for virtual users) :
server_host = localhost
port = 389
version = 3
search_base = ou=Users,dc=domain,dc=tld
scope = sub
# we search through the Users base for the recipient email address (%s)
query_filter = (mail=%s)
# if we find anything under ou=Users,dc=domain,dc=tld, we deliver to the account specified under "uid"
# so basically, if we send an email to john.doe@domain.tld, we will find an entry, finally delivering the email to uid username1
result_attribute = uid
ldap-alias.cf (for virtual aliases) :
server_host = localhost
port = 389
version = 3
scope = sub
# we search through the Aliases base...
search_base = ou=Aliases,dc=domain,dc=tld
# ...for the recipient email address (%s) specified under mailRoutingAddress field
query_filter = mailRoutingAddress=%s
# If we find anything, return memberUid, that can be accounts, groups, or aliases
result_attribute = memberUid
ldap-group.cf (for virtual groups) :
server_host = localhost
port = 389
version = 3
scope = sub
# Same as aliases, but in a different base
search_base = ou=Groups,dc=domain,dc=tld
query_filter = mailRoutingAddress=%s
result_attribute = memberUid
December 9, 2007 -
A while ago, I wrote an howto explaining how to set up a Debian box with Postfix and DSPAM as anti-spam solution.
I haven’t been able to test that howto in a real world environment yet (receiving and training the system with actual spam). Somehow, it has been reported by several persons that it was working (thanks guys !).
The howto was considering a small domain where the sysadmin would take care of retraining the system. (Don’t get me started on that. I prefer retraining the system myself than having a miserable spam detection rate because “users” don’t get involved in fighting spam.)
Somehow, the howto did not fit to customers needs, and so, I figured I should write an addendum to the 1st howto.
Basically, the customer doesn’t always have a sysadmin available on site. The users must retrain DSPAM themselves.
DSPAM offers a web interface to manage emails, quarantines, etc.
The following howto tries to explain how to get the whole thing running, it involves several changes in DSPAM configuration.
Also, please note mod_auth_mysql is not available in the stable repo for Etch, the howto explains how to compile it.
Here’s the link to the howto : Debian + Postfix + DSPAM + WebUI + MySQL auth
The howto is provided “as is”. I could not find the time lately to thoroughly test it.
I decided to publish it since the documentation regarding the WebUI is pretty poor.
I repeat, the howto is still a work in progress ! To be continued.
Let me know if it works for you.
September 12, 2007 -
I have tried to document the new email setup I’m willing to install at work.
My current setup is running under CentOS, uses SpamAssassin and courier-imap.
I’m trying to make the switch to different technologies : Debian, DSPAM and Dovecot.
DSPAM and Dovecot are apparently known to use less ressources, and ressources are an issue where I work (a non-profit org)
To avoid any problem of crazy text reformatting by Wordpress, the howto is downloadable as a text file :
Download it here :
http://www.wains.be/pub/postfix/postfix-debian.txt
Please, if you use it, let me know and tell me how it went.
There must be some mistakes around and I’d be grateful if you can provide some feedback on the quality of this documentation.
Please note : I have NOT tested Dspam in a live environment yet, so I can’t swear it would be efficient in this setup.
USE AT YOUR OWN RISK. YOU MUST TEST YOUR SETUP BEFORE PUTTING IN PRODUCTION.
August 23, 2007 -
OS : Debian Etch
Postfix : 2.3.8
Dspam : 3.6.8
I was following the official dspam documentation (http://dspam.nuclearelephant.com/text/README-3.6.7.txt) to set up Postfix and DSPAM.
I had this under /etc/postfix/master.rc :
smtp inet n - n - - smtpd -v
-o content_filter=lmtp:unix:/var/run/dspam/dspam.sock
localhost:10026 inet n - n - - smtpd
-o content_filter=
-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
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
But Postfix would not connect to dspam socket, the logs were returning :
Aug 22 14:58:23 vm-debian4 postfix/lmtp[24981]: 0FE1F43F7E: to=user at domain.lan, relay=none, delay=0.12, delays=0.08/0.04/0/0, dsn=4.4.1, status=deferred (connect to mx.domain.lan[/var/run/dspam/dspam.sock]: No such file or directory)
Usually, such a problem can occur if you’re running postfix as chrooted, you then need to put the sock file under the chroot (usually /var/spool/postfix/…). It can also occur if the permissions to the socket file are not set properly.
The default Debian install of Postfix doesn’t run as chrooted.
You can usually tell if a process is chrooted in master.rc :
This instance would run chrooted :
smtp inet n - y - - smtpd
While this one wouldn’t :
smtp inet n - n - - smtpd
As you can notice, the 3rd dash specifies if the process will run chrooted or not…
The fix !!
By default, master.rc had this :
lmtp unix - - - - - lmtp
It isn’t explicitely declared that lmtp should run “not-chrooted”
Changing to :
lmtp unix - - n - - lmtp
… fixed the issue ! ltmp is now explicitedly not chrooted and postfix and dspam now work together.
Thanks to the guys on #postfix (irc.freenode.net) !
April 26, 2007 -
I used to use Amavisd-new on our email gateway at work. It sucks. It was a memory hog and was consuming around 400 Mb of swap. It was making it difficult to upgrade clamav, something would break anytime you upgraded. I had a very basic use of amavis, I needed to get rid of it and find a better setup.
Basically, I just wanted to pipe the mails into ClamAV then if no viruses were found, pipe them in SpamAssassin, ideally doing all that from procmail.
And then someone came up with “clamassassin” : http://jameslick.com/clamassassin/
(available in the unstable Debian repository)
clamassassin is a simple virus filter wrapper for ClamAV for use in procmail filters and similiar applications. clamassassin's interface is similiar to that of spamassassin, making it easy to implement for those familiar with that tool. clamassassin is designed with an emphasis on security, robustness and simplicity.
Compile clamassassin as described in the docs.
This is my procmail filter (/etc/postfix/procmail/master.rc) :
SHELL=/bin/sh
DROPPRIVS=YES
LINEBUF=32768
SENDMAILFLAGS="-oi"
SPAMC="/usr/bin/spamc"
FORMAIL="/usr/bin/formail"
FROM="< $1>"
SHIFT=1
# Virus checks
:0fw
| /etc/postfix/clamassassin/clamassassin
# Virus found --> Sent to catchvirus
:0
* ^X-Virus-Status: Yes
! catchvirus@domain.be
# No virus found --> SpamAssassin checks
:0f
|$SPAMC -u spamd -f -s 125000 -U /var/run/spamd.sock
# Spam score 10+ --> email destroyed
:0
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*
{
SWITCHRC="/etc/postfix/procmail/killspam.rc"
}
# Spam score 8-10 --> Sent to catchspam with priority low
:0
* ^X-Spam-Level: \*\*\*\*\*\*\*\*
{
SWITCHRC="/etc/postfix/procmail/logspamlow.rc"
}
# Spam score 6-8 --> Sent to catchspam with priority normal
:0
* ^X-Spam-Level: \*\*\*\*\*\*
{
SWITCHRC="/etc/postfix/procmail/logspamnormal.rc"
}
# Spam score 0-6 --> Delivered tagged if spam score 3+
:0
! -f $FROM "$@"
If a virus is found, it is sent to a special mailbox, or the mail continues its way in the procmail filter. Depending on the spam score, the procmail script is switching to another procmail script. Those scripts can be downloaded from this post : Postfix + virtual users/domains : kill or forward spam under SpamAssassin using procmail
I call the procmail script in Postfix by the following placed in master.rc :
procmail unix - n n - 10 pipe
flags=Rq user=filter argv=/usr/bin/procmail -Y -m /etc/postfix/procmail/master.rc ${sender} ${recipient}
192.168.20.3:smtp inet n - y - 10 smtpd
-o content_filter=procmail
-o smtpd_sasl_auth_enable=no
-o smtpd_helo_restrictions=permit_mynetworks,reject_non_fqdn_hostname
-o smtpd_client_connection_count_limit=5
-o smtpd_client_connection_rate_limit=5
If you want to rewrite subjects, this is an interesting article :
http://john.ellingsworth.org/?p=16
Thanks to mjhall.org for their howto about clamassassin : http://www.mjhall.org/email.php
This is the swap space state, can you guess when I stopped using amavis and switched to clamassassin ?
March 5, 2007 -
I decided to give a try to DCC on our CentOS 3.8 mail gateway running Postfix.
SpamAssassin 3.1.8 was already installed.
January 25, 2007 -
Bounce messages sent by the postfix daemon used to be hardcoded until version 2.3.
This is actually great news for non-english speaking or not email-litterate users.
December 15, 2006 -
This command will give you the string that should be passed at AUTH PLAIN
For test@domain.be, you’d type this :
perl -MMIME::Base64 -e 'print encode_base64("\000test\@domain.be\000password")'
November 18, 2006 -
Scenario :
You run Postfix non-chrooted with SMTP auth though SASL authentication (using saslauthd)
The issue :
When chrooted, Postfix needs access to saslauthd sock file, which is not in the chroot area
The fix :
-
Scenario :
You run Postfix non-chrooted with a MySQL DB as backend.
The issue :
You can’t run Postfix chrooted because the MySQL sock is not located in the chroot area.
The fix :
Next Page »
