Re: Defining what the default welcomelist means

2024-04-14 Thread Bill Cole
I believe we are in solid agreement, a few notes below explaining how... On 2024-04-14 at 08:00:19 UTC-0400 (Sun, 14 Apr 2024 08:00:19 -0400) Greg Troxel is rumored to have said: > Bill Cole writes: > >> On 2024-04-12 at 18:56:15 UTC-0400 (Fri, 12 Apr 2024 18:56:15 -0400) >> Greg Troxel >>

Re: Defining what the default welcomelist means

2024-04-14 Thread Greg Troxel
Bill Cole writes: > On 2024-04-12 at 18:56:15 UTC-0400 (Fri, 12 Apr 2024 18:56:15 -0400) > Greg Troxel > >> Bill Cole writes: >> >>> 1. We serve our users: receivers, not senders. Senders claiming FPs >>> need the support of a corroborating would-be receiver. >> >> Agreed. Or maybe we take req

Re: Defining what the default welcomelist means

2024-04-13 Thread Benny Pedersen
Bill Cole skrev den 2024-04-13 19:42: score USER_IN_DEF_DKIM_WL -2 score USER_IN_DEF_SPF_WL -2 By default those each score -7.5 so a doubly-confirmed message gets the same insane -15 as a legacy listing (def_whitelist_from_rcvd) that doesn't require authentication. No such listings still exis

Re: Defining what the default welcomelist means

2024-04-13 Thread Bill Cole
On 2024-04-12 at 19:26:59 UTC-0400 (Fri, 12 Apr 2024 16:26:59 -0700) jdow is rumored to have said: > On 20240412 16:14:44, Greg Troxel wrote: >> jdow writes: >> >>> One pesky detail still exists. There is a very broad fuzzy area where >>> my spam is your ham and vice versa. You could probably dr

Re: Defining what the default welcomelist means

2024-04-13 Thread Bill Cole
On 2024-04-12 at 19:01:21 UTC-0400 (Fri, 12 Apr 2024 19:01:21 -0400) Greg Troxel is rumored to have said: > Also, I'm not sure you said this, but I would say: > >default whitelist is dkim only No. Existing practice is that we trust both DKIM and SPF, and I think that's fine. There are no u

Re: Defining what the default welcomelist means

2024-04-13 Thread Bill Cole
On 2024-04-12 at 18:56:15 UTC-0400 (Fri, 12 Apr 2024 18:56:15 -0400) Greg Troxel is rumored to have said: > I see it very slightly differently, but mostly agree > > Bill Cole writes: > >> 1. We serve our users: receivers, not senders. Senders claiming FPs >> need the support of a corroborating w

Re: Defining what the default welcomelist means

2024-04-12 Thread jdow
On 20240412 16:14:44, Greg Troxel wrote: jdow writes: One pesky detail still exists. There is a very broad fuzzy area where my spam is your ham and vice versa. You could probably drive yourself to an early grave trying to get the perfect Bayes training plus perfect rule set. spam is bulk and

Re: Defining what the default welcomelist means

2024-04-12 Thread Greg Troxel
jdow writes: > One pesky detail still exists. There is a very broad fuzzy area where > my spam is your ham and vice versa. You could probably drive yourself > to an early grave trying to get the perfect Bayes training plus > perfect rule set. spam is bulk and unsolicited. So yes the same messa

Re: Defining what the default welcomelist means

2024-04-12 Thread jdow
On 20240412 15:56:15, Greg Troxel wrote: I see it very slightly differently, but mostly agree Bill Cole writes: 1. We serve our users: receivers, not senders. Senders claiming FPs need the support of a corroborating would-be receiver. Agreed. Or maybe we take requests to add only from recei

Re: Defining what the default welcomelist means

2024-04-12 Thread Greg Troxel
Also, I'm not sure you said this, but I would say: default whitelist is dkim only This means All existing entries are converted to dkim as well as we can, not worrying if they break. We'll prune ones that don't work as dkim, and add a signing domain as we figure it out, as

Re: Defining what the default welcomelist means

2024-04-12 Thread Greg Troxel
I see it very slightly differently, but mostly agree Bill Cole writes: > 1. We serve our users: receivers, not senders. Senders claiming FPs > need the support of a corroborating would-be receiver. Agreed. Or maybe we take requests to add only from receivers. > 2. If senders have FPs on objec