dovecot - Apr 2021 - How to prevent, or change priority, of dovecot's FAILed relay-submission to relay's IPv6 address, and submit ONLY/first to IPv4?

On 4/9/21 8:08 AM, @lbutlr wrote:
> On 08 Apr 2021, at 06:08, PGNet Dev <pgnet.dev at 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.

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

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.

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.
> 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).
> 
>

Citeren PGNet Dev <pgnet.dev at gmail.com>:
> On 4/9/21 8:08 AM, @lbutlr wrote:
>> On 08 Apr 2021, at 06:08, PGNet Dev <pgnet.dev at 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 Friday, April 9, 2021 5:19:20 AM AKDT PGNet Dev
wrote:
> And it's a bad assumption that since the host is dual-stack that all
> services on it will be.
That's right. Email stuff that's supposed to work has to be crippled and
disabled somehow so that it does not actually work as it is supposed to.

There's a knob to tweak to break someone's mailbox for a party prank,
cut off
a service if it isn't immediately obvious how it's affecting someone
else's
work, or screw something else up so it can't or doesn't work reliably,
either.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20210409/d53c5a46/attachment.sig>