| Commit message (Collapse) | Author | Age | Files |
|---|
| |
|
|
|
|
|
|
| |
It looks as if the SyncRepl need read access on the 'entry' and
'objectClass' attributes of the entry being deleted, and the entry being
deleted no longer matches the ACL filters, so we have to grant access
globally. (We still have fine-grain control on the other attributes
which are not disclosed, though.)
|
| |
|
|
|
| |
This decision is left to the MX (as for 'fripostIsStatusActive'), which
will set the envelope recipient accordingly.
|
| | |
|
| |
|
|
|
|
| |
So our suffix is now a mere 'dc=fripost,dc=org'. We're also using the
default '/var/lib/ldap' as olcDbDirectory (hence we don't clear it
before hand).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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)
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
As of 2.9.6 (2.10), at least. See bug #730848.
|
| | |
|
| |
|
|
|
|
| |
"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).
|
| |
|
