| Commit message (Collapse) | Author | Age | Files |
|---|
| ... | |
| |
|
|
|
|
| |
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).
|
| |
|
