> On Nov 29, 2022, at 8:25 PM, Jim Fenton wrote:
>
>
> On 29 Nov 2022, at 18:54, Neil Anuskiewicz wrote:
>
> Unless I’m misunderstanding you’re saying those with an enforcing DMARC
> policy can’t successfully send to mailing lists. I’m doing it now so I don’t
> think DMARC has to stay
On 12/7/22 4:26 PM, Murray S. Kucherawy wrote:
Fair enough. Does the charter need to say that a revision to best
practices, relative to the replay problem, might be a possible
output? It's within the realm of possibility that no protocol work
comes out of this, but a "checkpoint" about
On 12/7/2022 4:26 PM, Murray S. Kucherawy wrote:
Fair enough. Does the charter need to say that a revision to best
practices, relative to the replay problem, might be a possible
output? It's within the realm of possibility that no protocol work
comes out of this, but a "checkpoint" about
On December 8, 2022 12:26:45 AM UTC, "Murray S. Kucherawy"
wrote:
>On Wed, Dec 7, 2022 at 2:06 PM Dave Crocker wrote:
>
>> As appealing as the AS concept is, I've never been clear how operationally
>> useful they are.
>>
>> More to the current point, if the anti-replay work to be done
On Wed, Dec 7, 2022 at 2:06 PM Dave Crocker wrote:
> As appealing as the AS concept is, I've never been clear how operationally
> useful they are.
>
> More to the current point, if the anti-replay work to be done benefits
> from a position on transit vs. non-transit, then including it directly
On 12/7/2022 1:47 PM, Murray S. Kucherawy wrote:
Yes, it's definitely true that the standard was written from the
perspective of delivery-time evaluation, and then sending that result
to MUAs rather than having MUAs actually do the evaluation. So
although 4686 says that's a design goal, 6376
On 12/7/22 1:47 PM, Murray S. Kucherawy wrote:
Yes, it's definitely true that the standard was written from the
perspective of delivery-time evaluation, and then sending that result
to MUAs rather than having MUAs actually do the evaluation. So
although 4686 says that's a design goal,
On Tue, Dec 6, 2022 at 4:20 PM Dave Crocker wrote:
> DKIM was developed to facilitate delivery handling decisions. The
> language in the RFC 4871 and RFC 6376 doesn't make this as explicit as I'd
> wish, given the perspective I'm advocating, but it's got some implicating
> language. References
On 12/7/22 1:59 AM, Alessandro Vesely wrote:
That should be the only deliverable from the wg along with an
evaluation of whether the problem is tractable. If it is tractable,
the wg should recharter with a plan of how to implement it.
Murray said it goes without saying that WGs can fail.
> On 7 Dec 2022, at 17:16, Barry Leiba wrote:
>
>> The purpose of a DKIM signature is, as our original statement put it, to
>> make sure that a message from your
>> bank actually came from your bank, even if it passed through your alumni
>> association. Once it arrives to your
>> real
On 12/7/22 9:16 AM, Barry Leiba wrote:
The purpose of a DKIM signature is, as our original statement put it, to make
sure that a message from your
bank actually came from your bank, even if it passed through your alumni
association. Once it arrives to your
real mailbox, that signature is not
> The purpose of a DKIM signature is, as our original statement put it, to make
> sure that a message from your
> bank actually came from your bank, even if it passed through your alumni
> association. Once it arrives to your
> real mailbox, that signature is not needed.
As long as the
On 12/7/22 2:59 AM, Alessandro Vesely wrote:
ARC is a good forwarding tool.
I question the veracity of that. Mostly around -- what I consider to be
-- the priming problem of getting a receiving system to trust an
upstream system's ARC signature.
Its semantic differs from DKIM as it
On Tue 06/Dec/2022 22:52:33 +0100 Michael Thomas wrote:
I think that any charter should specifically call out the need for a
problem statement. The problem is far more nuanced than the few lines in
the proposed charter and I think that the charter should be neutral about
whether the problem
14 matches
Mail list logo
