Re: Relay based on either auth or cert?

2021-05-12 Thread Edgar Pettijohn
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 ?

2021-05-12 Thread Martijn van Duren
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 ?

2021-05-12 Thread Harald Dunkel

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 ?

2021-05-12 Thread Martijn van Duren
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 ?

2021-05-12 Thread Reio Remma

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 ?

2021-05-12 Thread Harald Dunkel

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?

2021-05-12 Thread Edgar Pettijohn
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 

Re: smtpctl spf walk -6 ?

2021-05-12 Thread nathanael
Harald Dunkel  wrote:
> Hi folks,
> 
> I am a big fan of IPv6, so I wonder why smtpctl spf walk omits
> all the IPv6 addresses?
> 
>   # 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
> 
>   # dig spf.protection.outlook.com TXT +short | tr \  \\n
>   "v=spf1
>   ip4:40.92.0.0/15
>   ip4:40.107.0.0/16
>   ip4:52.100.0.0/14
>   ip4:104.47.0.0/17
>   ip6:2a01:111:f400::/48
>   ip6:2a01:111:f403::/48
>   include:spfd.protection.outlook.com
>   -all"
> 
>   # echo spf.protection.outlook.com | smtpctl spf walk -6
>   invalid command
> 
> 
> Regards
> Harri

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



smtpctl spf walk -6 ?

2021-05-12 Thread Harald Dunkel

Hi folks,

I am a big fan of IPv6, so I wonder why smtpctl spf walk omits
all the IPv6 addresses?

# 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

# dig spf.protection.outlook.com TXT +short | tr \  \\n
"v=spf1
ip4:40.92.0.0/15
ip4:40.107.0.0/16
ip4:52.100.0.0/14
ip4:104.47.0.0/17
ip6:2a01:111:f400::/48
ip6:2a01:111:f403::/48
include:spfd.protection.outlook.com
-all"

# echo spf.protection.outlook.com | smtpctl spf walk -6
invalid command


Regards
Harri