micah anderson:
> Wietse Venema writes:
>
> > micah anderson:
> >> Eray Aslan writes:
> >>
> >> > On Wed, Dec 19, 2018 at 02:36:50PM -0500, Viktor Dukhovni wrote:
> >> >> If there are no objections, I can change the default to "may" when
> >> >> TLS is compiled in.
> >> >
> >> > No objections f
Wietse Venema writes:
> micah anderson:
>> Eray Aslan writes:
>>
>> > On Wed, Dec 19, 2018 at 02:36:50PM -0500, Viktor Dukhovni wrote:
>> >> If there are no objections, I can change the default to "may" when
>> >> TLS is compiled in.
>> >
>> > No objections for setting smtp_tls_security_level.
micah anderson:
> Eray Aslan writes:
>
> > On Wed, Dec 19, 2018 at 02:36:50PM -0500, Viktor Dukhovni wrote:
> >> If there are no objections, I can change the default to "may" when
> >> TLS is compiled in.
> >
> > No objections for setting smtp_tls_security_level. Thanks for your
> > effort.
>
>
Eray Aslan writes:
> On Wed, Dec 19, 2018 at 02:36:50PM -0500, Viktor Dukhovni wrote:
>> If there are no objections, I can change the default to "may" when
>> TLS is compiled in.
>
> No objections for setting smtp_tls_security_level. Thanks for your
> effort.
I just wanted to circle back to thi
On 19 Dec 2018, at 14:36, Viktor Dukhovni wrote:
If there are no objections, I can change the default to "may" when
TLS is compiled in.
But how else will Postfix troubleshooters make themselves look like
geniuses with 10 seconds of "work?"
(Not An Actual Objection... I wholeheartedly applau
r since the
>> original.
> I did not see a clear consensus for or against a compile-time
> conditional default "may" for "smtp_tls_security_level":
> #ifdef USE_TLS
> #define DEF_SMTP_TLS_LEVEL "may"
> #else
> #define DEF_SMTP_TLS_
On Wed, Dec 19, 2018 at 02:36:50PM -0500, Viktor Dukhovni wrote:
> If there are no objections, I can change the default to "may" when
> TLS is compiled in.
No objections for setting smtp_tls_security_level. Thanks for your
effort.
--
Eray
micah anderson:
> What happens now when someone builds without TLS support and then
> enables some TLS option? It seems like the same thing should happen
> here.
I don't care what happens now. I want to avoid sending plaintext
mail when Postfix is configured to require TLS, and someone forgets
to
support, and Postfix configuration a)
> enables opportunistic TLS or b) Postfix configuration requires TLS?
Perhaps we should honour the configured (main.cf or per-destination)
security level, and thus, with TLS support not compiled in:
* A main.cf security level > "none" generates
itly.
>> > >
>> > > Or, whether there are Postfix package maintainers in the same boat:
>> > > too busy to add code to enable opportunistic TLS in the client at
>> > > package install time, but would be happy to see it happen upstream.
>> >
>&
y_level" setting in their main.cf
>> > file.
>> >
>> > * Would not mind to see TLS turned on as a side-effect of a future
>> > upgrade, but can't find the activation energy to do it explicitly.
>> >
>> > Or, whether there are Postfix package ma
_level" setting in their main.cf
> > > file.
> > >
> > > * Would not mind to see TLS turned on as a side-effect of a future
> > > upgrade, but can't find the activation energy to do it explicitly.
> > >
> > > Or, whether there are Postfi
fix, but rather the content of the initial
"main.cf" file when the package is first installed. A package can
not only enable outbound opportunistic TLS, but perhaps also (given
sufficient understanding of the platform) enable DANE when there's
a validating local resolver, and generate
> > * Would not mind to see TLS turned on as a side-effect of a future
> > upgrade, but can't find the activation energy to do it explicitly.
> >
> > Or, whether there are Postfix package maintainers in the same boat:
> > too busy to add code to enable oppor
ity_level":
>
> #ifdef USE_TLS
> #define DEF_SMTP_TLS_LEVEL "may"
> #else
> #define DEF_SMTP_TLS_LEVEL ""
> #endif
>
> which would default to enable outbound opportunistic TLS whever TLS
> support is compiled in. Since this last came up
e the
> original.
I did not see a clear consensus for or against a compile-time
conditional default "may" for "smtp_tls_security_level":
#ifdef USE_TLS
#define DEF_SMTP_TLS_LEVEL "may"
#else
#define DEF_SMTP_TLS_LEVEL ""
#endif
which woul
micah writes:
> Viktor Dukhovni writes:
>
>>> On Dec 6, 2017, at 8:08 PM, micah wrote:
>>>
>>> Is there any reason why postfix, when compiled with TLS, can simply set
>>> the default to 'may'?
>>
>> This is easy enough to implement, the only complication is
>> that the documentation would need
Viktor Dukhovni:
>
>
> > On May 31, 2018, at 8:04 AM, Dirk St?cker wrote:
> >
> > Even after years of UNIX experience there are commands and syntaxes I've
> > newer seen before. That <(...) is surely helpful elsewhere, when I can
> > remember it...
>
> It is of course a "bashism" and not a P
> On May 31, 2018, at 8:04 AM, Dirk Stöcker wrote:
>
> Even after years of UNIX experience there are commands and syntaxes I've
> newer seen before. That <(...) is surely helpful elsewhere, when I can
> remember it...
It is of course a "bashism" and not a POSIX-shell feature, so you
won't f
On Tue, 29 May 2018, Wietse Venema wrote:
This is a task which I need something to change a vendor supplied main.cf
into the better understandable minimum configuration which does not
contain legacy settings.
Could "postconf" get a new "-N" paramater for that maybe ;-)
My Postfix cycles are c
@lbutlr:
> I do have one question that I've never noticed before. The settings for =
> mydomain and myhostname show that they are at the default values. Where =
> is postfix getting the defaults for this and does it mean the settings =
> really aren't needed unless your hostname is, for some reason
On Tue, 2018-05-29 at 13:57 -0400, Viktor Dukhovni wrote:
> > On May 29, 2018, at 1:54 PM, Jim P. wrote:
> >
> > It's more of a language "feature". This works:
> >
> > LANG=C comm -1 -2 <(postconf -n) <(postconf -d)
> >
> > this doesn't:
> >
> > LANG=en_US comm -1 -2 <(postconf -n) <(postconf
On 29 May 2018, at 11:57, Viktor Dukhovni wrote:
> The collation rules for "en_US" are abominable. I always set:
>
> LC_CTYPE=en_US.UTF-8 LANG=C
Yep, strongly agree with this. I foolishly had LANG=en_US some time back
thinking it was sensible. It is not. Everything breaks.
> On May 29, 2018, at 1:54 PM, Jim P. wrote:
>
> It's more of a language "feature". This works:
>
> LANG=C comm -1 -2 <(postconf -n) <(postconf -d)
>
> this doesn't:
>
> LANG=en_US comm -1 -2 <(postconf -n) <(postconf -d)
The collation rules for "en_US" are abominable. I always set:
L
On Tue, 2018-05-29 at 13:32 -0400, Viktor Dukhovni wrote:
> > On May 29, 2018, at 12:28 PM, Jim P. wrote:
> >
> > FWIW, I had to use this:
> >
> > comm -1 -2 <(postconf -n|sort) <(postconf -d|sort)
>
> That'd only be needed if you have a funny collation locale.
> Try:
>
> env -i "PATH=$PA
> On May 29, 2018, at 12:28 PM, Jim P. wrote:
>
> FWIW, I had to use this:
>
> comm -1 -2 <(postconf -n|sort) <(postconf -d|sort)
That'd only be needed if you have a funny collation locale.
Try:
env -i "PATH=$PATH" LANG=C LC_COLLATE=C bash -c '
comm -1 -2 <(postconf -n) <(post
On Tue, 2018-05-29 at 10:49 +0200, Stefan Förster wrote:
> * Dirk Stöcker :
> > On Mon, 28 May 2018, Viktor Dukhovni wrote:
> >
> > > > It might be useful, but probably not, to have a version of
> > > > postconf -n that showed the default value along sinde the
> > > > changed value:
> > >
> > > j
On 2018-05-29 (02:35 MDT), Dirk Stöcker wrote:
>
> Do you maybe also have a command to show only changed parameters?
This is doable, but it takes a bit more processing than a single line.
Basically, a shell script that parses the output of
join <(postconf -n) <(postconf -d | sed 's/=/(default
Dirk St?cker:
> On Mon, 28 May 2018, Viktor Dukhovni wrote:
>
> >> It might be useful, but probably not, to have a version of postconf -n
> >> that showed the default value along sinde the changed value:
> >
> > join <(postconf -n) <(postconf -d | sed 's/=/(default:/; s/$/)/')
>
> Do you maybe a
* Dirk Stöcker :
On Mon, 28 May 2018, Viktor Dukhovni wrote:
It might be useful, but probably not, to have a version of postconf -n that
showed the default value along sinde the changed value:
join <(postconf -n) <(postconf -d | sed 's/=/(default:/; s/$/)/')
Do you maybe also have a comman
On Mon, 28 May 2018, Viktor Dukhovni wrote:
It might be useful, but probably not, to have a version of postconf -n that
showed the default value along sinde the changed value:
join <(postconf -n) <(postconf -d | sed 's/=/(default:/; s/$/)/')
Do you maybe also have a command to show only cha
On 2018-05-28 (11:26 MDT), Viktor Dukhovni wrote:
>
> join <(postconf -n) <(postconf -d | sed 's/=/(default:/; s/$/)/')
That's nifty!
--
"you'd think you could trust a horde of hungarian barbarians"
> On May 28, 2018, at 1:26 PM, Viktor Dukhovni
> wrote:
>
> join <(postconf -n) <(postconf -d | sed 's/=/(default:/; s/$/)/')
I should mention that this is "bash" syntax. Other shells require
temp files. On at least some FreeBSD systems bash by default does
not assume the existence of /dev
> On May 28, 2018, at 11:35 AM, @lbutlr wrote:
>
> It might be useful, but probably not, to have a version of postconf -n that
> showed the default value along sinde the changed value:
join <(postconf -n) <(postconf -d | sed 's/=/(default:/; s/$/)/')
--
Viktor.
On 26 May 2018, at 12:59, Benny Pedersen wrote:
> just kidding, i would like to see main.cf smaller, so postconf -n gives more
> settings as default from -d
>
> as it is now setting is more or less random default from main.cf
>
> keep main.cf minimal is good sense
I’m not sure what you mean, t
/dev/rob0 skrev den 2018-05-26 18:59:
Just a thought. This particular misunderstanding is pretty common.
Of course "instead of actual settings" should be a clue. It might
help if the OP tells us what he was thinking when reading that
passage about "-d". Reading too fast?
postconf -d output
On Sat, May 26, 2018 at 12:56 PM, Viktor Dukhovni <
postfix-us...@dukhovni.org> wrote:
>
>
> > On May 26, 2018, at 8:30 AM, Sean Son
> wrote:
> >
> > Also, if I set smtpd_tls_ciphers" and/or "smtp_tls_ciphers" to "high" ,
> won'
On 2018-05-26 (10:59 MDT), /dev/rob0 wrote:
> Perhaps this could be reworded to be less confusing? Since "-d"
> doesn't look at main.cf, s/main.cf/"Postfix internal"/?
I dunno, I think "Print main.cf default parameter settings instead of actual
settings." is very clear.
--
We will fight for
On Sat, May 26, 2018 at 01:11:00PM -0400, Viktor Dukhovni wrote:
> > On May 26, 2018, at 12:59 PM, /dev/rob0 wrote:
> >
> >> Man postconf:
> >> -d Print main.cf default parameter settings instead of
> >> actual settings. Specify -df to fold long lines
> >> fo
> On May 26, 2018, at 12:59 PM, /dev/rob0 wrote:
>
>> Man postconf:
>> -d Print main.cf default parameter settings instead of
>> actual settings. Specify -df to fold long lines
>> for human readability (Postfix 2.9 and later).
>
> Perhaps this could be rew
On Sat, May 26, 2018 at 06:51:33AM -0600, @lbutlr wrote:
> On 26 May 2018, at 06:30, Sean Son
> wrote:
> > postconf -d | egrep '^[^ ]*mtpd?_tls.*_protocols' . but it still
> > shows me the old settings
>
>
> The output of postconf -d will never change.
>
> Man postconf:
>-d Print
> On May 26, 2018, at 8:30 AM, Sean Son
> wrote:
>
> Also, if I set smtpd_tls_ciphers" and/or "smtp_tls_ciphers" to "high" , won't
> that conflict with opportunistic TLS.
Only for senders that don't support any of the modern ciphersuites
On 26 May 2018, at 06:30, Sean Son wrote:
> postconf -d | egrep '^[^ ]*mtpd?_tls.*_protocols' . but it still shows me
> the old settings
The output of postconf -d will never change.
Man postconf:
-d Print main.cf default parameter settings instead of actual set-
ti
se two issues. Any suggestions on what
> I should do to fix them with out breaking opportunistic TLS is greatly
> appreciated!
>
> Change the settings to the posted Postfix 3.0+ defaults.
> As for the medium ciphers. Set "smtpd_tls_ciphers" and/or
> "smtp_tls_ci
t; i was informed by our security team that my postfix server has SSL Version 2
> and 3 protocol detected and SSL Medium Strength Cipher suites supported. I am
> supposed to fix those two issues. Any suggestions on what I should do to
> fix them with out breaking opportunistic TLS is gr
On Mon, May 21, 2018 at 2:08 PM, Viktor Dukhovni wrote:
>
>
> > On May 21, 2018, at 1:16 PM, Sean Son
> wrote:
> >
> > Hello all
> >
> > I have opportunistic TLS (offering STARTLS) configured in my main.cf
> file. I have been tasked to disable S
> On May 21, 2018, at 1:16 PM, Sean Son
> wrote:
>
> Hello all
>
> I have opportunistic TLS (offering STARTLS) configured in my main.cf file.
> I have been tasked to disable SSLv2 and SSLv3 as well as disable medium
> strength ciphers (to use high strength one
On 21 May 2018, at 13:16 (-0400), Sean Son wrote:
Hello all
I have opportunistic TLS (offering STARTLS) configured in my main.cf
file. I have been tasked to disable SSLv2 and SSLv3 as well as
disable
medium strength ciphers (to use high strength ones instead) in my
postfix
server. If I
Hello all
I have opportunistic TLS (offering STARTLS) configured in my main.cf
file. I have been tasked to disable SSLv2 and SSLv3 as well as disable
medium strength ciphers (to use high strength ones instead) in my postfix
server. If I was to add the following to my main.cf
Viktor Dukhovni writes:
>> On Dec 6, 2017, at 8:08 PM, micah wrote:
>>
>> Is there any reason why postfix, when compiled with TLS, can simply set
>> the default to 'may'?
>
> This is easy enough to implement, the only complication is
> that the documentation would need to explain the variable
>
On Wed, Dec 06, 2017 at 05:22:19PM -0600, Noel Jones wrote:
> I was thinking "make install" rather than "make upgrade" is a good
> enough indicator of first time install. Deciding if TLS is available
> might be trickier.
Source based distros like Gentoo make install to a seperate destination
dir a
> On Dec 6, 2017, at 8:08 PM, micah wrote:
>
> Is there any reason why postfix, when compiled with TLS, can simply set
> the default to 'may'?
This is easy enough to implement, the only complication is
that the documentation would need to explain the variable
default.
> If it is compiled with
Wietse Venema writes:
> Noel Jones:
>> On 12/6/2017 1:39 PM, Viktor Dukhovni wrote:
>> >
>> > As for changing the default, I am not opposed, perhaps given the
>> > changes in the SMTP ecosystem since 2014:
>> >
>> > https://transparencyreport.google.com/safer-email/overview?encrypt_in=end:15125
On 12/6/2017 3:24 PM, Wietse Venema wrote:
>
> How would one recognize 'first-time' installation? If that helps
> only the tiny minority of sites that install Postfix from source,then
> it does not seem to be a good target. Better to get the vendors to
> run those commands instead.
>
> Wiet
Noel Jones:
> On 12/6/2017 1:39 PM, Viktor Dukhovni wrote:
> >
> > As for changing the default, I am not opposed, perhaps given the
> > changes in the SMTP ecosystem since 2014:
> >
> > https://transparencyreport.google.com/safer-email/overview?encrypt_in=end:151251840;series:inbound;start:13
On 12/6/2017 1:39 PM, Viktor Dukhovni wrote:
>
> As for changing the default, I am not opposed, perhaps given the
> changes in the SMTP ecosystem since 2014:
>
> https://transparencyreport.google.com/safer-email/overview?encrypt_in=end:151251840;series:inbound;start:138853440&lu=encrypt_i
> On Dec 6, 2017, at 2:27 PM, micah wrote:
>
> I'm sorry, I meant 'smtp_tls_security_level = may' - not
> smtpd_tls_security_level.
>
> You are correct that smtpd_tls_security_level would need a certificate,
> but 'smtp_tls_security_level' does not, and as an opportunistic mode, it
> is design
On Fri, Jun 23, 2017 at 01:48:29AM +, Nik Kostaras wrote:
> Is there any value making this check optional with the use of a
> configuration parameter, to specify the expected minimum timeout (0 to
> disable the timeout check)?
I think that a brief delay for the tiny fraction of sites that
mis
e not retransmitted immediately after opportunistic TLS
handshake failure
On Thu, Jun 22, 2017 at 06:14:08PM +, Nik Kostaras wrote:
> In one of my tests I'm configuring Postfix client (smtp) to use
> opportunistic TLS with TLSv1.2 protocol only
Don't do that. See RFC7435.
On Fri, Jun 23, 2017, Viktor Dukhovni wrote:
> Some MTAs (say Sendmail) don't downgrade to cleartext at all when
> the peer purports to support STARTTLS. Postfix gives the remote
Just FYI: in sendmail 8.16 it's an option:
To automatically handle TLS interoperability problems for outgoin
On Thu, Jun 22, 2017 at 06:14:08PM +, Nik Kostaras wrote:
> In one of my tests I'm configuring Postfix client (smtp) to use
> opportunistic TLS with TLSv1.2 protocol only
Don't do that. See RFC7435. Raising the floor on acceptable
cryptographic parameters often lowers se
Nik Kostaras:
> Jun 22 17:30:26 postfix-outbound/smtp[27125]: 3wtnBB3Jr7z1Q67T:
> to=, relay=10.44.43.1[10.44.43.1]:25, delay=0.08,
> delays=0.02/0.03/0.03/0, dsn=4.7.5, status=deferred (Cannot start TLS:
> handshake failure)
>
> It reaches
> if (PLAINTEXT_FALLBACK_OK_AFTER_STARTTLS_FAILURE
FTER_STARTTLS_FAILURE.
Nik
-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org]
On Behalf Of Wietse Venema
Sent: 22 June 2017 20:17
To: Postfix users
Subject: Re: Message not retransmitted immediately after opportunistic TLS
handshake failure
Nik Ko
Nik Kostaras:
> As expected the TLS handshake fails, but Postfix moves the message
> to deferred queue rather than retrying immediately in plaintext.
What is the error message? The kind of error determines whether
or not Postfix will immediately fall back to plaintext immediately.
The Postfix vers
Hi all,
In one of my tests I'm configuring Postfix client (smtp) to use opportunistic
TLS with TLSv1.2 protocol only and the next MTA (server side) to use
opportunistic TLS with TLSv1.1 only,
to see the behaviour of Postfix after a failed handshake.
As expected the TLS handshake fails
On Thu, Mar 30, 2017 at 02:54:09PM +0200, Benny Pedersen wrote:
> Levente Birta skrev den 2017-03-30 14:27:
>
> > Mar 30 13:48:16 wsrv postfix/tlsproxy[34871]: CONNECT from
> > [98.137.64.231]:33591
> > Mar 30 13:48:16 wsrv postfix/tlsproxy[34871]: warning: TLS library
> > problem: error:14094416
o is justified. SHA1 should be avoided, but
admitedly no one would bother with the computational load needed for a
SHA1 attack on our opportunistic TLS email, particularly no spammer
trying to find a relay to use.
You did not respond to the rest of the email. Any comments o
On Fri, Jan 22, 2016 at 03:14:22PM -0500, Curtis Villamizar wrote:
> You might
> also want to report that the keys they use are less than LOW security
> but that might be a feature.
You're mistaken. These ciphers are HIGH.
> Note that none of the ciphers used by comcast.net support even low
> s
comcast, then please report that. You might
also want to report that the keys they use are less than LOW security
but that might be a feature. Please also ask when opportunistic TLS
was enabled.
Note that none of the ciphers used by comcast.net support even low
strength and forward secrecy.
cat
On Thu, Jan 21, 2016 at 10:55:19PM -0500, Curtis Villamizar wrote:
> It took a while to get a dumpfile. My tcpdump command only covered a
> subset of comcast.net mailhosts.
>
> This has a failed TLS negotiation and a few packets from a next
> attempt. The log entry below covers this first conne
In message <20160115235712.gn...@mournblade.imrryr.org>
Viktor Dukhovni writes:
>
> On Fri, Jan 15, 2016 at 06:47:38PM -0500, Curtis Villamizar wrote:
>
> > Viktor,
> >
> > If you are still interested below is a tcpdump.
> >
> > If not interested, please just delete.
>
> I was looking for a
In message <20160115235712.gn...@mournblade.imrryr.org>
Viktor Dukhovni writes:
>
> On Fri, Jan 15, 2016 at 06:47:38PM -0500, Curtis Villamizar wrote:
>
> > Viktor,
> >
> > If you are still interested below is a tcpdump.
> >
> > If not interested, please just delete.
>
> I was looking for a
On Fri, Jan 15, 2016 at 06:47:38PM -0500, Curtis Villamizar wrote:
> Viktor,
>
> If you are still interested below is a tcpdump.
>
> If not interested, please just delete.
I was looking for a binary PCAP file, not an ASCII decode. Yes,
it would be good to know whether Comcast was having ECDSA
In message <88031027-d5b8-4f48-947d-294302fac...@dukhovni.org>
Viktor Dukhovni writes:
> Post a PCAP file of a single failed TLS handshake. I know the person
> at comcast in charge of their email transport security. I can probably
> get them to fix it once we nail down the problem, assuming it
In message <20160115051749.gl...@mournblade.imrryr.org>
Viktor Dukhovni writes:
> On Thu, Jan 14, 2016 at 11:54:13PM -0500, Curtis Villamizar wrote:
>
> > > > > > smtp_tls_ciphers = high
> > > > >
> > > > > Usually best to leav
On Thu, Jan 14, 2016 at 11:54:13PM -0500, Curtis Villamizar wrote:
> > > > > smtp_tls_ciphers = high
> > > >
> > > > Usually best to leave this at "medium". This is opportunistic
> > > > TLS, and if high fails, you
> On Thu, Jan 14, 2016 at 03:53:23PM -0500, Curtis Villamizar wrote:
>
> > > > smtp_tls_ciphers = high
> > >
> > > Usually best to leave this at "medium". This is opportunistic
> > > TLS, and if high fails, you'll send cl
In message <20160114200215.gj...@mournblade.imrryr.org>
Viktor Dukhovni writes:
> On Thu, Jan 14, 2016 at 02:07:07PM -0500, Curtis Villamizar wrote:
>
> > In message
> > Curtis Villamizar writes:
> >
> > > btw - I just added "!TLSv1.0" to get only TLSv1.2. I wasn't sure I
> > > could specif
On Thu, Jan 14, 2016 at 03:53:23PM -0500, Curtis Villamizar wrote:
> > > smtp_tls_ciphers = high
> >
> > Usually best to leave this at "medium". This is opportunistic
> > TLS, and if high fails, you'll send cleartext, which is NOT
> >
m
> > smtp_tls_key_file = /etc/postfix/key.pem
>
> Usually best to not configure client certificates.
>
> > smtp_tls_ciphers = high
>
> Usually best to leave this at "medium". This is opportunistic
> TLS, and if high fails, you'll send clea
On Thu, Jan 14, 2016 at 02:07:07PM -0500, Curtis Villamizar wrote:
> In message
> Curtis Villamizar writes:
>
> > btw - I just added "!TLSv1.0" to get only TLSv1.2. I wasn't sure I
> > could specify !TLSv1.0 so I just tried it.
Who said the correct name is "TLSv1.0"?
http://www.postfix.o
In message
Curtis Villamizar writes:
> btw - I just added "!TLSv1.0" to get only TLSv1.2. I wasn't sure I
> could specify !TLSv1.0 so I just tried it.
>
> Curtis
oops that didn't work.
Curtis
_ciphers = high
Usually best to leave this at "medium". This is opportunistic
TLS, and if high fails, you'll send cleartext, which is NOT
stronger than medium.
> smtp_tls_exclude_ciphers = aNULL MD5 DES
Mostly harmless, but not ideal. Instead try:
In message <88031027-d5b8-4f48-947d-294302fac...@dukhovni.org>
Viktor Dukhovni writes:
>
> > On Jan 13, 2016, at 8:52 PM, Curtis Villamizar
> > wrote:
> >
> > The logs revealed something about the nature of the problem. A few of
> > these sort of messages were found.
> >
> > Jan 13 17:08:22 m
In message <3pgpvv0nvczj...@spike.porcupine.org>
Wietse Venema writes:
> Curtis Villamizar:
> > What I'd like to do is set smtpd_tls_security_level back to "may" and
> > then somehow set it to "none" if the EHLO domain is comcast.net (oops
> > the secret is out).
> >
> > I see we have smtp_tls_p
> On Jan 13, 2016, at 8:52 PM, Curtis Villamizar
> wrote:
>
> The logs revealed something about the nature of the problem. A few of
> these sort of messages were found.
>
> Jan 13 17:08:22 mta3 postfix/smtpd[15958]:
> warning: TLS library problem:
> error:1408A0C1:SSL
> routines:ssl3_ge
Curtis Villamizar:
> What I'd like to do is set smtpd_tls_security_level back to "may" and
> then somehow set it to "none" if the EHLO domain is comcast.net (oops
> the secret is out).
>
> I see we have smtp_tls_policy_maps, but no smtpd_tls_policy_maps.
Use this to suppress the STARTTLS announce
I turned on opportunistic TLS last summer I think. All was fine for a
long time. btw - I'm currently running the FreeBSD
postfix-current-3.0.20151003,4 port but previously used 2.8.
Somewhat recently someone with a residential cable provider account
complained that he got mail from me but
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
s to move on to other things to improve.
These aren't the droids you're looking for.
> "It is likely safe to set "smtp_tls_ciphers = medium" if you wish to
> disable the obsolete "export" and "low" grade ciphers even with
> opportunistic TLS.&qu
umentation lists that list?
> Best pracice is to leave them as-is.
Yet, that same page states:
"It is likely safe to set "smtp_tls_ciphers = medium" if you wish to
disable the obsolete "export" and "low" grade ciphers even with
opportunistic TLS.&
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
1 - 100 of 126 matches
Mail list logo
