One has to ask why it has AAAA record in DNS if you don't intend to use it?

Aki

On 08/04/2021 14:45 PGNet Dev pgnet.dev@gmail.com wrote:

How do you turn OFF, or reduce priority of, IPv6 connect attempts by submission relay?

On 4/3/21 8:03 PM, PGNet Dev wrote:

...

my server is a linux, dual-stack IPv4/IPv6 host

it runs multiple services, including, but not limited to, postfix & dovecot

the hostname is

    internal.mx.example.com

its DNS config,

    host internal.mx.example.com internal.mx.example.com has address 10.1.1.15 internal.mx.example.com has IPv6 address fd80:10:1::15 internal.mx.example.com mail is handled by 5 internal.mx.example.com.

here, for dovecot

    dovecot --version 2.3.13 (89f716dc2)

submission is configured to relay to the same-host postfix instance, listening @ port 465

    ./conf.d/10-master.conf ... protocols = imap submission lmtp sieve ... submission_relay_host       = internal.mx.example.com submission_relay_port       = 465 submission_relay_ssl        = smtps submission_relay_ssl_verify = yes submission_relay_trusted    = yes

whereas other services listen at both IPv4 & IPv6 addresses, with IPv6 preferred over IPv4, postfix listens ONLY on IPv4,

    postconf inet_protocols inet_protocols = ipv4

and, as intended, simply refuses ipv6 connections

    telnet 10.1.1.15 465 Trying 10.1.1.15... Connected to 10.1.1.15. Escape character is '^]'. ^] telnet> quit Connection closed.

    telnet -6 fd80:10:1::15 465 Trying fd80:10:1::15... telnet: connect to address fd80:10:1::15: Connection refused

on each/every mail submit -- via dovecot -- dovecot makes the connection

    2021-04-03 19:35:35 submission(mailer@mx.example.com): Debug: smtp-server: conn 10.1.2.163:35388 [1]: Server accepted connection (fd=7) 2021-04-03 19:35:35 submission(mailer@mx.example.com): Debug: smtp-server: conn 10.1.2.163:35388 [1]: Connection created 2021-04-03 19:35:35 submission(mailer@mx.example.com): Debug: smtp-client: conn internal.mx.example.com:465 [1]: Connection created 2021-04-03 19:35:35 submission(mailer@mx.example.com): Debug: smtp-client: conn internal.mx.example.com:465 [1]: Disconnected

looks up IP address

    2021-04-03 19:35:35 submission(mailer@mx.example.com): Debug: smtp-client: conn internal.mx.example.com:465 [1]: Looking up IP address 2021-04-03 19:35:35 submission(mailer@mx.example.com): Debug: smtp-client: conn internal.mx.example.com:465 [1]: Performing asynchronous DNS lookup 2021-04-03 19:35:35 submission(mailer@mx.example.com): Debug: smtp-server: conn 10.1.2.163:35388 [1]: Sent: 235 2.7.0 Logged in.

finds BOTH IPs -- IPv4 & IPv6

    2021-04-03 19:35:35 submission(mailer@mx.example.com): Debug: smtp-client: conn internal.mx.example.com:465 [1]: DNS lookup successful; got 2 IPs

then first tries to connect via the host's IPv6 address,

    2021-04-03 19:35:35 submission(mailer@mx.example.com): Debug: smtp-client: conn internal.mx.example.com:465 [1]: Connecting to fd80:10:1::15:465 2021-04-03 19:35:35 submission(mailer@mx.example.com): Debug: smtp-client: conn internal.mx.example.com:465 ([fd80:10:1::15]:465) [1]: Connecting 2021-04-03 19:35:35 submission(mailer@mx.example.com): Debug: smtp-client: conn internal.mx.example.com:465 ([fd80:10:1::15]:465) [1]: Waiting for connect (fd=8) to finish for max 0 msecs

############ FAILS ############

    2021-04-03 19:35:35 submission(mailer@mx.example.com): Debug: smtp-client: conn internal.mx.example.com:465 ([fd80:10:1::15]:465) [1]: Client connection failed (fd=8)

then proceeds to connect to the host's IPv4 address

    2021-04-03 19:35:35 submission(mailer@mx.example.com): Debug: smtp-client: conn internal.mx.example.com:465 ([fd80:10:1::15]:465) [1]: Connecting to 10.1.1.15:465 2021-04-03 19:35:35 submission(mailer@mx.example.com): Debug: smtp-client: conn internal.mx.example.com:465 (10.1.1.15:465) [1]: Connecting 2021-04-03 19:35:35 submission(mailer@mx.example.com): Debug: smtp-client: conn internal.mx.example.com:465 (10.1.1.15:465) [1]: Waiting for connect (fd=11) to finish for max 0 msecs 2021-04-03 19:35:35 submission(mailer@mx.example.com): Debug: smtp-client: conn internal.mx.example.com:465 (10.1.1.15:465) [1]: Client connected (fd=11) 2021-04-03 19:35:35 submission(mailer@mx.example.com): Debug: smtp-client: conn internal.mx.example.com:465 (10.1.1.15:465) [1]: Connected to server (from 10.1.1.15:52880) 2021-04-03 19:35:35 submission(mailer@mx.example.com): Debug: smtp-client: conn internal.mx.example.com:465 (10.1.1.15:465) [1]: Starting SSL handshake 2021-04-03 19:35:35 submission(mailer@mx.example.com): Debug: smtp-client: conn internal.mx.example.com:465 (10.1.1.15:465) [1]: SSL handshake successful ...

and submission continues/completes

I need to get Dovecot to stop trying/failing @ those IPv6 address submission connections.

Either by

    (1) trying IPv4 *first*, before IPv6, to avoid the FAIL on submission

or

    (2) turning off submission relay by IPv6 altogether, as I'll never use it

What's the config required to do either/both?

On 08 Apr 2021, at 06:08, PGNet Dev pgnet.dev@gmail.com wrote:

whereas other services listen at both IPv4 & IPv6 addresses, with IPv6 preferred over IPv4, postfix listens ONLY on IPv4,

Do you mean that YOUR postfix only listens to ipv4? If so, wouldn't the solution be to setup postfix to listen to ipv6?

Postfix added support for IPv6 back in version 2 days.

inet_protocols = ipv4, ipv6

or

inet_protocols = all

(My ISP does not provide IPv6, so I have little experience with it, so entirely possible I am missing something here).

-- Eliot: Jesus. Alice has gone full Harry Potter part seven/eight over there. Margo: God, I hope we're winning.

Citeren PGNet Dev pgnet.dev@gmail.com:

On 4/9/21 8:08 AM, @lbutlr wrote:

...

On 08 Apr 2021, at 06:08, PGNet Dev pgnet.dev@gmail.com wrote:

...

whereas other services listen at both IPv4 & IPv6 addresses, with
IPv6 preferred over IPv4, postfix listens ONLY on IPv4,

Do you mean that YOUR postfix only listens to ipv4?

Yep.

...

If so, wouldn't the solution be to setup postfix to listen to ipv6?

That would work, of course, but that's not the point. I'm not
planning to open postfix listener on the public IPv6 in order to
accommodate one service connection (Dovecot's relay submit), only to
have to add add'l knobs to lock down access.

There is no need to use a global address, assuming the systems Postfix
and Dovecot are on the same LAN, a link-local IPv6 address would be
just fine. This is no less insecure than a RFC1918 IPv4 address.

And it's a bad assumption that since the host is dual-stack that all
services on it will be.

I fail to see why. If a hostname resolves to both an A and AAAA
record, it should provides services on both.

The 'solution' is to have Dovecot relay submit connect where & how
you TELL it to connect, NOT where it assumes it's OK to connect.

You've already told it where to connect: internal.mx.example.com.
Since that host has both an A and AAAA record, you're telling it both
are equally fine. If that's not what you want, either hardcode the
IPv4 address in the submission_relay_host or create an
internal-ipv4.mx.example.com A record.

It's already possible to set

submission_relay_host = submission_relay_port = submission_relay_ssl = submission_relay_ssl_verify = submission_relay_trusted =

in order to specify exactly how/where to securely connect for relay.

It's a head scratcher what the philosophical reticence is for
completing the picture with a

submission_relay_inet_protocols

or somesuch.

It's a head scratcher why people still insist on running services on
legacy IPv4 only.

On 09 Apr 2021, at 08:29, PGNet Dev pgnet.dev@gmail.com wrote:

...

...

And it's a bad assumption that since the host is dual-stack that all services on it will be. If a hostname resolves to both an A and AAAA record, it should provides services on both.

Says who/what?

There is no should/must/shall in any internet standard that suggest/implies/requires that.

It's blatantly obnvisou because otherwise you have to try to figure out if www.example.com:587 is on the A or the AAAA record, which is pretty much he opposite of how multiple records work.

If you had a DNS that returned multiple IPs got ;old balancing, would it be rational to have only SOME of those IPs respond on port 587 and others respond only on port 465 or 8955?

Of course not.

If you have to mandate ipv4, use the ipv4 address.

-- I desire the things that will destroy me in the end.

On Fri, Apr 09, 2021 at 01:15:27PM -0400, PGNet Dev wrote:

There's no sound reason -- technical or otherwise -- of not providing perfectly legitimate infrastructure-config choices to the admin, and an option to override default behaviors. Especially when the override is of defaults that are questionable, internally-made assumptions in the 1st place.

There most certainly is a sound reason, which is that it is code that would need to be written and maintained in order to solve a problem that is at least arguably user error. If the admin specifies a name rather than an IP address, and that name resolves to multiple addresses (whether they be different families of address is irrelevant), then the software is entirely correct in deciding to use any of those addresses in whatever order it wants. If you want to route around the DNS because of breakage in your local configuration, use a specific address or create a name that contains only the addresses you want. It is unreasonable instead to impose a burden of maintenance on the dovecot developers, or the penalty of poorly-exercised code (since this is, frankly, a corner case) on all the users.

Regards,

A

Andrew Sullivan ajs@crankycanuck.ca

On 09 Apr 2021, at 13:06, PGNet Dev pgnet.dev@gmail.com wrote:

...

then the software is entirely correct in deciding to use any of those addresses in whatever order it wants.

Complete and utter malarkey.

Ah, well, I suggest you write your own patch and implement it then, since you have no interest in any explanations at all having already made up your mind. You din't come here for help or information, you came to argue.

You have the code, do as you will.

-- "Are you pondering what I'm pondering?" "I think so, Brain. But suppose we do the hokey pokey and turn ourselves around, is that what it's really all about?"

On 09 Apr 2021, at 07:57, Arjen de Korte build+dovecot@de-korte.org wrote:

Citeren PGNet Dev pgnet.dev@gmail.com:

...

And it's a bad assumption that since the host is dual-stack that all services on it will be. I fail to see why. If a hostname resolves to both an A and AAAA record, it should provides services on both.

Yes, that would be my stance on it.

...

The 'solution' is to have Dovecot relay submit connect where & how you TELL it to connect, NOT where it assumes it's OK to connect.

You've already told it where to connect: internal.mx.example.com. Since that host has both an A and AAAA record, you're telling it both are equally fine. If that's not what you want, either hardcode the IPv4 address in the submission_relay_host or create an internal-ipv4.mx.example.com A record.

Right. The tools are already there, there is no need for dovecot to add another specific setting for this edge case when it is entirely unnecessary.

It's a head scratcher why people still insist on running services on legacy IPv4 only.

Some of us have no choice, sadly. Two of the largest ISPs (Comcast and Century Link) in the US refuse to offer IPv6 to business customers, and have gone to some lengths to screw up IPv6 for their consumer customers.

-- Alice: If you would just shut up for about for two seconds, this sex dream would pass the Bechdel test.