> On 30 Jan 2025, at 21:39, Jeremy Harris wrote:
>
> On 30/01/2025 21:19, Michael Thomas wrote:
>>> I’m a little unclear on the need to fully describe the “mutation” that
>>> might be applied by an intermediary. Even if fully described, you need to
>>> have some trust of the intermediary to a
On 1/31/2025 9:38 AM, John R Levine wrote:
I'm equallly looking forward to a description of all the experience
with the Author header. Sheesh.
Thanks for engaging in discussion of substance, rather than choosing to
dive into an attack an alternative proposal. Very professional.
d/
--
Dav
p.s. glad to hear you have done some local testing of an unmunger. No doubt
this has been well-documented publicly and is familiar to the rest of the
community. I'm sure the experience will provide useful input to the public
discussion that will eventually start, about this new technology. S
Dave Crocker wrote in
:
...
|In a discussion about creating a complex, untested technology, to be
|used at scale, asking about whether a far simpler approach that is
In how far is it complex, actually?
File differences is at the core of for example git(1), and i do
not mention all the other
It appears that Dave Crocker said:
>-=-=-=-=-=-
>
>On 1/30/2025 1:39 PM, Jeremy Harris wrote:
>> One useful thing from being able to recover the message as it arrived
>> at a mailing-list manager: An MUA displaying the message could
>> display the original From: header - undoing some of the damag
On 1/30/2025 1:39 PM, Jeremy Harris wrote:
One useful thing from being able to recover the message as it arrived
at a mailing-list manager: An MUA displaying the message could
display the original From: header - undoing some of the damage that
(IMHO) dkim/dmarc has perpetrated in forcing MLMs to
On 1/31/2025 7:58 AM, John Levine wrote:
Has anyone ever implemented it? I've never heard of anyone doing so.
On the other hand, I've done From header unmungers that know about the
particular
munges that some lists do, and would like it if there were a more general way
to do that.
In a disc
Michael Thomas wrote in
<4af22ea9-b533-497b-bd14-d37b46a61...@mtcc.com>:
|On 1/30/25 5:00 PM, Murray S. Kucherawy wrote:
|> On Thu, Jan 30, 2025 at 1:34 PM Michael Thomas wrote:
|>> But I'm content to leave that discussion to the WG rather than
|>> the charter.
|>>
|> I do think
It appears that Dave Crocker said:
>-=-=-=-=-=-
>
>On 1/31/2025 7:58 AM, John Levine wrote:
>> Has anyone ever implemented it? I've never heard of anyone doing so.
>>
>> On the other hand, I've done From header unmungers that know about the
>> particular
>> munges that some lists do, and would
John Levine wrote in
<20250131155823.b9661bab1...@ary.qy>:
|It appears that Dave Crocker said:
|>On 1/30/2025 1:39 PM, Jeremy Harris wrote:
|>> One useful thing from being able to recover the message as it arrived
|>> at a mailing-list manager: An MUA displaying the message could
|>> displa
On 1/31/2025 10:31 AM, John Levine wrote:
More to the point, the whole point of making mutations reversible is so that
recipient systems can recover the original signed message and intermediates
can leave the From header alone, only making changes that they consider
useful, like subject line tags
On Fri, 31 Jan 2025, Dave Crocker wrote:
But again, my original point on this sub-trhead is that Author: is trivial,
not fragile, and based on constructs that have been used in email from its
start. It does not address the larger problem, but it does address From
field munging.
Can you tell
On 1/31/2025 7:39 PM, John R Levine wrote:
Can you tell us about MTAs and MUAs that have implemented it? I'm not
aware of any. The RFC was published four years ago
So, John, back to this?
Is there some reason you are so insistent on conducting a design
discussion with a focus on something
Dave Crocker wrote in
:
|On 1/31/2025 10:31 AM, John Levine wrote:
|> More to the point, the whole point of making mutations reversible \
|> is so that
|> recipient systems can recover the original signed message and intermedia\
|> tes
|> can leave the From header alone, only making changes
Review of:
ID: https://www.ietf.org/id/draft-gondwana-dkim2-motivation-01.html
DKIM2 Why DKIM needs replacing, and what a replacement would look like
draft-gondwana-dkim2-motivation-01
While the draft might have started with a direction that matches the
title, it is no
15 matches
Mail list logo
