On Tue, May 11, 2021 at 08:21:50PM -0400, post...@ptld.com wrote:
> It is my understanding if you publish DANE and TLSA records not only
> must you be using DNSSEC (Which most big companies don't) but then your
> mail server will not accept mail from anyone not using TLS 1.2+.
This is wrong.
* post...@ptld.com:
> It is my understanding if you publish DANE and TLSA records not only
> must you be using DNSSEC (Which most big companies don't) but then
> your mail server will not accept mail from anyone not using TLS 1.2+.
DNSSEC only ensures that DNS responses can be verified against ke
Viktor's announcement reminds me,
It is my understanding if you publish DANE and TLSA records not only
must you be using DNSSEC (Which most big companies don't) but then your
mail server will not accept mail from anyone not using TLS 1.2+. Why
would you want to do that and block receiving some
The announcement from Microsoft:
https://techcommunity.microsoft.com/t5/exchange-team-blog/understanding-email-scenarios-if-tls-versions-cannot-be-agreed/ba-p/2065089
This shouldn't affect most Postfix users, but if you've accidentally
disabled TLS 1.2 and higher (either inbound or outbound),
Hello
Mail_version = 3.4.14
postconf: warning: /etc/postfix/main.cf: unused parameter: smtpd_policy_maps
= socketmap:inet:127.0.0.1:8461:postfix
postconf: warning: /etc/postfix/main.cf: unused parameter: smtp_policy_maps
= socketmap:inet:127.0.0.1:8461:postfix
smtpd_policy_maps - Obs
post...@ptld.com:
> I read the NFS_README.html, and i could not find any other postfix page
> talking about NFS.
> Are there any other write ups on best practices for using postfix with
> only the maildir location over NFS?
>
> Many of the random blogs online give advice for older versions NFS2
I read the NFS_README.html, and i could not find any other postfix page
talking about NFS.
Are there any other write ups on best practices for using postfix with
only the maildir location over NFS?
Many of the random blogs online give advice for older versions NFS2 and
3 which rely on RPC.
Are
Was it smtp_tls_policy_maps perhaps?
--
Rick King
- On May 11, 2021, at 12:09 PM, Noel Jones njo...@megan.vbhcs.org wrote:
On 5/11/2021 12:28 PM, Maurizio Caloro wrote:
> Hello
>
> Mail_version = 3.4.14
>
> postconf: warning: /etc/postfix/main.cf: unused parameter:
> smtpd_policy_map
On 5/11/2021 12:28 PM, Maurizio Caloro wrote:
Hello
Mail_version = 3.4.14
postconf: warning: /etc/postfix/main.cf: unused parameter:
smtpd_policy_maps = socketmap:inet:127.0.0.1:8461:postfix
postconf: warning: /etc/postfix/main.cf: unused parameter:
smtp_policy_maps = socketmap:inet:127.0
On Tue, May 11, 2021 at 07:38:18PM +0300, IL Ka wrote:
> If no, then you should use SASL to auth the client.
> Be sure to force TLS ( smtpd_tls_auth_only) in this case.
> You can also enable client certificate verification (see TLS_README) to
> make the system even more secure.
> Also, use "smtpd_s
On 11.05.21 10:55, Bryan K. Walton wrote:
I apologize. I messed up the subject line on my first email.
no problem dude.
On Tue, May 11, 2021 at 10:52:07AM -0500, Bryan K. Walton wrote:
We have two Postfix servers. Currently, none of them allow relaying.
We accept incoming email only from a
>
>
> Is there any security benefits to creating this smart host as a separate
> SMTP server? Are there any "best practices" for this kind of situation?
>
It depends on your network structure and how much do you trust your new
clients.
If your client resides directly at your local network (eithe
I apologize. I messed up the subject line on my first email.
On Tue, May 11, 2021 at 10:52:07AM -0500, Bryan K. Walton wrote:
> We have two Postfix servers. Currently, none of them allow relaying.
> We accept incoming email only from authenticated users and from
> mail servers sending mail to an
We have two Postfix servers. Currently, none of them allow relaying.
We accept incoming email only from authenticated users and from
mail servers sending mail to any domain where we are the final
destination.
We are considering setting up an SMTP smart host server for a few
entities that would be
I found the issue.
Apparently there where two saslauthd related files in /etc/default.
/etc/default/saslauthd and /etc/default/saslauthd-postfix
I am not sure how it got there, but most likely by the previous person
working on it.
However, changing the following:
OPTIONS="-c -m /var/run/saslau
15 matches
Mail list logo
