Dear Viktor, dear Wietse,
Am 25.11.22 um 17:25 schrieb Viktor Dukhovni:
On Fri, Nov 25, 2022 at 09:35:28AM -0500, Wietse Venema wrote:
Viktor Dukhovni:
However, in this case the issue is a minor oversight in the Postfix TLS
client code. The intended logging behaviour does not happen. Patch
On Fri, Nov 25, 2022 at 09:35:28AM -0500, Wietse Venema wrote:
> Viktor Dukhovni:
> > However, in this case the issue is a minor oversight in the Postfix TLS
> > client code. The intended logging behaviour does not happen. Patch
> > below:
>
> Is there an equivalent for the still supported Postf
On Fri, Nov 25, 2022 at 09:35:28AM -0500, Wietse Venema wrote:
> > However, in this case the issue is a minor oversight in the Postfix TLS
> > client code. The intended logging behaviour does not happen. Patch
> > below:
>
> Is there an equivalent for the still supported Postfix version 3.5?
>
Viktor Dukhovni:
> However, in this case the issue is a minor oversight in the Postfix TLS
> client code. The intended logging behaviour does not happen. Patch
> below:
Is there an equivalent for the still supported Postfix version 3.5?
That would also fix Postfix version 3.4 which has the same
On 2022-11-21 at 14:45:52 UTC-0500 (Mon, 21 Nov 2022 20:45:52 +0100)
Paul Menzel
is rumored to have said:
Dear Bill,
Thank you for your reply.
Am 21.11.22 um 19:05 schrieb Bill Cole:
On 2022-11-21 at 12:18:33 UTC-0500 (Mon, 21 Nov 2022 18:18:33 +0100)
Paul Menzel is rumored to have said:
Dear Bill,
Thank you for your reply.
Am 21.11.22 um 19:05 schrieb Bill Cole:
On 2022-11-21 at 12:18:33 UTC-0500 (Mon, 21 Nov 2022 18:18:33 +0100)
Paul Menzel is rumored to have said:
With Postfix 3.6.0-RC1 and
# postconf -n smtp_tls_security_level
smtp_tls_security_level = dane
th
On Mon, Nov 21, 2022 at 06:18:33PM +0100, Paul Menzel wrote:
> With Postfix 3.6.0-RC1 and
I am curious why you are using a rather dated release-candidate.
> After a while of head scratching, I thought it might have to do with the
> SMTP servers publishing TLSA records, but the domain in the ema
On 2022-11-21 at 12:18:33 UTC-0500 (Mon, 21 Nov 2022 18:18:33 +0100)
Paul Menzel
is rumored to have said:
Dear Postfix folks,
With Postfix 3.6.0-RC1 and
# postconf -n smtp_tls_security_level
smtp_tls_security_level = dane
the Postfix SMTP client logs several untrusted TLS connection
Dear Postfix folks,
With Postfix 3.6.0-RC1 and
# postconf -n smtp_tls_security_level
smtp_tls_security_level = dane
the Postfix SMTP client logs several untrusted TLS connections for hosts
with a good TLS certificate setup.
It’s mainly German research organizations using the DFN-Mai
Dear Postfix folks,
Am 17.02.22 um 15:56 schrieb Paul Menzel:
Am 17.02.22 um 10:57 schrieb Paul Menzel:
Using Postfix 3.6.0-rc1, for an email sent to x.y.molgen.mpg.de it
looks up the TLSA records for y.molgen.mpg.de instead of
x.y.molgen.mpg.de:
2022-02-12T12:02:21+01:00 tldr postfi
Dear Postfix folks,
Am 17.02.22 um 10:57 schrieb Paul Menzel:
Using Postfix 3.6.0-rc1, for an email sent to x.y.molgen.mpg.de it looks
up the TLSA records for y.molgen.mpg.de instead of x.y.molgen.mpg.de:
2022-02-12T12:02:21+01:00 tldr postfix/smtp[25656]: warning: TLS policy
lookup fo
Dear Postfix folks,
Using Postfix 3.6.0-rc1, for an email sent to x.y.molgen.mpg.de it looks
up the TLSA records for y.molgen.mpg.de instead of x.y.molgen.mpg.de:
2022-02-12T12:02:21+01:00 tldr postfix/smtp[25656]: warning: TLS
policy lookup for github.molgen.mpg.de/github.molgen.mpg.de:
Dan Mahoney wrote
>> Here's an SMTP DANE validator that I use when I make changes to my server.
>> https://dane.sys4.de/
>>
>> I'm not sure if it is just what you're looking for, though.
>
> No, I am looking for a server to which I can send mail to make sure DANE is
> being looked up and used
On Mon, Jan 03, 2022 at 09:47:44AM -0800, Dan Mahoney wrote:
> Also...the server I'm sending to has a legit signed cert that matches
> its hostname, so the message I get is:
>
> Trusted TLS connection established to prime.gushi.org[149.20.68.142]:25:
> TLSv1.2 with cipher ECDHE-RSA-AES256-G
On 2022-01-03 23:02, Dan Mahoney wrote:
On Jan 3, 2022, at 1:46 PM, Mike wrote:
On 1/3/2022 2:38 PM, Dan Mahoney (Gushi) wrote:
[snip]
One more question: Does anyone know of a "reflector" like service
that one
can use to test DANE validation, i.e. a site that one is allowed to
send
test me
> On Jan 3, 2022, at 1:46 PM, Mike wrote:
>
> On 1/3/2022 2:38 PM, Dan Mahoney (Gushi) wrote:
>> [snip]
>>
>> One more question: Does anyone know of a "reflector" like service that one
>> can use to test DANE validation, i.e. a site that one is allowed to send
>> test messages to, that *onl
On 1/3/2022 2:38 PM, Dan Mahoney (Gushi) wrote:
>[snip]
>
> One more question: Does anyone know of a "reflector" like service that one
> can use to test DANE validation, i.e. a site that one is allowed to send
> test messages to, that *only* has DANE as the trust mech (so, say, a
> self-signed
On Mon, 3 Jan 2022, Dan Mahoney wrote:
This is a problem when your local resolver is slaving the root zone, as a standard root
zone "type slave" will hand . NS out with the AA bit set, but will not set the
AD bit.
There's a feature in more recent versions of BIND (mirror zones) that may fix
Dan Mahoney:
> > If you enable DNSSEC lookups, Postfix will log a warning when the root
> > zone appears unsigned. See:
> >
> >http://www.postfix.org/postconf.5.html#dnssec_probe
> >
> >This feature is available in Postfix 3.6 and later. It was
> >backported to Postfix versions 3.5.9
> On Jan 3, 2022, at 6:22 AM, Viktor Dukhovni
> wrote:
>
> On Mon, Jan 03, 2022 at 05:49:05AM -0800, Dan Mahoney (Gushi) wrote:
>
>> We run validating resolvers at the day job, but by default not on the box
>> where postfix runs. (I.e. we rely on the AD bit).
>
> "Relying in the AD bit" i
On Mon, Jan 03, 2022 at 05:49:05AM -0800, Dan Mahoney (Gushi) wrote:
> We run validating resolvers at the day job, but by default not on the box
> where postfix runs. (I.e. we rely on the AD bit).
"Relying in the AD bit" is independent of whether the validating
resolver is local or remote. How
Hey there,
We run validating resolvers at the day job, but by default not on the box
where postfix runs. (I.e. we rely on the AD bit).
In reading over what's required to enable DANE support in postfix, I see
that there's a compile-time requirement for the DNS lib in the OS to
support it, wh
On 4/17/20 4:29 PM, Viktor Dukhovni wrote:
> More at:
all links appreciated.
the summary's particularly nicely readable by those of among the minion masses
of normal humans ;-)
> Postfix documentation covers the client side
still among the best, most-exhaustively detailed s/docs/reference man/
l.sys4.de/pipermail/dane-users/2017-August/000417.html
> Any favorites/recommendations for current "what/why" & "how to" DNSSEC/DANE
> with Postfix docs/tutorials/posts/etc?
Postfix documentation covers the client side, but the DANE for servers
HOTWO has not yet been written.
all this back-n-forth on list re: DNSSEC/DANE has resulted in a flurry of
interest among colleagues etc. and i've been getting emails. lots.
for the what/why i've been tossing them Viktor's now just slightly dusty preso
Real World DANE Inter-domain email transport
https:/
I wrote the attached script to help me with key rollover.
I am not sure where to go with this. If anybody is interested take a
look and make what use of you will.
Comments and suggestions please.
John A
#!/bin/bash
#
# Why this script, the ISC has do created a number of tools to manage and
gen
On December 31, 2014 12:37:52 PM Viktor Dukhovni
wrote:
On Wed, Dec 31, 2014 at 12:45:20AM -0500, John wrote:
> https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.1
> https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.4
Sorry,
Don't worry about it.
https://tools.ietf.or
On Wed, Dec 31, 2014 at 12:23:16AM -0500, John wrote:
> >>smtpd_use_tls = yes
> >>smtpd_tls_security_level = may
>
> Just so I get this right "/smtpd_tls_security_level = dane/" is acceptable,
No, DANE TLS is for the sending (verifying) MTA only.
--
Viktor.
On Wed, Dec 31, 2014 at 12:45:20AM -0500, John wrote:
> https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.1
> https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.4
Sorry,
https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1
https://tools.ietf.org/html/draft-ietf-dane-
/smtpd_tls_security_level = dane/.
postconf does not show any error for the above, but postfix itself does
"fatal: invalid TLS level "dane" - I have switched back to may
--
John Allen
KLaM
--
You are off the edge of the map, mate. Here there be monsters!
https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.1
https://tools.ietf.org/draft-ietf-dane-ops-07#section-8.4
Both of the above return "object not found" I assume that as they are
both draft docs they come and go as the editors update them.
I will keep an eye on the site, hopefully catch t
On 12/30/2014 11:19 PM, Viktor Dukhovni wrote:
On Tue, Dec 30, 2014 at 07:47:24PM -0500, John wrote:
I have setup my DNS server for DNSSEC + DANE. I am using inline signing on
Bind9 and it appears to be working for HTTPS access.
I have a minor problem with key rolling, it seems to be a rather
On Tue, Dec 30, 2014 at 07:47:24PM -0500, John wrote:
> I have setup my DNS server for DNSSEC + DANE. I am using inline signing on
> Bind9 and it appears to be working for HTTPS access.
> I have a minor problem with key rolling, it seems to be a rather cumbersome
> process at the m
On 12/30/2014 7:58 PM, wie...@porcupine.org (Wietse Venema) wrote:
Wietse Venema:
John:
*Dec 30 19:16:35 bilbo postfix/smtp[3376]: warning: [127.0.0.1]:10024:
dane configured with dnssec lookups disabled*
Have you noticed the "unused parameter" warning for smtp_dns_supporta_level?
That is, wh
Wietse Venema:
> John:
> > *Dec 30 19:16:35 bilbo postfix/smtp[3376]: warning: [127.0.0.1]:10024:
> > dane configured with dnssec lookups disabled*
>
> Have you noticed the "unused parameter" warning for smtp_dns_supporta_level?
That is, when you use the postconf command to show the
configurati
John:
> *Dec 30 19:16:35 bilbo postfix/smtp[3376]: warning: [127.0.0.1]:10024:
> dane configured with dnssec lookups disabled*
Have you noticed the "unused parameter" warning for smtp_dns_supporta_level?
Wietse
I have setup my DNS server for DNSSEC + DANE. I am using inline signing
on Bind9 and it appears to be working for HTTPS access.
I have a minor problem with key rolling, it seems to be a rather
cumbersome process at the moment, but I suspect that it is me rather
than the process.
Having got it
37 matches
Mail list logo
