| Commit message (Collapse) | Author | Age | Files |
|---|
| |
|
|
|
|
|
|
| |
On the infrastructure boundary. We don't reject/quarantine as it would
affect members who forward their mail sent to <user@example.com> to
<user@fripost.org>. Members can install Sieve rules to send any
messages with failed Authentication-Results headers directly in their
spambox.
|
| |
|
|
|
|
| |
Unlike what we wrote in 2014 (cf. 4fb4be4d279dd94cab33fc778cfa318b93d6926f)
the postscreen(8) server can run chrooted, meaning we can also chroot
the smtpd(8), tlsproxy(8), dnsblog(8) and cleanup(8) daemons.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Cf. lmdb_table(5).
|
| | |
|
| | |
|
| |
|
|
|
| |
So being listed on that BL doesn't yield a flat reject if the IP isn't
also listed to other lists.
|
| |
|
|
|
|
|
|
|
|
|
| |
These addresses need to be accepted on the MX:es, as recipients
sometimes phone back during the SMTP session to check whether the sender
exists.
Since a time-dependent suffix is added to the local part (cf.
http://www.postfix.org/postconf.5.html#address_verify_sender_ttl) it's
not enough to drop incoming mails to ‘double-bounce@fripost.org’, and
it's impractical to do the same for /^double-bounce.*@fripost\.org$/.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
certificate.
See postconf(5). This avoids the “(Client did not present a
certificate)” messages in the Received headers.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
To avoid new commits upon cert renewal.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
locally.
And use this to fetch all X.509 leaf certificates.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
|
| |
Interhost communications are protected by stunnel4. The graphs are only
visible on the master itself, and content is generated by Fast CGI.
|
| |
|
|
|
| |
‘noreply@’ aliases can be added by routing them to
‘@discard.fripost.org’.
|
| |
|
|
|
|
| |
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.
|
