| Age | Commit message (Collapse) | Author |
|---|
|
The onlyif check was incorrectly specified in the original implementation in
commit id: 15b83d88dcedab496a19cef57f11c5c8e091dd4a this inverts it so it
is properly detected.
Change-Id: I531e206fff1ca61780adcd195e1f917011e50fb4
|
|
The unix socket method for connecting to the milter was incorrectly
reverted, this puts it back to how it should be.
Change-Id: Ifde669c920a249c782f577a112f4d45e60a889a2
|
|
- ignore puppet lint error about inheriting from different namespace
|
|
In order for postfix to access the opendkim milter socket, we need to
remove the chroot option for the cleanup service.
See e97a9d3800b173375a630e18e4b1aa0894eb96e1 for opendkim
implementation.
Change-Id: I2742650965e61273fb804ebe9ce3f9bd38796582
|
|
|
|
Change-Id: I328aa37b393817e1764ea7e635fcefc801adbbf4
|
|
Change-Id: I9c8f9c9c3ee7cd89f013cbb08397377522ed5a4a
|
|
Conflicts:
puppet/modules/site_postfix/manifests/mx.pp
|
|
replacement wasn't being done. (#7890)
This moves that replacement into its own class, clears the old value and
sets it properly in the smtps transport.
Change-Id: I27c02730597df4943761d8bcb61014aeded9dc75
|
|
|
|
smtpd_relay_restrictions was added in postfix 2.10 (jessie
has 2.11 atm). Without this, outbound mails are rejected to
be relayed.
from http://www.postfix.org/SMTPD_ACCESS_README.html:
NOTE: Postfix versions before 2.10 did not have
smtpd_relay_restrictions. They combined the mail relay and spam blocking
policies, under smtpd_recipient_restrictions. This could lead to
unexpected results. For example, a permissive spam blocking policy could
unexpectedly result in a permissive mail relay policy. An example of
this is documented under "Dangerous use of
smtpd_recipient_restrictions".
smtpd_relay_restrictions defaults to
'permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination'
and is configured here to check for a valid client cert.
see http://www.postfix.org/postconf.5.html#smtpd_relay_restrictions
- Resolves: #7856
|
|
ensuring the satellite hosts are setup properly (#7611)
Change-Id: I9dce57c305a6fd6a39596a941174fe1879af5e4f
|
|
without getting blocked by the rbl (#7819)
Change-Id: Ib7a00f810b6c49528e5f99a1d83296553a81e65e
|
|
debconf selections, are set correctly (#7478)
Change-Id: I3bd261fd6fe27bbf10b8994ffff9f8b7be5b9de0
|
|
to relay mail through us (#3634)
Change-Id: I46cf3ffbef4261839c376f4c36a50d9c44eb1374
|
|
This change will make sure that the user/group for leap-mx exist, and it
changes the mail location from /var/mail/vmail to the more helpful name
/var/mail/leap-mx.
This change requires:
https://github.com/leapcode/leap_mx/pull/78
and it would replace merge request:
https://github.com/leapcode/leap_mx/pull/65
and fix https://leap.se/code/issues/6936 and
https://leap.se/code/issues/7635
Change-Id: Idbe678dc999e394232c2eeef2b2018d39ab7cc3b
|
|
When mail comes in to the system, a lookup is done to see if it is a
valid leap user, if it is, leap_mx now returns something of the form:
uuid@deliver.local (see #5959). The virtual_mailbox_domains lists
deliver.local, so postfix choses to deliver to
virtual_mailbox_base (/var/mail/vmail) which has been hardcoded to the
'vmail' maildir and user.
We want leap related mail and leap aliases to go through the virtual
alias system, all the hard-coded universal aliases we want to go through
the local system and we dont want these separate. Known domains that are
considered 'virtual' will be forwarded or delivered to the vmail user,
the rest rejected as unknown recipient, instead of being handed off to
leap-mx.
Previously, the way this was done is we leaned (too heavily) on the
'luser_relay' postfix configuration which sent anything that wasn't
locally configured right to the leap_mx spool. That meant everything
went there, including addresses that didn't exist, and leap-mx would
then have to process those and bounce them. This removes the
'luser_relay' option, so any address that doesn't resolve properly to
either a local address/alias, or a leap address or alias (through
tcp lookups on 2424 and 4242) will get bounced as an unknown user.
Change-Id: I3c22e9383861b3794dd9adfd7aa6a0cf0a773a18
|
|
Change-Id: I6a6e68908b71d7499eb3ef3c7f0173b3d5b7baa2
|
|
issue #5924
Change-Id: I6aa1e7751633407d441cbc6436d8426d37dbbfa7
|
|
whitelisting (#3625)
Change-Id: I15985ca00ee95bc62855f098a78e364ebbc32616
|
|
|
|
Change-Id: I42a1ef661dc55fb8110e82e930f67679c3dff1f8
|
|
Change-Id: If92faee5f877301bf23564d5b6e71c4b1263de54
|
|
|
|
|
|
Change-Id: Ib701886ad26c5e39ccd669fadca81404b5c0426a
|
|
Valid users submitting mail to be delivered should not be blocked by
configured RBLs.
Settings in main.cf are valid and used globally, unless they are
overridden in master.cf for specific Postfix daemons. We have set in
main.cf the smtp_client_restrictions parameter to check for configured
rbls, so we need to override that and empty it in order to allow valid
clients to send mail, even when their IP is listed in an RBL.
Note: most users will typically be connecting via VPN, so their IP would
typically be replaced by the VPN gateway one, but there are cases where
this is still useful.
Change-Id: Ie4171113c78ae2814402a1ed9b5343280cbf79d1
|
|
The openpgp header added by the client is sometimes incorrect, because
the client doesn't actually know what the proper URL is for the
webapp. The server knows, however.
Change-Id: I2243b19a6337d8e0be97590e2ca9c9c0b0fffdac
|
|
|
|
Set zen.spamhaus as the default rbl
Change-Id: Ic3537d645c80ba42267bab370a1cf77730382158
|
|
/ect/aliases #6829
We began to recieve spam for vmail@DOMAIN. So we want to block
inbound mail to local system users. However, users in the /etc/aliases
file are still accepted on inbound mail - see
https://leap.se/code/issues/6909 for a follow up.
Change-Id: I03d3014984c4bd27f90147125fb037b68716624d
|
|
Change-Id: I029ffabd33299a5b42e5f262e372eafb6272d094
|
|
Change-Id: Idf550ed004bcb42d6e19ac0a2c5286f52a390935
|
|
smtp_tls_security_level of 'encrypt', so it is not optional (#1902)
Change-Id: I61ad0823e3eb8df6c224767d63f0911dcba42a16
|
|
because the DNS lookup is either impossible (.local domain), or
incorrect (certain openstack/amazon/piston cloud configurations create
this setup when the relayhost is in the same cluster as the satellite).
Fixes #5225
Change-Id: Ifbc201678f2c0e97ee0e12bbf1c7f71d035d45c1
|
|
the mynetworks parameter. Previously we only allowed other mx servers to
relay to each other, but this prevents system mail from non-mx nodes
from getting out.
Fixes "Helo command rejected: You are not in domain bitmask.net (in reply to RCPT TO command))" (#5343)
Change-Id: I5e204958cb235808eedc3a1724fb2dc6c7a5b73b
|
|
|
|
Helo as the domain (#4495)
Change-Id: I6c8ac28faceb8b0c6129a606ede04837efd3d261
|
|
Change-Id: I959fa40ff508bbeaf7baa0b6ba90c10c9e6b0ef7
|
|
Change-Id: I779ea60e6d726d042203fa0756d73b4af079d728
|
|
class for smtp vs. smtpd tls configurations
Change-Id: Ic1cc560c76924fcbbc15e245bec7b78ac2de83d3
|
|
wrapper mode on the smtps port 465 now (#4366)
enable the missing smtpd_helo_restrictions for smtps
Change-Id: Iac497369d65c5ad8fd7e93e6fcabb830b855b4f6
|
|
Change-Id: I4ffb5b9203741d1152dfd93ef9ecc45f6a6088d4
|
|
Change-Id: I547b99becb8b16fec0ac89f06fb6d833cbde3c2b
|
|
|
|
|
|
|
|
|
|
|
|
implementing RFC2142 and more (#3602)
Change-Id: Ic2765b25ff9e1560def4900a1bf38dc8023b0ffa
|
