On 11.01.22 15:46, Bill Cole wrote:
On 2022-01-10 at 19:15:46 UTC-0500 (Mon, 10 Jan 2022 19:15:46 -0500)
Alex
is rumored to have said:
[...]
Here are my current settings:
# postconf -n -c /etc/postfix-117|grep -E 'tls|cipher'
smtp_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtp_tls
Dnia 11.01.2022 o godz. 11:33:12 Bill Cole pisze:
>
> It's mildly amusing that THIS THREAD is an example of one risk of
> not simply trusting Wietse & Viktor (with broad community oversight)
> to get the TLS defaults right.
That's exactly what I wanted to say. Just let's trust Postfix authors tha
On 2022-01-11 at 10:16:20 UTC-0500 (Tue, 11 Jan 2022 16:16:20 +0100)
Charlotte 🦝 Delenk
is rumored to have said:
On 11.01.22 15:46, Bill Cole wrote:
On 2022-01-10 at 19:15:46 UTC-0500 (Mon, 10 Jan 2022 19:15:46 -0500)
Alex
is rumored to have said:
[...]
Here are my current settings:
# postco
Charlotte ? Delenk wrote:-
>We are talking about systems that should not be running in prod anymore,
>but still are due to inertia. Mails not being delivered may hopefully be
>the push that kickstarts upgrading efforts.
But it is not that the email fails delivery, rather it is transmitted
unen
On 2022-01-10 at 19:15:46 UTC-0500 (Mon, 10 Jan 2022 19:15:46 -0500)
Alex
is rumored to have said:
[...]
Here are my current settings:
# postconf -n -c /etc/postfix-117|grep -E 'tls|cipher'
smtp_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtp_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TL
On Mon, Jan 10, 2022 at 07:15:46PM -0500, Alex wrote:
> > The vulnerabilities I am aware of that justify sticking to v1.2/3 in
> > web, IMAP, and database servers are not viable against SMTP because of
> > the brief, non-repetitive, and largely unpredictable nature of the TLS
> > sessions used by
Hi,
> > I have a postfix-3.5.10 system and having a little trouble configuring
> > it to ensure I'm not including any vulnerable ciphers. I had
> > previously posted about this issue in September, and thought I
> > followed the instructions I was given, but a recent security scan
> > (onsecurity)
for those following along, I find this a useful, summary reference
Hands-on: implementing DANE in PostfixCryptographic security for mail transport
https://www.sidn.nl/en/news-and-blogs/hands-on-implementing-dane-in-postfix
On Mon, Jan 10, 2022 at 11:17:12AM -0500, Alex wrote:
>
> NULL ciphers (no encryption) not offered (OK)
> Anonymous NULL Ciphers (no authentication)offered (NOT ok)
In addition to the text in TLS_README, see:
https://datatracker.ietf.org/doc/html/rfc7672#section
On 2022-01-10 at 11:08:49 UTC-0500 (Mon, 10 Jan 2022 11:08:49 -0500)
Alex
is rumored to have said:
Hi,
I have a postfix-3.5.10 system and having a little trouble configuring
it to ensure I'm not including any vulnerable ciphers. I had
previously posted about this issue in September, and though
This question is answered regularly on this list.
http://www.postfix.org/TLS_README.html#server_cipher
> By default anonymous ciphers are enabled. … One can't force a remote
> SMTP client to check the server certificate, so excluding anonymous
> ciphers is generally unnecessary.
Hi, here is some follow-up info I received that provides more details
on what the vulnerability scan is reporting:
Testing cipher categories
NULL ciphers (no encryption) not offered (OK)
Anonymous NULL Ciphers (no authentication)offered (NOT ok)
Export ciphers (w/o A
Hi,
I have a postfix-3.5.10 system and having a little trouble configuring
it to ensure I'm not including any vulnerable ciphers. I had
previously posted about this issue in September, and thought I
followed the instructions I was given, but a recent security scan
(onsecurity) shows port 25 is sti
Viktor Dukhovni writes:
>> On Dec 6, 2017, at 1:41 PM, micah wrote:
>>
main.cf
smtpd_tls_security_level = may
>>
>> Is there a reason why 'smtpd_tls_security_level = may' is not default in
>> postfix? What needs to be done to make it default? It seems harmless to
>> have that enabled
> On Dec 6, 2017, at 1:41 PM, micah wrote:
>
>>> main.cf
>>> smtpd_tls_security_level = may
>
> Is there a reason why 'smtpd_tls_security_level = may' is not default in
> postfix? What needs to be done to make it default? It seems harmless to
> have that enabled by default, with no negative ef
Viktor Dukhovni writes:
>> On Dec 6, 2017, at 10:21 AM, li...@mbchandler.net wrote:
>>
>> main.cf
>> smtpd_tls_security_level = may
Is there a reason why 'smtpd_tls_security_level = may' is not default in
postfix? What needs to be done to make it default? It seems harmless to
have that enabled
> On Dec 6, 2017, at 10:21 AM, li...@mbchandler.net wrote:
>
> main.cf
> smtpd_tls_security_level = may
>
> smtpd_sender_restrictions =
> check_client_access cidr:/etc/postfix/enforced_inbound_tls.cidr
>
> enforced_inbound_tls.cidr
> 10.0.0.0/8 reject_plaintext_session
>
> My questi
I'm enforcing inbound TLS from my internal network with these settings:
main.cf
smtpd_tls_security_level = may
smtpd_sender_restrictions =
check_client_access cidr:/etc/postfix/enforced_inbound_tls.cidr
enforced_inbound_tls.cidr
10.0.0.0/8 reject_plaintext_session
My question is,
Hi Viktor,
On Saturday, 02 Aug 2014 15:32 +, Viktor Dukhovni wrote:
> > I've noticed, that my Postfix installation does select in some
> > caes (especially if Postfix is running on both ends)
> > AECDH-AES256-SHA instead of ECDHE-RSA-AES256-GCM-SHA384. The
> > receiving Postfix does support E
On Sat, Aug 02, 2014 at 11:53:45AM +0200, Ihsan Dogan wrote:
> I've noticed, that my Postfix installation does select in some
> caes (especially if Postfix is running on both ends)
> AECDH-AES256-SHA instead of ECDHE-RSA-AES256-GCM-SHA384. The
> receiving Postfix does support ECDHE-RSA-AES256-GCM-
Hi,
I've noticed, that my Postfix installation does select in some
caes (especially if Postfix is running on both ends)
AECDH-AES256-SHA instead of ECDHE-RSA-AES256-GCM-SHA384. The
receiving Postfix does support ECDHE-RSA-AES256-GCM-SHA384 and
connections with that cipher are possible.
But if Pos
21 matches
Mail list logo
