| Commit message (Collapse) | Author | Age | Files |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The clients are identified using their certificate, and connect securely
to the SyncProv.
There are a few workarounds (XXX) in the ACLs due to Postfix not
supporting SASL binds in Wheezy.
Overview:
- Authentication (XXX: strong authentication) is required prior to any DIT
operation (see 'olcRequires').
- We force a Security Strength Factor of 128 or above for all operations (see
'olcSecurity'), meaning one must use either a local connection (eg,
ldapi://, possible since we set the 'olcLocalSSF' to 128), or TLS with at
least 128 bits of security.
- XXX: Services may not simple bind other than locally on a ldapi:// socket.
If no remote access is needed, they should use SASL/EXTERNAL on a ldapi://
socket whenever possible (if the service itself supports SASL binds).
If remote access is needed, they should use SASL/EXTERNAL on a ldaps://
socket, and their identity should be derived from the CN of the client
certificate only (hence services may not simple bind).
- Admins have restrictions similar to that of the services.
- User access is only restricted by our global 'olcSecurity' attribute.
|
| | |
|
| |
|
|
|
|
| |
E.g., ldap.fripost.org, ntp.fripost.org, etc. (Ideally the DNS zone
would be provisioned by ansible, too.) It's a bit unclear how to index
the subdomains (mx{1,2,3}, etc), though.
|
| |
|
|
| |
(To be removed when the fix enters stable.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We introduce a limitation on the domain-aliases: they can't have
children (e.g., lists or users) any longer.
The whole alias resolution, including catch-alls and domain aliases, is
now done in 'virtual_alias_maps'. We stop the resolution by returning a
dummy alias A -> A for mailboxes, before trying the catch-all maps.
We're still using transport_maps for lists. If it turns out to be a
bottleneck due to the high-latency coming from LDAP maps, (and the fact
that there is a single qmgr(8) daemon), we could rewrite lists to a
dummy subdomain and use a static transport_maps instead:
virtual_alias_maps:
mylist@example.org -> mylist#example.org@mlmmj.localhost.localdomain
transport_maps:
mlmmj.localhost.localdomain mlmmj:
|
| |
|
|
|
|
|
|
|
| |
Right now the list server cannot be hosted with a MX, due to bug 51:
http://mlmmj.org/bugs/bug.php?id=51
Web archive can be compiled with MHonArc, but the web server
configuration is not there yet.
|
| |
|
|
|
|
| |
They were only a dirty hack for list commands à la Mailman such as
mylist-request. If we are to use another list manager such as mlmmj,
which uses a VERP delimiter instead, the problem disappears.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, we pretend that lists are valid users (via a match in the
mailbox_transport_maps) but choose a different transport (with the same
request in transport_maps).
The advantage is that we get rid of the ugly hack for list transport…
A minor drawback is that we now have two LDAP lookups instead of one for
non local addresses (ie, everything but reserved addresses). Hopefully
the requests are cached; but even if they aren't, querying a local LDAP
server is supposed to be cheap.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Mails to be retrained are stored in the spooldir /home/mail/spamspool;
later a daemon catches them up and feed them to sa-learn(1p). (On busy
systems batch-process the learning should be much more efficient.)
The folder transisition matrix along with the corresponding actions can
be found there:
http://hg.dovecot.org/dovecot-antispam-plugin/raw-file/5ebc6aae4d7c/doc/dovecot-antispam.7.txt
See also dovecot-antispam(7).
|
| | |
|
| |
|
|
|
|
| |
It'd certainly be nicer if we didn't have to deploy amavis' schema
everywhere, but we need the 'objectClass' in our replicates, hence they
need to be aware of the 'amavisAccount' class.
|
| |
|
|
|
|
|
|
|
|
|
| |
Antispam & antivirus, using ClamAV and SpamAssassin through Amavisd-new.
Each user has his/her amavis preferences, and own Bayes filter (to
maximize privacy).
One question remains, though: how to set spamassassin's trusted_networks
/ internal_networks / msa_networks? It seems not obivious to get it
write with IPSec and dynamic IPs.
(Cf. https://wiki.apache.org/spamassassin/AwlWrongWay)
|
| | |
|
| | |
|
| |
|
|
| |
(Hence the SyncProv overlay.)
|
| | |
|
| |
|
|
| |
As of 2.9.6 (2.10), at least. See bug #730848.
|
| | |
|
| |
|
|
|
|
|
| |
This is because the UNIX domain socket to connect to when performing
LDAP lookups needs to be in the chroot.
Also, don't open a INET socket unless we're a Sync Provider.
|
| |
|
|
|
|
| |
"username=postfix,cn=peercred,cn=external,cn=auth" is replaced by
"gidNumber=106+uidNumber=102,cn=peercred,cn=external,cn=auth" where 102
is postfix's UID and 106 its primary GID (looked up from /etc/passwd).
|
| |
|
