On Wed 14/Sep/2022 06:35:50 +0200 Stephen J. Turnbull wrote:
I still think you're going to get pushback on the requirements
language, but the analysis is complete and accurate.
That sounds good to me. I've posted the new draft version[*]. As all drafts,
it is still open to discussions.
Alessandro Vesely writes:
> It would also be possible to link DB tables,
No, it's not. It's all one row (IIRC).
> or to define triggers that replicate insert/ update/ delete on a
> number of tables/ fields.
Which is exactly the complexity I don't want in Mailman if we can
avoid it. Keep
On Tue 13/Sep/2022 10:14:12 +0200 Stephen J. Turnbull wrote:
Alessandro Vesely writes:
Maintaining synchronization of configurations of two lists will be tedious
for the admin, or involve relatively complicated coding if we arrange to
automatically mirror configuration changes.
Couldn't
First let me make clear that (1) I do have influence on Mailman's
position here but (2) I am not authoritative and (3) Mailman has no
position yet. I'm discussing this and that and we'll see where my
position and eventually Mailman's come out. So anything I say may be
wrong (always check my
Hi Steve,
thanks for your precious insights.
Some comments inline and a new version:
On Sat 10/Sep/2022 10:41:21 +0200 Stephen J. Turnbull wrote:
Alessandro Vesely writes:
3. The ARC method
This twin-list proposal doesn't depend specifically on ARC.
Right.
For each list with
Alessandro Vesely writes:
> Internet-Draft MLM TransformationsSeptember 2022
>
>
> 3. The ARC method
This twin-list proposal doesn't depend specifically on ARC. Any
subscriber who thinks they know better than the DMARC protocol can
choose to ignore the DMARC
On Tue 06/Sep/2022 15:28:10 +0200 Stephen J. Turnbull wrote:
At worst, one could set up two lists, fed by the same stream, one
with munging enabled and the other not, letting users subscribe to
the one they prefer.
To be honest, while I'm at best 50% willing to implement the user
option, I
Alessandro Vesely writes:
> The tale goes that large mailbox providers want ARC as a tool to
> filter mail streams from lists that don't do a good filtering
> themselves. ARC, they say, allows to attribute reputation
> correctly. However, I don't think they can tell who a message is
>
On Tue 06/Sep/2022 06:41:36 +0200 Stephen J. Turnbull wrote:
Alessandro Vesely writes:
On Sun 04/Sep/2022 13:38:39 +0200 Stephen J. Turnbull wrote:
I asked bind-users if anyone verifying ARC saw any difference after
trusting isc.org. Besides adding ARC sets, bind-users do From: munging,
Alessandro Vesely writes:
> On Sun 04/Sep/2022 13:38:39 +0200 Stephen J. Turnbull wrote:
> > Not sure what you mean by "sealing". Do you mean they're not
> > implementing the rest of the protocol?
>
> They add a complete ARC set. Actually, they add three ARC sets to each
> message, one
Hi Steve!
On Sun 04/Sep/2022 13:38:39 +0200 Stephen J. Turnbull wrote:
Alessandro Vesely writes:
There is a thread about ARC sealing in bind-users[*].
Not sure what you mean by "sealing". Do you mean they're not
implementing the rest of the protocol?
They add a complete ARC set.
11 matches
Mail list logo
