ught calling Mr. Gates
for support, even if I paid him.
Marius.
-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of
grantksupp...@operamail.com
Sent: Sunday, June 22, 2014 12:03 AM
To: postfix-users@postfix.org
Subject: Re: Oppo
grantksupp...@operamail.com:
> Viktor,
>
> > Your server is fine. Google is using RC4 outbound, and it is their
> > responsibility to improve that, not yours.
>
> Thanks, for the pointers. That's cleared up & understood now.
>
> On Sat, Jun 21, 2014, at 01:35 PM, Wietse Venema wrote:
> > Inste
Viktor,
> Your server is fine. Google is using RC4 outbound, and it is their
> responsibility to improve that, not yours.
Thanks, for the pointers. That's cleared up & understood now.
On Sat, Jun 21, 2014, at 01:35 PM, Wietse Venema wrote:
> Instead of tinkering with carefully-chosen Postfix d
grantksupp...@operamail.com:
>
>
> On Sat, Jun 21, 2014, at 11:41 AM, Viktor Dukhovni wrote:
> > I repeat, these aren't the droids you're looking for.
>
> ok, no longer looking for those droids.
>
> returning to why I started looking for them in the 1st place, trying to
> understand/control the
On Sat, Jun 21, 2014 at 01:13:35PM -0700, grantksupp...@operamail.com wrote:
> looking at headers of mail sent FROM my my postfix server TO my gmail
> account
>
> Received: from mx.grantkX.com (mx.grantkX.com.
> [##.##.##.##])
> by mx.google.com with ESMTPS id
>
On Sat, Jun 21, 2014, at 11:41 AM, Viktor Dukhovni wrote:
> I repeat, these aren't the droids you're looking for.
ok, no longer looking for those droids.
returning to why I started looking for them in the 1st place, trying to
understand/control the strength of encryption to/from my server, maki
On Sat, Jun 21, 2014 at 10:49:17AM -0700, grantksupp...@operamail.com wrote:
> > See also:
> >
> > http://www.postfix.org/FORWARD_SECRECY_README.html
>
> Right. That's one of the specific documents I'd already referenced as
> having read in my OP. It's thorough, and to me, confusing. Whic
hi
On Sat, Jun 21, 2014, at 10:36 AM, Viktor Dukhovni wrote:
> The *default* Postfix TLS cipherlist settings are chosen with care.
> Best pracice is to leave them as-is.
>
> See also:
>
> http://www.postfix.org/FORWARD_SECRECY_README.html
Right. That's one of the specific documents I'd alr
On Sat, Jun 21, 2014 at 10:26:41AM -0700, grantksupp...@operamail.com wrote:
> I think I see the variety of options, and understand some of the
> pitfalls, as discussed, but TBH am a bit lost as to what the 'best
> practices' *recommendation* for the cipher list to use is? specifically
> for a PFS
On Sat, Jun 21, 2014, at 10:07 AM, Viktor Dukhovni wrote:
> > During a security audit, it was determined that the MX supported what
> > the auditors called "weak" ciphers and protocols (SSLv3, TLSv1.0,
> > RC4-MD5, anonymous ciphers and so on). The auditors demanded that we
> > disable all those -
On Sat, Jun 21, 2014 at 01:11:04PM +0200, Stefan Foerster wrote:
> During a security audit, it was determined that the MX supported what
> the auditors called "weak" ciphers and protocols (SSLv3, TLSv1.0,
> RC4-MD5, anonymous ciphers and so on). The auditors demanded that we
> disable all those -
> On 06/21/2014 01:11 PM, Stefan Foerster wrote:
>
> our current situation is as follows:
>
> 1. Public MX, very low incoming volume, "smtpd_tls_security_level = may"
> 2. Senders aren't known beforehand, i.e. no previous business relationship.
> 3. Senders' IT usually doesn't support DANE.
> 4. I
On Sat, Jun 21, 2014 at 12:45 PM, Stefan Foerster
wrote:
> While I certainly share your view on this - though I would have worded
> it less strongly - my question still stands: Does anyone have real world
> data to share (e.g. "we disabled ciphers X, Y and Z and then N percent
> of clients failed
On Sat, Jun 21, 2014 at 12:21 PM, li...@rhsoft.net wrote:
>
>
> Am 21.06.2014 13:11, schrieb Stefan Foerster:
>> our current situation is as follows:
>>
>> 1. Public MX, very low incoming volume, "smtpd_tls_security_level = may"
>> 2. Senders aren't known beforehand, i.e. no previous business rela
* "li...@rhsoft.net" :
> Am 21.06.2014 13:11, schrieb Stefan Foerster:
> > Could someone share experience with or point me to some kind of "best
> > practices" regarding opportunistic TLS, or explain the reasoning for
> > banning "weak" ciphers/protocols on a public MX? (again, not talking
> > abou
Am 21.06.2014 13:11, schrieb Stefan Foerster:
> our current situation is as follows:
>
> 1. Public MX, very low incoming volume, "smtpd_tls_security_level = may"
> 2. Senders aren't known beforehand, i.e. no previous business relationship.
> 3. Senders' IT usually doesn't support DANE.
> 4. Inco
16 matches
Mail list logo
