Tertiary MX never used

[mickaeltorres]

On OpenSMTPD 6.0.2p1 on debian jessie, when having a tertiary MX as follow:

toto.com. 60 IN MX 10 mx01.toto.com.
toto.com. 60 IN MX 20 mx02.toto.com.
toto.com. 60 IN MX 30 mx03.toto.com.

If mx01.toto.com and mx02.toto.com are both down, it seems that mx03.toto.com is never tried.
The route for mx01.toto.com is only disabled for 15s when a timeout occurs and the connect timeout is ~2min by default on this debian.
So mx01 times out, is disabled for 15secs, mx02 is tried, 15 seconds pass, mx01 is re-enabled, only then mx02 times out, so it re-tries mx01, and so on.
mx03 is never tried.

[SjonHortensius]

I can confirm this issue; we're having the same problem

[poolpOrg]

For the record, I asked @mickaeltorres to open a ticket but explained IRL that this ticket is meant to make sure that the MTA layer rewrite will account for this.

[zoot]

I'm curious as to why this issue hasn't been tackled already? It's critical for production deployments.

Please consider moving this to Milestone 6.7.0, or is this implicit, since the MTA layer rewrite seemed to have been targeted for 6.7.0 too?

[poolpOrg]

Why this hasn't been tackled already ?

There are very few people contributing code and none have shown interest in this issue. I personally don't work full-time on this project so I will spend the hours I have on tasks that generate the most noise or that annoy me the most. This issue is FAR from being the one that has annoyed the most users and, while it needs to be fixed, it was/is not in the top priorities.

It is not going to be fixed in 6.7.0 because @ericfaurot was not available to work on the MTA rewrite and I didn't have time to work on it by myself while also working on other time consuming tasks during my spare time.

It will be worked on but unless there's a sponsored development to buy developer time, this is going to be done on a volunteer basis and will depend on developer priorities.

[zoot]

Ok, thanks; that makes perfect sense.

I don't mean to pressurise unnecessarily. I'm sorry. I fully appreciate yours and the other developers' work here, thank you.

My eagerness is due to a serious interest in the project and would love to justify more testing time of OpenSMTPD as a replacement for my current production infrastructure.

I'll keep a beady eye on progressive development ...