| Commit message (Collapse) | Author | Age | Files |
... | |
|
|
|
|
| |
This decision is left to the MX (as for 'fripostIsStatusActive'), which
will set the envelope recipient accordingly.
|
| |
|
|
|
|
| |
(It opens the key as root, but then drops the permissions.)
|
|
|
|
|
| |
First generate all certs (-t genkey), then build the TLS policy maps (
-t tls_policy).
|
| |
|
| |
|
|
|
|
|
| |
Use it to delete cn=admin,dc=fripost,dc=org, and to remove the rootDN on
the 'config' database.
|
|
|
|
|
| |
The SyncProv won't start if the file olcTLSCACertificateFile points to
doesn't exist.
|
|
|
|
|
|
| |
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).
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
'if $l' is false when $l is 0, while 0@example.org is a perfectly valid
address.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Also, it's now possible to reuse an existing private key (with -f).
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
SMTP client connection caching was introduced in 2.6.0: the SMTP session is
held for the next task (in adaptative mode, only when there was a delay of only
5s between the two previous mails), but Postfix will terminate it if the next
mail doesn't come soon enough, or if amavis does't terminate it itself (usually
after 15s).
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
(Unless a new instance is created, or the master.cf change is modified.)
Changing some variables, such as inet_protocols, require a full restart,
but most of the time it's overkill.
|
|
|
|
|
|
| |
And don't restart or reload either upon change of pcre: files that are
used by smtpd(8), cleanup(8) or local(8), following the suggestion from
http://www.postfix.org/DATABASE_README.html#detect .
|
|
|
|
| |
So unfortunately we can't fit a 2048-bits RSA key.
|
| |
|
| |
|
|
|
|
| |
For DKIM signing and virus checking.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Unlike adduser(8), ansible's 'user' module copies skeletal configuration
files even for system users (unless called with createhome=no).
|
|
|
|
|
|
|
| |
This is important as we don't want the IMAP server baning the webmail,
for instance. (The fail2ban instance running next to the webmail should
ban the attacker, but that running next to the IMAP server shouldn't ban
legit users.)
|
|
|
|
|
|
|
| |
The reason is that we don't want to rely on CAs to verify the
certificate of our server. Dovecot currently doesn't offer a way to
match said cert against a local copy or known fingerprint. stunnel
does.
|
| |
|
|
|
|
|
| |
For some reason giraff doesn't like IPSec. App-level TLS sessions are
less efficient, but thanks to ansible it still scales well.
|
| |
|
|
|
|
|
|
|
| |
In 2.1.7 they are buggy, and make Dovecot crash (when connected through
Evolution for instance). They have improved a lot since, though:
http://hg.dovecot.org/dovecot-2.2/file/c55c660d6e9d/NEWS
|
|
|
|
|
|
| |
Sadly not doing so and keeping a table message ID -> username, like we
do for SASL authenticated users, doesn't seem trivial here. We could
encrypt the header, though.
|
| |
|
| |
|
| |
|
| |
|
| |
|