On Wed, Feb 26, 2014 at 05:40:38PM +0100, li...@rhsoft.net wrote:
> that's why I wanted to make clear if the limitation is a
> strong technical one or "only" highly recommended
Strongly recommended for all but the most determined DIY users who
are at the mercy of their own skills and attention to
Am 26.02.2014 17:30, schrieb Viktor Dukhovni:
>> no - the two dns servers are already in the LAN and working
>>
>> they are trusted and if i do not trust my own LAN i also can
>> not trust a forwarder running on 127.0.0.1 asking them
>
> Without an anti-spoofing firewall, remote name servers may b
On Wed, Feb 26, 2014 at 10:42:29AM +0100, li...@rhsoft.net wrote:
> > If the LAN housing the MTAs and multiple caching nameservers is
> > physically secure and well firewalled, you could potentially rely
> > on that physical security and firewall anti-spoofing rules.
>
> that is the point: if i d
Zitat von li...@rhsoft.net:
Am 26.02.2014 12:48, schrieb Wietse Venema:
lst_ho...@kwsoft.de:
Yes, of course. In practice, for most users, the local resolver
is by far the simplest configuration.
Is or will this be "enforced" by Postfix in some way for DANE?
Postfix does not parse /etc/re
Am 26.02.2014 12:57, schrieb Wietse Venema:
> li...@rhsoft.net:
>> Am 26.02.2014 12:48, schrieb Wietse Venema:
>>> lst_ho...@kwsoft.de:
> Yes, of course. In practice, for most users, the local resolver
> is by far the simplest configuration.
Is or will this be "enforced" by Pos
li...@rhsoft.net:
> Am 26.02.2014 12:48, schrieb Wietse Venema:
> > lst_ho...@kwsoft.de:
> >>> Yes, of course. In practice, for most users, the local resolver
> >>> is by far the simplest configuration.
> >>
> >> Is or will this be "enforced" by Postfix in some way for DANE?
> >
> > Postfix does
Am 26.02.2014 12:48, schrieb Wietse Venema:
> lst_ho...@kwsoft.de:
>>> Yes, of course. In practice, for most users, the local resolver
>>> is by far the simplest configuration.
>>
>> Is or will this be "enforced" by Postfix in some way for DANE?
>
> Postfix does not parse /etc/resolv.conf
so c
Zitat von wie...@porcupine.org:
lst_ho...@kwsoft.de:
> Yes, of course. In practice, for most users, the local resolver
> is by far the simplest configuration.
Is or will this be "enforced" by Postfix in some way for DANE?
Postfix does not parse /etc/resolv.conf.
Wietse
Thanks!
lst_ho...@kwsoft.de:
> > Yes, of course. In practice, for most users, the local resolver
> > is by far the simplest configuration.
>
> Is or will this be "enforced" by Postfix in some way for DANE?
Postfix does not parse /etc/resolv.conf.
Wietse
Zitat von Viktor Dukhovni :
On Wed, Feb 26, 2014 at 07:43:25AM +0100, Erwan David wrote:
> The local resolver can have the resolvers on the LAN configured as
> forwarders, but you need the local stub resolver. No reason not to have
> one, really, especially on a busy mail server.
However you
Am 26.02.2014 07:33, schrieb Viktor Dukhovni:
> On Wed, Feb 26, 2014 at 12:54:37AM +0100, li...@rhsoft.net wrote:
>
>>> The local resolver can have the resolvers on the LAN configured as
>>> forwarders, but you need the local stub resolver. No reason not to have
>>> one, really, especially on
Am 26.02.2014 02:25, schrieb DTNX Postmaster:
> On 26 Feb 2014, at 00:54, li...@rhsoft.net wrote:
>> Am 26.02.2014 00:46, schrieb DTNX Postmaster:
>>> On 26 Feb 2014, at 00:29, li...@rhsoft.net wrote:
Am 25.02.2014 17:41, schrieb Dirk Stöcker:
> On Tue, 25 Feb 2014, Viktor Dukhovni wrote:
On 26 Feb 2014, at 07:46, Viktor Dukhovni wrote:
> On Wed, Feb 26, 2014 at 07:43:25AM +0100, Erwan David wrote:
>
>>> The local resolver can have the resolvers on the LAN configured as
>>> forwarders, but you need the local stub resolver. No reason not to have
>>> one, really, especially on a
On Wed, Feb 26, 2014 at 07:43:25AM +0100, Erwan David wrote:
> > The local resolver can have the resolvers on the LAN configured as
> > forwarders, but you need the local stub resolver. No reason not to have
> > one, really, especially on a busy mail server.
>
> However your "local" resolver co
On Wed, Feb 26, 2014 at 12:46:13AM CET, DTNX Postmaster
said:
> On 26 Feb 2014, at 00:29, li...@rhsoft.net wrote:
>
> > Am 25.02.2014 17:41, schrieb Dirk Stöcker:
> >> On Tue, 25 Feb 2014, Viktor Dukhovni wrote:
> smtp_dns_support_level = dnssec
>
> was enough to fix this. I'll s
On Wed, Feb 26, 2014 at 12:54:37AM +0100, li...@rhsoft.net wrote:
> > The local resolver can have the resolvers on the LAN configured as
> > forwarders, but you need the local stub resolver. No reason not to have
> > one, really, especially on a busy mail server
>
> yes, you normally have a loc
On 26 Feb 2014, at 00:54, li...@rhsoft.net wrote:
> Am 26.02.2014 00:46, schrieb DTNX Postmaster:
>> On 26 Feb 2014, at 00:29, li...@rhsoft.net wrote:
>>> Am 25.02.2014 17:41, schrieb Dirk Stöcker:
On Tue, 25 Feb 2014, Viktor Dukhovni wrote:
>> smtp_dns_support_level = dnssec
>>
Am 26.02.2014 00:46, schrieb DTNX Postmaster:
> On 26 Feb 2014, at 00:29, li...@rhsoft.net wrote:
>> Am 25.02.2014 17:41, schrieb Dirk Stöcker:
>>> On Tue, 25 Feb 2014, Viktor Dukhovni wrote:
> smtp_dns_support_level = dnssec
>
> was enough to fix this. I'll see how many servers will
On 26 Feb 2014, at 00:29, li...@rhsoft.net wrote:
> Am 25.02.2014 17:41, schrieb Dirk Stöcker:
>> On Tue, 25 Feb 2014, Viktor Dukhovni wrote:
smtp_dns_support_level = dnssec
was enough to fix this. I'll see how many servers will have a
"Verified" connection in the future.
>>>
Am 25.02.2014 17:41, schrieb Dirk Stöcker:
> On Tue, 25 Feb 2014, Viktor Dukhovni wrote:
>>> smtp_dns_support_level = dnssec
>>>
>>> was enough to fix this. I'll see how many servers will have a
>>> "Verified" connection in the future.
>>
>> I hope you read the note about the importance of having
On Tue, 25 Feb 2014, Viktor Dukhovni wrote:
smtp_dns_support_level = dnssec
was enough to fix this. I'll see how many servers will have a
"Verified" connection in the future.
I hope you read the note about the importance of having 127.0.0.1
and/or ::1 as the only nameservers listed in /etc/re
* Viktor Dukhovni :
> On Tue, Feb 25, 2014 at 09:57:13AM +0100, Dirk St?cker wrote:
>
> > smtp_dns_support_level = dnssec
> >
> > was enough to fix this. I'll see how many servers will have a
> > "Verified" connection in the future.
>
> I hope you read the note about the importance of having 127
On Tue, Feb 25, 2014 at 09:57:13AM +0100, Dirk St?cker wrote:
> smtp_dns_support_level = dnssec
>
> was enough to fix this. I'll see how many servers will have a
> "Verified" connection in the future.
I hope you read the note about the importance of having 127.0.0.1
and/or ::1 as the only namese
On 2/24/2014 3:52 PM, /dev/rob0 wrote:
On Mon, Feb 24, 2014 at 01:16:39AM +0100, Dirk Stöcker wrote:
On Sun, 23 Feb 2014, Viktor Dukhovni wrote:
If you want scalable security for SMTP, become an early adopter
of DANE TLS, available in Postfix 2.11. Today, you'll be able
to opportunistically a
On Tue, 25 Feb 2014, Dirk Stöcker wrote:
Hmpf. It says "dane configured with dnssec lookups disabled". Seems I need to
fix the RPM first.
No, a
smtp_dns_support_level = dnssec
was enough to fix this. I'll see how many servers will have a "Verified"
connection in the future.
Ciao
--
http:/
Hello,
But I have no idea how to use the postfix tools to start a TLS
connection to such an server without sending an email. This requires
too much internal knowledge I fear. Last time I tried to call smtp
tool by hand it told me not to do so and I took that advice.
/usr/sbin/sendmail -f $(
On Mon, Feb 24, 2014 at 04:38:12PM -0600, /dev/rob0 wrote:
> On Mon, Feb 24, 2014 at 02:36:46PM -0700, LuKreme wrote:
> > On 24 Feb 2014, at 06:09 , Viktor Dukhovni
> > wrote:
> > > On Mon, Feb 24, 2014 at 12:26:42PM +0100, Dirk St?cker wrote:
> > >
> > > Nonsense. Patrick Koetter's .de domain
On Mon, Feb 24, 2014 at 02:36:46PM -0700, LuKreme wrote:
> On 24 Feb 2014, at 06:09 , Viktor Dukhovni
> wrote:
> > On Mon, Feb 24, 2014 at 12:26:42PM +0100, Dirk St?cker wrote:
> >
> > Nonsense. Patrick Koetter's .de domain is DNSSEC signed. His
> > mailserver has TLSA records. Enabling DNSS
On Mon, Feb 24, 2014 at 10:15:48PM +0100, Dirk St?cker wrote:
> >You're asking for a verification status that would indicate
> >conditional MITM protection:
> >
> > - False negative: MITM protection is illusory when the MX
> > hostname is compromised through DNS record forgery.
> >
> > - F
On 24 Feb 2014, at 06:09 , Viktor Dukhovni wrote:
> On Mon, Feb 24, 2014 at 12:26:42PM +0100, Dirk St?cker wrote:
>
> Nonsense. Patrick Koetter's .de domain is DNSSEC signed. His
> mailserver has TLSA records. Enabling DNSSEC does not prevent you
> from communicating with the rest of the world
On Mon, 24 Feb 2014, Viktor Dukhovni wrote:
With a bit of luck roughly 5 years. Exim has not implemented DANE
yet, and the RFC for DANE TLS for SMTP has not yet been ratified
by the IETF. The first Postfix release with DANE just came out
last month, and is not in most O/S distributions.
You'
On Mon, Feb 24, 2014 at 01:16:39AM +0100, Dirk Stöcker wrote:
> On Sun, 23 Feb 2014, Viktor Dukhovni wrote:
> >If you want scalable security for SMTP, become an early adopter
> >of DANE TLS, available in Postfix 2.11. Today, you'll be able
> >to opportunistically authenticate the handful of DNSSEC
On Mon, Feb 24, 2014 at 07:03:21PM +0100, Dirk St?cker wrote:
> >Nonsense. Patrick Koetter's .de domain is DNSSEC signed. His
> >mailserver has TLSA records. Enabling DNSSEC does not prevent you
> >from communicating with the rest of the world. Furthermore, you
> >can enable DNSSEC validation
Am 24.02.2014 19:03, schrieb Dirk Stöcker:
> On Mon, 24 Feb 2014, Viktor Dukhovni wrote:
>
>>> I don't want to have a perfection box which can't communicate with
>>> the rest of the world, but something which helps with todays
>>> internet.
>>
>> Nonsense. Patrick Koetter's .de domain is DNSSEC s
On Mon, 24 Feb 2014, Viktor Dukhovni wrote:
I don't want to have a perfection box which can't communicate with
the rest of the world, but something which helps with todays
internet.
Nonsense. Patrick Koetter's .de domain is DNSSEC signed. His
mailserver has TLSA records. Enabling DNSSEC doe
On Mon, Feb 24, 2014 at 12:26:42PM +0100, Dirk St?cker wrote:
> > >Oh yes - DNSSEC. When will it come? In hundred years?
> >
> >Available today. Two of my domains are signed, the third will be
> >shortly. And you're complaining about people being complacent and
> >stuck in the past.
>
> I don't
Dirk St?cker:
> >> 5) with a trusted cert matching the hostname + hostname == reverse DNS
> >
> > This is even more meaningless.
>
> It is an additional level of security. Only a very small bit, yes, but it
PLEASE DO NOT call this "security". This stuff is weaker than spam
filter heuristics, an
On Mon, 24 Feb 2014, Viktor Dukhovni wrote:
I know that there are many side-effects and things which don't work,
but that does not mean that one can at least try?
Sorry, no half-assed solutions that work only sometimes and break
unpredictably.
Yes, the same story again. When it does not work
On Mon, Feb 24, 2014 at 01:16:39AM +0100, Dirk St?cker wrote:
> >SMTP is not HTTP. Due to MX indirection, peer authentication is
> >not possible without explicit per-destination configuration. Once
> >you've gone to all that trouble, you may as well configure a "secure"
> >channel.
>
> I know t
Dirk St?cker:
> On Sun, 23 Feb 2014, Viktor Dukhovni wrote:
>
> >> I hope there aren't any TLS capable mailservers, which fallback to
> >> unencrypted transmission, when I use this.
> >
> > Fallback is up the client. I am not aware of any Internet facing
> > MX hosts that offer STARTTLS without a
On 23 Feb 2014, at 15:57 , Dirk Stöcker wrote:
> Seems Postfix still need to learn a lot about secure connections. Your
No, you are simply not understanding the purpose of opportunistic TLS. The
purpose is not to verify identity, but simply to encrypt the transmission
channel. Identity is meani
Am 24.02.2014 01:16, schrieb Dirk Stöcker:
> On Sun, 23 Feb 2014, Viktor Dukhovni wrote:
>>> smtp_tls_verify_certs=whenpossible
>>
>> SMTP is not HTTP. Due to MX indirection, peer authentication is
>> not possible without explicit per-destination configuration. Once
>> you've gone to all that
On Sun, 23 Feb 2014, Viktor Dukhovni wrote:
I hope there aren't any TLS capable mailservers, which fallback to
unencrypted transmission, when I use this.
Fallback is up the client. I am not aware of any Internet facing
MX hosts that offer STARTTLS without any server certificate. Lots
of SMTP
On Sun, 23 Feb 2014, Viktor Dukhovni wrote:
smtp_tls_verify_certs=whenpossible
SMTP is not HTTP. Due to MX indirection, peer authentication is
not possible without explicit per-destination configuration. Once
you've gone to all that trouble, you may as well configure a "secure"
channel.
I
On Mon, Feb 24, 2014 at 12:25:50AM +0100, Dirk St?cker wrote:
> >> smtp_tls_exclude_ciphers=aNULL
> >>
> >> for the transport that delivers mail between your internal systems.
> >
> >Does not sound like what I want. I don't want to hardcode a
> >specific handling for some servers, I want that the
On Sun, Feb 23, 2014 at 11:57:35PM +0100, Dirk St?cker wrote:
> >When both sides are Postfix, and the client is opportunistic, the
> >server and client typically agree to a cipher-suite without any
> >certificates. Why bother, if the client does not check anyway.
>
> Because it allows to at to l
On Sun, 23 Feb 2014, Dirk Stöcker wrote:
If this is important to you, set:
smtp_tls_exclude_ciphers=aNULL
for the transport that delivers mail between your internal systems.
Does not sound like what I want. I don't want to hardcode a specific handling
for some servers, I want that the "
On Mon, 24 Feb 2014, li...@rhsoft.net wrote:
Seems Postfix still need to learn a lot about secure connections
seems you need to do so
in case of opportunistic there is not real trust
trusted in case of a secure connection means both sides know each
other - opportunistic means the other side
Am 23.02.2014 23:57, schrieb Dirk Stöcker:
> Seems Postfix still need to learn a lot about secure connections
seems you need to do so
in case of opportunistic there is not real trust
trusted in case of a secure connection means both sides know each
other - opportunistic means the other side nee
On Sun, 23 Feb 2014, Viktor Dukhovni wrote:
On Sun, Feb 23, 2014 at 02:28:07PM +0100, Dirk St?cker wrote:
And whatever I do I'm unable to get any of these three to show a
trusted connection to any of the others. It trusts Google and GMX
and whatever, but not my own servers. That's disturbing.
Viktor Dukhovni:
> diff --git a/src/tls/tls_client.c b/src/tls/tls_client.c
> --- a/src/tls/tls_client.c
> +++ b/src/tls/tls_client.c
> @@ -1045,7 +1045,9 @@ TLS_SESS_STATE *tls_client_start(const
> TLS_CLIENT_START_PROPS *props)
> */
> if (log_mask & TLS_LOG_SUMMARY)
> msg_info("
On Sun, Feb 23, 2014 at 02:28:07PM +0100, Dirk St?cker wrote:
> And whatever I do I'm unable to get any of these three to show a
> trusted connection to any of the others. It trusts Google and GMX
> and whatever, but not my own servers. That's disturbing.
>
> Here the configs I use essentially
E
52 matches
Mail list logo
