| Commit message (Collapse) | Author | Age | Files |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
certificate.
See postconf(5). This avoids the “(Client did not present a
certificate)” messages in the Received headers.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Following Viktor Dukhovni's 2015-08-06 recommendation
http://article.gmane.org/gmane.mail.postfix.user/251935
(We're using stronger ciphers and protocols in our own infrastructure.)
|
| |
|
|
|
|
| |
Following Viktor Dukhovni's 2015-08-06 recommendation for Postfix >= 2.11
http://article.gmane.org/gmane.mail.postfix.user/251935
|
| |
|
|
|
|
|
|
|
|
| |
Ideally we we should also increase the Diffie-Hellman group size from
2048-bit to 3072-bit, as per ENISA 2014 report.
https://www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014
But we postpone that for now until we are reasonably certain that older
client won't be left out.
|
| |
|
|
| |
That is, on the MSA and in our local infrastructure.
|
| | |
|
| | |
|
| |
|
|
|
| |
Put all relay restrictions under smtpd_relay_restrictions and leave
smtpd_recipient_restrictions empty, since we don't do DNSBL.
|
| |
|
|
|
|
|
| |
We don't want to bounce messages for which the recipient(s)' MTA replies
451 due to some greylisting in place. We would like to accept 451
alone, but unfortunately it's not possible to bounce unverified
recipients due to DNS or networking errors.
|
| |
|
|
|
|
| |
In particular, since Postfix is now able to perform LDAP lookups using
SASL, previous hacks with simble binds on cn=postfix,ou=services,… can
now be removed.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
See http://www.postfix.org/POSTSCREEN_README.html and
http://rob0.nodns4.us/postscreen.html
It's infortunate that smtpd(8) cannot be chrooted any longer, which
means that we have to un-chroot cleanup(8) as well. Indeed, currently
smtpd(8) uses $virtual_alias_maps for recipient validation; later
cleanup(8) uses it again for rewriting. So these processes need to be
both chrooted, or both not.
|
| | |
|
| |
|
|
|
| |
There are false-positive with that, for instead due to SOA records
pointing to non-existing subdomains.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
On the MDA the domain is our 'mda.fripost.org', there is no need to
perform an extra DNS lookup.
The MSA does not perform local or virtual delivery, but relays
everything to the outgoing SMTP proxy.
On the MX, there is no need to check for recipient validity as we are
the final destination; but unsure that the RCPT TO address is a valid
recipient before doing the greylisting.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Quoting postconf(5):
smtpd_reject_unlisted_recipient (default: yes)
Request that the Postfix SMTP server rejects mail for unknown recipient
addresses, even when no explicit reject_unlisted_recipient access
restriction is specified. This prevents the Postfix queue from filling
up with undeliverable MAILER-DAEMON messages.
An address is always considered "known" when it matches a virtual(5)
alias or a canonical(5) mapping.
[…]
* The recipient domain matches $virtual_alias_domains but the recipient
is not listed in $virtual_alias_maps.
* The recipient domain matches $virtual_mailbox_domains but the
recipient is not listed in $virtual_mailbox_maps, and
$virtual_mailbox_maps is not null.
Since we alias everything under special, "invalid", domains (mda.f.o and
mailman.f.o), our $virtual_mailbox_maps was null, which led to
reject_unlisted_recipient not being triggered for say, "noone@fripost.org".
However, replacing $virtual_mailbox_domains with $virtual_alias_domains fits
into the second point above.
|
| |
|
|
|
| |
We can therefore spare some lookups on the MDA, and use static:all
instead.
|
| | |
|
| |
|
|
|
| |
For some reason giraff doesn't like IPSec. App-level TLS sessions are
less efficient, but thanks to ansible it still scales well.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Which might be caused by slow LDAP lookups in transport_maps. Instead,
we alias each addresses for which we want a custom transport to a
dedicated "dummy" domain, and use a static (CDB) transport_maps to map
said domains to their transport; the receiver can then use canonical(8)
to restore the original envelope recipient. Since the alias resolution
is performed by cleanup(8), which can run in parallel with other
instances, it should decongestion bottlenecks under heavy loads.
So far only the MX:es have been decongestioned. The list manager and
the MDA should be treated as well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
It has to be performed last, to give a chance to be accepted as a
regular mailbox.
We introduce a new, dedicated, smtpd daemon whose only purpose is to
resolve catch-alls.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
|
|
Other abreviations are upper case.
|
