Re: detect fake mx, tls security encrypt

[Noel Jones]

On 12/20/2018 11:42 AM, Stefan Bauer wrote:
> Hi,
> 
> i use smtp_tls_security_level = encrypt - if remote site have mx like
> 
> mx 10 mail1 without tls
> mx 100 mail2 fake-mx with no open port
> 
> postfix detects lack of tls on mx10goes to mx100 and waits
> maximal_queue_lifetime.
> 
> i don't like fake mx as they create a long delay.
> 
> i could reduce queue lifetime but in general thats bad for real
> systems with temp issues.
> 
> how do you handle this?
> 
> Stefan


Most people handle this by not using "encrypt" on a public server.

Postfix can't tell why the MX is dead, so the behavior is correct.

If you want to handle it differently, you'll need to add rules for
each site, such as a transport map entry that points only to the
main MX, or an error: transport entry.



  -- Noel Jones

Re: detect fake mx, tls security encrypt

[Viktor Dukhovni]

> On Dec 20, 2018, at 12:42 PM, Stefan Bauer  wrote:
> 
> I use smtp_tls_security_level = encrypt

The cost of that choice is that you must also have:

  main.cf:
indexed = ${default_database_type}:${config_directory}/
smtp_tls_policy_maps = ${indexed}tls-policy

and be prepared to watch your logs and add manual exceptions:

  tls-policy:
# Non-mandatory TLS for domains that don't (yet?) have
# working STARTTLS.  Perhaps "none" rather than "may" in
# some cases.
#
example.net may
...

-- 
Viktor.

Re: detect fake mx, tls security encrypt

[Stefan Bauer]

I'm aware of this exeptions but i dont like to set them. our policy is safe
or not at all via mail.

i would like to have a setting like do not try next mx, if first mx lacks
tls support. it assumes that if tls is not avail on primary it will for
sure also not be avail on second and third.

Am Donnerstag, 20. Dezember 2018 schrieb Viktor Dukhovni <
postfix-us...@dukhovni.org>:
>> On Dec 20, 2018, at 12:42 PM, Stefan Bauer 
wrote:
>>
>> I use smtp_tls_security_level = encrypt
>
> The cost of that choice is that you must also have:
>
>   main.cf:
> indexed = ${default_database_type}:${config_directory}/
> smtp_tls_policy_maps = ${indexed}tls-policy
>
> and be prepared to watch your logs and add manual exceptions:
>
>   tls-policy:
> # Non-mandatory TLS for domains that don't (yet?) have
> # working STARTTLS.  Perhaps "none" rather than "may" in
> # some cases.
> #
> example.net may
> ...
>
> --
> Viktor.
>
>

Re: detect fake mx, tls security encrypt

[Viktor Dukhovni]

> On Dec 20, 2018, at 1:25 PM, Stefan Bauer  wrote:
> 
> I'm aware of such exceptions but I don't like to set them.  Our policy is 
> safe or not at all via mail.

That policy has a cost.  You don't like the cost, but there it is...

> I would like to have a setting like do not try next mx,
> if first mx lacks tls support. it assumes that if tls is
> not avail on primary it will for sure also not be avail
> on second and third.

Sorry, Postfix does not and will not do that.  Data-mine your logs
for deliveries that fall back to a dead MX host (connection failure
and a large "c" value (>= smtp_connect_timeout) in the "delays=a/b/c/d"
part of the log entry, e.g.

  delays=263861/0.01/60/0, dsn=4.4.1, status=deferred
(connect to : Operation timed out)

Then, if you refuse to ever deliver in the clear, reject mail to
the domain.

  transport:
example.com error:5.1.2:Destination domain does not support STARTTLS

-- 
-- 
Viktor.

Re: detect fake mx, tls security encrypt

[Stefan Bauer]

thats a nice approach! thank you. will test.

Am Donnerstag, 20. Dezember 2018 schrieb Viktor Dukhovni <
postfix-us...@dukhovni.org>:
>> On Dec 20, 2018, at 1:25 PM, Stefan Bauer 
wrote:
>>
>> I'm aware of such exceptions but I don't like to set them.  Our policy
is safe or not at all via mail.
>
> That policy has a cost.  You don't like the cost, but there it is...
>
>> I would like to have a setting like do not try next mx,
>> if first mx lacks tls support. it assumes that if tls is
>> not avail on primary it will for sure also not be avail
>> on second and third.
>
> Sorry, Postfix does not and will not do that.  Data-mine your logs
> for deliveries that fall back to a dead MX host (connection failure
> and a large "c" value (>= smtp_connect_timeout) in the "delays=a/b/c/d"
> part of the log entry, e.g.
>
>   delays=263861/0.01/60/0, dsn=4.4.1, status=deferred
> (connect to : Operation timed out)
>
> Then, if you refuse to ever deliver in the clear, reject mail to
> the domain.
>
>   transport:
> example.com error:5.1.2:Destination domain does not support STARTTLS
>
> --
> --
> Viktor.
>

Re: detect fake mx, tls security encrypt

[Stefan Bauer]

nights later, a better approach seems to have a policy service that does
the tls pre-checking.

Something like this already around? ( i'm no coder but want to sponsor that
if someone can do it) pm please

Am Donnerstag, 20. Dezember 2018 schrieb Viktor Dukhovni <
postfix-us...@dukhovni.org>:
>> On Dec 20, 2018, at 1:25 PM, Stefan Bauer 
wrote:
>>
>> I'm aware of such exceptions but I don't like to set them.  Our policy
is safe or not at all via mail.
>
> That policy has a cost.  You don't like the cost, but there it is...
>
>> I would like to have a setting like do not try next mx,
>> if first mx lacks tls support. it assumes that if tls is
>> not avail on primary it will for sure also not be avail
>> on second and third.
>
> Sorry, Postfix does not and will not do that.  Data-mine your logs
> for deliveries that fall back to a dead MX host (connection failure
> and a large "c" value (>= smtp_connect_timeout) in the "delays=a/b/c/d"
> part of the log entry, e.g.
>
>   delays=263861/0.01/60/0, dsn=4.4.1, status=deferred
> (connect to : Operation timed out)
>
> Then, if you refuse to ever deliver in the clear, reject mail to
> the domain.
>
>   transport:
> example.com error:5.1.2:Destination domain does not support STARTTLS
>
> --
> --
> Viktor.
>

Re: detect fake mx, tls security encrypt

[Robert Schetterer]

Am 22.12.18 um 07:55 schrieb Stefan Bauer:
nights later, a better approach seems to have a policy service that does 
the tls pre-checking.



long time ago i wrote this

https://blog.sys4.de/recipient-verification-tls-mandatory-modus-en.html

perhaps it helps



Something like this already around? ( i'm no coder but want to sponsor 
that if someone can do it) pm please


Am Donnerstag, 20. Dezember 2018 schrieb Viktor Dukhovni 
mailto:postfix-us...@dukhovni.org>>:
 >> On Dec 20, 2018, at 1:25 PM, Stefan Bauer > wrote:

 >>
 >> I'm aware of such exceptions but I don't like to set them.  Our 
policy is safe or not at all via mail.

 >
 > That policy has a cost.  You don't like the cost, but there it is...
 >
 >> I would like to have a setting like do not try next mx,
 >> if first mx lacks tls support. it assumes that if tls is
 >> not avail on primary it will for sure also not be avail
 >> on second and third.
 >
 > Sorry, Postfix does not and will not do that.  Data-mine your logs
 > for deliveries that fall back to a dead MX host (connection failure
 > and a large "c" value (>= smtp_connect_timeout) in the "delays=a/b/c/d"
 > part of the log entry, e.g.
 >
 >   delays=263861/0.01/60/0, dsn=4.4.1, status=deferred
 >     (connect to : Operation timed out)
 >
 > Then, if you refuse to ever deliver in the clear, reject mail to
 > the domain.
 >
 >   transport:
 > example.com  error:5.1.2:Destination domain does 
not support STARTTLS

 >
 > --
 > --
 >         Viktor.
 >



--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: detect fake mx, tls security encrypt

[Stefan Bauer]

Hi Robert,

thanks. already saw that but i dont want to bother remote sites with a
'full verify'. still like the policy server approach. should be no big
thing for a coder - familiar with perl.

Am Samstag, 22. Dezember 2018 schrieb Robert Schetterer :
> Am 22.12.18 um 07:55 schrieb Stefan Bauer:
>>
>> nights later, a better approach seems to have a policy service that does
the tls pre-checking.
>
>
> long time ago i wrote this
>
> https://blog.sys4.de/recipient-verification-tls-mandatory-modus-en.html
>
> perhaps it helps
>
>>
>> Something like this already around? ( i'm no coder but want to sponsor
that if someone can do it) pm please
>>
>> Am Donnerstag, 20. Dezember 2018 schrieb Viktor Dukhovni <
postfix-us...@dukhovni.org >:
>>  >> On Dec 20, 2018, at 1:25 PM, Stefan Bauer mailto:cubew...@googlemail.com>> wrote:
>>  >>
>>  >> I'm aware of such exceptions but I don't like to set them.  Our
policy is safe or not at all via mail.
>>  >
>>  > That policy has a cost.  You don't like the cost, but there it is...
>>  >
>>  >> I would like to have a setting like do not try next mx,
>>  >> if first mx lacks tls support. it assumes that if tls is
>>  >> not avail on primary it will for sure also not be avail
>>  >> on second and third.
>>  >
>>  > Sorry, Postfix does not and will not do that.  Data-mine your logs
>>  > for deliveries that fall back to a dead MX host (connection failure
>>  > and a large "c" value (>= smtp_connect_timeout) in the
"delays=a/b/c/d"
>>  > part of the log entry, e.g.
>>  >
>>  >   delays=263861/0.01/60/0, dsn=4.4.1, status=deferred
>>  > (connect to : Operation timed out)
>>  >
>>  > Then, if you refuse to ever deliver in the clear, reject mail to
>>  > the domain.
>>  >
>>  >   transport:
>>  > example.com  error:5.1.2:Destination domain does
not support STARTTLS
>>  >
>>  > --
>>  > --
>>  > Viktor.
>>  >
>
>
> --
> [*] sys4 AG
>
> http://sys4.de, +49 (89) 30 90 46 64
> Schleißheimer Straße 26/MG, 80333 München
>
> Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
> Vorstand: Patrick Ben Koetter, Marc Schiffbauer
> Aufsichtsratsvorsitzender: Florian Kirstein
>