20200108 -- nexthop destinations separated by comma or whitespace

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

20200108 -- nexthop destinations separated by comma or whitespace

Ralf Hildebrandt-2
I don't see the change 20200108 reflected in the transport(5) man page.

While this isn't a problem per se, I have been using this form for
internal routing:

exchange.charite.de   exchange:s-mx14-ht01.charite.de,exchange:s-mx14-ht02.charite.de

to get rid of the pesky internal MX record for exchange.charite.de.

This worked until this morning 09:10:59 (I 've been using 20200112, I
upgraded now, though):

Jan 29 07:14:10 mail-cbf-int postfix/master[3584]: reload -- version 3.5-20200112, configuration /etc/postfix
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32685]: fatal: unknown service: s-mx14-ht02.charite.de/tcp
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32885]: fatal: unknown service: s-mx14-ht02.charite.de/tcp
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32884]: fatal: unknown service: s-mx14-ht02.charite.de/tcp
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32943]: fatal: unknown service: s-mx14-ht02.charite.de/tcp
Jan 29 09:10:59 mail-cbf-int postfix/smtp[33545]: fatal: unknown service: s-mx14-ht02.charite.de/tcp
Jan 29 09:10:59 mail-cbf-int postfix/smtp[33707]: fatal: unknown service: s-mx14-ht02.charite.de/tcp
Jan 29 09:12:00 mail-cbf-int postfix/smtp[34103]: fatal: unknown service: s-mx14-ht02.charite.de/tcp
Jan 29 09:12:48 mail-cbf-int postfix/master[3584]: reload -- version 3.5-20200112, configuration /etc/postfix

Interesting logs:

Jan 29 09:10:59 mail-cbf-int postfix/tlsproxy[33285]: DISCONNECT [10.32.37.105]:25
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32685]: 486x4x5kyfz20krL: lost connection with s-mx14-ht01.charite.de[10.32.37.105] while sending end of data -- message may be sent more than once
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32685]: fatal: unknown service: s-mx14-ht02.charite.de/tcp
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32885]: 486x4x5tWJz20kyZ: lost connection with s-mx14-ht01.charite.de[10.32.37.105] while sending end of data -- message may be sent more than once
Jan 29 09:10:59 mail-cbf-int postfix/tlsproxy[33285]: DISCONNECT [10.32.37.105]:25
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32885]: fatal: unknown service: s-mx14-ht02.charite.de/tcp
Jan 29 09:10:59 mail-cbf-int postfix/tlsproxy[33285]: DISCONNECT [10.32.37.105]:25
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32884]: 486x4y0nSFz20l2f: lost connection with s-mx14-ht01.charite.de[10.32.37.105] while sending end of data -- message may be sent more than once
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32884]: fatal: unknown service: s-mx14-ht02.charite.de/tcp

and later:

Jan 29 09:11:00 mail-cbf-int postfix/qmgr[2174]: warning: transport exchange failure -- see a previous warning/fatal/panic logfile record for the problem description
Jan 29 09:11:00 mail-cbf-int postfix/qmgr[2174]: warning: transport exchange failure -- see a previous warning/fatal/panic logfile record for the problem description
Jan 29 09:11:00 mail-cbf-int postfix/qmgr[2174]: warning: transport exchange failure -- see a previous warning/fatal/panic logfile record for the problem description
Jan 29 09:11:00 mail-cbf-int postfix/qmgr[2174]: warning: transport exchange failure -- see a previous warning/fatal/panic logfile record for the problem description

I checked that transport_maps has not been changed prior to the failure:

Jan 29 09:26:31 mail-cbf-int postfix/trivial-rewrite[46120]: table cdb:/etc/postfix/transport(0,lock|no_regsub|fold_fix|utf8_request) has changed -- restarting
Jan 29 09:27:11 mail-cbf-int postfix/trivial-rewrite[46273]: table cdb:/etc/postfix/transport(0,lock|no_regsub|fold_fix|utf8_request) has changed -- restarting
Jan 29 09:27:12 mail-cbf-int postfix/trivial-rewrite[46290]: table cdb:/etc/postfix/transport(0,lock|no_regsub|fold_fix|utf8_request) has changed -- restarting
Jan 29 09:28:12 mail-cbf-int postfix/trivial-rewrite[46471]: table cdb:/etc/postfix/transport(0,lock|no_regsub|fold_fix|utf8_request) has changed -- restarting
Jan 29 09:28:20 mail-cbf-int postfix/trivial-rewrite[46558]: table cdb:/etc/postfix/transport(0,lock|no_regsub|fold_fix|utf8_request) has changed -- restarting
Jan 29 09:36:58 mail-cbf-int postfix/trivial-rewrite[49739]: table cdb:/etc/postfix/transport(0,lock|no_regsub|fold_fix|utf8_request) has changed -- restarting
Jan 29 09:37:00 mail-cbf-int postfix/trivial-rewrite[46807]: table cdb:/etc/postfix/transport(0,lock|no_regsub|fold_fix|utf8_request) has changed -- restarting
Jan 29 09:37:04 mail-cbf-int postfix/trivial-rewrite[47049]: table cdb:/etc/postfix/transport(0,lock|no_regsub|fold_fix|utf8_request) has changed -- restarting
Jan 29 09:40:06 mail-cbf-int postfix/trivial-rewrite[51439]: table cdb:/etc/postfix/transport(0,lock|no_regsub|fold_fix|utf8_request) has changed -- restarting


--
[*] sys4 AG

https://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
Reply | Threaded
Open this post in threaded view
|

Re: 20200108 -- nexthop destinations separated by comma or whitespace

Viktor Dukhovni
On Wed, Jan 29, 2020 at 09:56:45AM +0100, Ralf Hildebrandt wrote:

> I don't see the change 20200108 reflected in the transport(5) man page.

The HISTORY file writeup was:

    20200108
   
           UI cleanup: SMTP (and LMTP) client support for a list of
           nexthop destinations separated by comma or whitespace. These
           will be tried in the specified order. The list form can be
           specified in relayhost, transport_maps, default_transport,
           and sender_dependent_default_transport_maps.  Examples:
           "relayhost = foo.example, bar.example", and "default_transport
           = smtp:foo.exmple, bar.example". Files: smtp/smtp.c,
           smtp/smtp_connect.c, trivial-rewrite/resolve.c, proto/transport,
           proto/postconf.proto, global/mail_params.c.

Which explains that the feature is a change in the SMTP/LMTP nexthop
syntax, NOT a change in the transport syntax.

> While this isn't a problem per se, I have been using this form for
> internal routing:
>
> exchange.charite.de   exchange:s-mx14-ht01.charite.de,exchange:s-mx14-ht02.charite.de

This looks wrong, it should be :

    exchange.charite.de   exchange:s-mx14-ht01.charite.de,s-mx14-ht02.charite.de

One "exchange" transport, multiple nexthop hosts.

> This worked until this morning 09:10:59 (I 've been using 20200112, I
> upgraded now, though):

Not sure why it worked, it wasn't supposed to. :-)

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: 20200108 -- nexthop destinations separated by comma or whitespace

Ralf Hildebrandt-2
* Viktor Dukhovni <[hidden email]>:

> > exchange.charite.de   exchange:s-mx14-ht01.charite.de,exchange:s-mx14-ht02.charite.de
>
> This looks wrong, it should be :
>
>     exchange.charite.de   exchange:s-mx14-ht01.charite.de,s-mx14-ht02.charite.de
>
> One "exchange" transport, multiple nexthop hosts.

Cool.
 
> Not sure why it worked, it wasn't supposed to. :-)

Maybe it always tried the first entry, and once the first machine was
unreachable (or failed, see the log snippet) it tried the second
machine - just to find a broken nexthop!

--
[*] sys4 AG

https://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
Reply | Threaded
Open this post in threaded view
|

Re: 20200108 -- nexthop destinations separated by comma or whitespace

Viktor Dukhovni
On Wed, Jan 29, 2020 at 10:52:02AM +0100, Ralf Hildebrandt wrote:

> > This looks wrong, it should be :
> >
> >     exchange.charite.de   exchange:s-mx14-ht01.charite.de,s-mx14-ht02.charite.de
> >
> > One "exchange" transport, multiple nexthop hosts.
>
> Cool.
>  
> > Not sure why it worked, it wasn't supposed to. :-)
>
> Maybe it always tried the first entry, and once the first machine was
> unreachable (or failed, see the log snippet) it tried the second
> machine - just to find a broken nexthop!

Yes.  The nexthop syntax is essentially:

    <name>[:<port>] ("," <name>[:<port>])*

So set a fallback relay of "exchange" on port "s-mx14-ht02.charite.de",
which presumably does not appear in your /etc/services file.

Mind you, if you have working MX records, I'd stick with those.
Especially if there's no reason to prefer "ht01" to "ht02".

--
    Viktor.