Re: Relay based on either auth or cert?
On May 11, 2021 8:35 PM, Sean Kamath wrote:I was pondering a message Gille Chehade commented on (https://narkive.com/2puCGKoq.4) a very long time ago. He said: > The cert verification happens at the transport level, not the SMTP level > and an invalid certificate will cause TLS to abort and close connection. > > You can use this for example to have your local CA issue certificates to > a set of internal machines and have the mail gateway accept relaying for > these machines without authentication. > > You can also use this to ensure that users have a two-factor auth, their > credentials no longer are enough to relay, they would also have to use a > valid certificate issued by your CA. if their credentials are stolen, it > will not allow people to use the server as a spamming center. > > Or you could decide to authenticate users using certificates and not the > traditional user/password mechanism. A client will then have to show you > a valid certificate otherwise connection will drop at TLS negotiation. What I’m wondering is if there is a way to do both on the submission port (one of two factors, either being sufficient for relaying). In other words, accept mail on the submission port from either an authenticated user using a password, or verify they are using a certificate. I don’t want to require users using a password to use a cert, and I don’t want users using a cert be required to authenticate with a password. Is this possible? Sean You may be able to coax `auth-optional' to do what you want. Edgar
Re: smtpctl spf walk -6 ?
On Wed, 2021-05-12 at 15:45 +0200, Harald Dunkel wrote: > On 5/12/21 2:56 PM, Martijn van Duren wrote: > > Apparently it's a problem in glibc's inet_net_pton. It does not support > > AF_INET6. to.c has the same problem and works around this problem by > > handcrafting broken_inet_net_pton_ipv6(). > > > > Would it be possible to use inet_pton() ? > > > Regards > Harri > Nope, inet_pton doesn't support CIDR. broken_inet_net_pton_ipv6() uses inet_pton internally.
Re: smtpctl spf walk -6 ?
On 5/12/21 2:56 PM, Martijn van Duren wrote: Apparently it's a problem in glibc's inet_net_pton. It does not support AF_INET6. to.c has the same problem and works around this problem by handcrafting broken_inet_net_pton_ipv6(). Would it be possible to use inet_pton() ? Regards Harri
Re: smtpctl spf walk -6 ?
On Wed, 2021-05-12 at 13:33 +0200, Harald Dunkel wrote: > On 5/12/21 8:56 AM, nathanael wrote: > > > > this is what i get on my machine: > > > > ~ echo spf.protection.outlook.com | smtpctl spf walk > > 40.92.0.0/15 > > 40.107.0.0/16 > > 52.100.0.0/14 > > 104.47.0.0/17 > > 2a01:111:f400::/48 > > 2a01:111:f403::/48 > > 51.4.72.0/24 > > 51.5.72.0/24 > > 51.5.80.0/27 > > 20.47.149.138/32 > > 51.4.80.0/27 > > 2a01:4180:4051:0800::/64 > > 2a01:4180:4050:0800::/64 > > 2a01:4180:4051:0400::/64 > > 2a01:4180:4050:0400::/64 > > > > no idea why you don't see the ipv6 addresses > > > > On OpenBSD 6.8 and 6.9 I get the expected result, too. The problem > shows up on Debian 10 and Unstable (opensmtpd 6.8.0p2). > > Using strace I verified that smtpctl and dig connect to the same DNS > server. Yet dig reports the IPv6 addresses, smtptl spf walk doesn't. > Its unlikely that the DNS server drops the IPv6 addresses from a TXT > record, anyway. > > Maybe its a problem of the BSD compatibility layer, included in > the portable version? > > > Regards > Harri > Apparently it's a problem in glibc's inet_net_pton. It does not support AF_INET6. to.c has the same problem and works around this problem by handcrafting broken_inet_net_pton_ipv6(). Someone from -portable should probably copy this function over to spfwalk.c. martijn@
Re: smtpctl spf walk -6 ?
On 12.05.2021 14:33, Harald Dunkel wrote: On 5/12/21 8:56 AM, nathanael wrote: this is what i get on my machine: ~ echo spf.protection.outlook.com | smtpctl spf walk 40.92.0.0/15 40.107.0.0/16 52.100.0.0/14 104.47.0.0/17 2a01:111:f400::/48 2a01:111:f403::/48 51.4.72.0/24 51.5.72.0/24 51.5.80.0/27 20.47.149.138/32 51.4.80.0/27 2a01:4180:4051:0800::/64 2a01:4180:4050:0800::/64 2a01:4180:4051:0400::/64 2a01:4180:4050:0400::/64 no idea why you don't see the ipv6 addresses On OpenBSD 6.8 and 6.9 I get the expected result, too. The problem shows up on Debian 10 and Unstable (opensmtpd 6.8.0p2). Using strace I verified that smtpctl and dig connect to the same DNS server. Yet dig reports the IPv6 addresses, smtptl spf walk doesn't. Its unlikely that the DNS server drops the IPv6 addresses from a TXT record, anyway. Maybe its a problem of the BSD compatibility layer, included in the portable version? Regards Harri I see the same on CentOS 8 with 6.8p2: echo spf.protection.outlook.com | smtpctl spf walk 40.92.0.0/15 40.107.0.0/16 52.100.0.0/14 104.47.0.0/17 51.4.72.0/24 51.5.72.0/24 51.5.80.0/27 20.47.149.138/32 51.4.80.0/27 Good luck, Reio
Re: smtpctl spf walk -6 ?
On 5/12/21 8:56 AM, nathanael wrote: this is what i get on my machine: ~ echo spf.protection.outlook.com | smtpctl spf walk 40.92.0.0/15 40.107.0.0/16 52.100.0.0/14 104.47.0.0/17 2a01:111:f400::/48 2a01:111:f403::/48 51.4.72.0/24 51.5.72.0/24 51.5.80.0/27 20.47.149.138/32 51.4.80.0/27 2a01:4180:4051:0800::/64 2a01:4180:4050:0800::/64 2a01:4180:4051:0400::/64 2a01:4180:4050:0400::/64 no idea why you don't see the ipv6 addresses On OpenBSD 6.8 and 6.9 I get the expected result, too. The problem shows up on Debian 10 and Unstable (opensmtpd 6.8.0p2). Using strace I verified that smtpctl and dig connect to the same DNS server. Yet dig reports the IPv6 addresses, smtptl spf walk doesn't. Its unlikely that the DNS server drops the IPv6 addresses from a TXT record, anyway. Maybe its a problem of the BSD compatibility layer, included in the portable version? Regards Harri
Re: Relay based on either auth or cert?
On May 11, 2021 8:35 PM, Sean Kamath wrote:I was pondering a message Gille Chehade commented on (https://narkive.com/2puCGKoq.4) a very long time ago. He said: > The cert verification happens at the transport level, not the SMTP level > and an invalid certificate will cause TLS to abort and close connection. > > You can use this for example to have your local CA issue certificates to > a set of internal machines and have the mail gateway accept relaying for > these machines without authentication. > > You can also use this to ensure that users have a two-factor auth, their > credentials no longer are enough to relay, they would also have to use a > valid certificate issued by your CA. if their credentials are stolen, it > will not allow people to use the server as a spamming center. > > Or you could decide to authenticate users using certificates and not the > traditional user/password mechanism. A client will then have to show you > a valid certificate otherwise connection will drop at TLS negotiation. What I’m wondering is if there is a way to do both on the submission port (one of two factors, either being sufficient for relaying). In other words, accept mail on the submission port from either an authenticated user using a password, or verify they are using a certificate. I don’t want to require users using a password to use a cert, and I don’t want users using a cert be required to authenticate with a password. Is this possible? Sean You could have separate listen directives on separate ports. Of course the users would have to set up their clients correctly. Edgar