Host offered STARTTLS: [mxlb... without relation to destination domain

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Host offered STARTTLS: [mxlb... without relation to destination domain

Stefan Bauer-2
I like the option smtp_tls_note_starttls_offer = yes
but when a host is logged, it's hard to keep track to which recipient domain that host belong without doing dns-lookups against all listed in smtp_tls_policy_maps.

Can this be improved to maybe also list the appropriate recipient domain?
Reply | Threaded
Open this post in threaded view
|

Re: Host offered STARTTLS: [mxlb... without relation to destination domain

Wietse Venema
Stefan Bauer:
> I like the option smtp_tls_note_starttls_offer = yes
> but when a host is logged, it's hard to keep track to which recipient
> domain that host belong without doing dns-lookups against all listed in
> smtp_tls_policy_maps.
>
> Can this be improved to maybe also list the appropriate recipient domain?

This information is logged then the TLS level is set to NONE.

Why not set the default TLS level to 'may' (perhaps with appropriate
default ciphers/protocols/etc) and automatically discover what
recipients can really be delivered over TLS?

The existence of a STARTTLS announcement does not mean that
you will actually be able to interoperate with the server.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Host offered STARTTLS: [mxlb... without relation to destination domain

Viktor Dukhovni
In reply to this post by Stefan Bauer-2


> On Sep 9, 2018, at 9:46 AM, Stefan Bauer <[hidden email]> wrote:
>
> I like the option smtp_tls_note_starttls_offer = yes
> but when a host is logged, it's hard to keep track to which recipient
> domain that host belong without doing dns-lookups against all listed
> in smtp_tls_policy_maps.

Well, TLS is by nexthop domain not recipient domain.  Typically the
nexthop domain is the recipient domain, but with "relayhost" or
other transport overrides, they need not be the same.  So if your
goal is discover which policy got you there, then you want the
nexthop logged.

If you use the collate.pl script (which may need tweaks to
match the initial boilerplate part of your syslog message format
with the data, hostname, ...) included with the Postfix source
you can see which deliveries correspond to the messages in
question.  We could log the nexthop domain in a future release,
this is not an unreasonable request.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Host offered STARTTLS: [mxlb... without relation to destination domain

Stefan Bauer-2
That would be great to have this as part of the log string! Thank you for considering my request.

Am So., 9. Sep. 2018 um 19:03 Uhr schrieb Viktor Dukhovni <[hidden email]>:


> On Sep 9, 2018, at 9:46 AM, Stefan Bauer <[hidden email]> wrote:
>
> I like the option smtp_tls_note_starttls_offer = yes
> but when a host is logged, it's hard to keep track to which recipient
> domain that host belong without doing dns-lookups against all listed
> in smtp_tls_policy_maps.

Well, TLS is by nexthop domain not recipient domain.  Typically the
nexthop domain is the recipient domain, but with "relayhost" or
other transport overrides, they need not be the same.  So if your
goal is discover which policy got you there, then you want the
nexthop logged.

If you use the collate.pl script (which may need tweaks to
match the initial boilerplate part of your syslog message format
with the data, hostname, ...) included with the Postfix source
you can see which deliveries correspond to the messages in
question.  We could log the nexthop domain in a future release,
this is not an unreasonable request.

--
        Viktor.