On Wed 26/Mar/2025 09:23:19 +0100 Wei Chuang wrote:
FORWARDED MESSAGE: From header rewritten and Delivered-to added
DKIM2-Signature: i=2; h=list-unsubscribe-post:delivered-to
From: list@mailinglist.example
Wasn't the purpose to keep the author's real address in the From: field?
Delivered-to
A terminology nit, but it's going to come up in the future so I'd like to
put it out there early before we have a big re-editing job to do:
On Wed, Mar 26, 2025 at 1:23 AM Wei Chuang wrote:
> This is a strawman description for the DKIM2 header signing. I know that
> Richard is writing a draft f
I should have mentioned that the example is a problematic scenario where
DKIM2 and in particular the ideas in
draft-gondwana-dkim2-modification-alegbra could make this scenario
tractable for authentication. The details of the modification algebra are
however out of scope for this particular exampl
On 3/26/25 11:02 AM, Murray S. Kucherawy wrote:
On Wed, Mar 26, 2025 at 9:31 AM Alessandro Vesely wrote:
It's a matter of MTA design. The closer the specification adheres
to SMTP, the
wider the implementation choices.
I think about this differently:
Right now, you could implemen
On Wed, Mar 26, 2025 at 9:31 AM Alessandro Vesely wrote:
> It's a matter of MTA design. The closer the specification adheres to SMTP,
> the
> wider the implementation choices.
>
I think about this differently:
Right now, you could implement STD 76 DKIM via a pipeline. The only thing
it needs a
On Wed, 26 Mar 2025, Murray S. Kucherawy wrote:
Requiring any part of the envelope, or knowledge of SMTP routing, is a
significant departure and means this simple "pipe the pure message"
interface can't work. You need something more complex; significantly, you
need the envelope, and you need to
On Wed 26/Mar/2025 16:13:23 +0100 John Levine wrote:
It appears that Wei Chuang said:
the "rt=" or in the RFC5322 address headers. Which of these is easier to
adopt by open source DKIM and SMTP packages? Might splitting all
recipients be a simple config already in those open source SMTP?
One more from me, in a rush (of course).
It
- fixes header sorting in the diff, it of course must honour
RFC 6376, section 5.4.2, and nothing else
- adds an explicit note for MTAs regarding recipient limits
- more on that (recipient limit announced via DNS RR)
- and adds a final note
- no p
It appears that Wei Chuang said:
>the "rt=" or in the RFC5322 address headers. Which of these is easier to
>adopt by open source DKIM and SMTP packages? Might splitting all
>recipients be a simple config already in those open source SMTP?
FWIW, in both Postfix and Exim, it's a one line config
On Wed, Mar 26, 2025 at 5:14 AM Jeremy Harris wrote:
>
> On 3/26/25 10:04 AM, Alessandro Vesely wrote:
> > AFAIK, most or all mailing lists send single messages, otherwise they
> > couldn't do VERP, but I'm not sure it's a universal rule.
>
> I am aware of some that send at least some of their ou
On 3/26/25 1:58 PM, Murray S. Kucherawy wrote:
On Wed, Mar 26, 2025 at 11:14 AM Michael Thomas wrote:
AKA "layering violation". That's on what is being proposed here,
not on SMTP. Made worse by constricting perfectly valid SMTP behavior.
...which isn't to say it shouldn't be done, but
On 3/26/25 11:13 AM, Alessandro Vesely wrote:
If you want to do forensics you can check more, but that's all that a
receiver is likely to care about.
It ought to be not very hard to check all signatures, reversing the
changes. There needs to be a way to tell what changes are tolerated.
For
On Wed, Mar 26, 2025 at 11:14 AM Michael Thomas wrote:
> AKA "layering violation". That's on what is being proposed here, not on
> SMTP. Made worse by constricting perfectly valid SMTP behavior.
>
...which isn't to say it shouldn't be done, but we have to acknowledge that
that's what we're doing,
On Wed, Mar 26, 2025 at 11:07 AM John R Levine wrote:
> That's true. Someone pointed out that you can't do DKIM2 as a milter
> since milters can't mess with the envelope and I doubt they can split a
> message into two copies.
>
Milters can see the envelope and even change it. But yes, they can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Alessandro
Vesely writes
>On Mon 24/Mar/2025 20:19:29 +0100 Richard Clayton wrote:
>> In message , Alessandro Vesely
> writes
>>
>>>BTW, is dkim2=fail different from "failing DKIM2 signatures from a 100%
>>>DKIM2
>>>mail chain"? I me
It appears that Michael Thomas said:
>Does anybody know if there is a precedent for a message/SMTP layering
>violation that limits what you can and can't do with SMTP?
There's Delivered-To: which has a version of the envelope recipient
and is used for loop breaking. If you see a message with a
On 3/26/25 12:09 PM, Richard Clayton wrote:
It's not a question of hardness -- if you check more signatures than you
need to then you are heating up the planet unnecessarily.
Can we please dispense with this pointless imagery? RSA verifies are
trivial and have been for 20 years. If you want
On 26/03/2025 09:18, Wei Chuang wrote:
On Tue, Mar 25, 2025 at 9:43 AM Wei Chuang wrote:
On Tue, Mar 25, 2025 at 3:06 AM Alessandro Vesely wrote:
On Mon 24/Mar/2025 20:49:32 +0100 Wei Chuang wrote:
To support that use case and other scenarios where the recipient is not
explicitly declared in
https://groups.google.com/ exists, but I'm not sure how it compares in
terms of scale to other providers. I can confirm that it does VERP, and as
a consequence of this delivers unique messages to all subscribers.
On Wed, Mar 26, 2025 at 6:13 AM Jeremy Harris wrote:
> On 3/26/25 10:04 AM, Alessan
On 3/26/25 10:04 AM, Alessandro Vesely wrote:
AFAIK, most or all mailing lists send single messages, otherwise they couldn't
do VERP, but I'm not sure it's a universal rule.
I am aware of some that send at least some of their output as
multiple-recipient messages. Given the prevalence of 800l
On Tue, Mar 25, 2025 at 9:43 AM Wei Chuang wrote:
>
>
> On Tue, Mar 25, 2025 at 3:06 AM Alessandro Vesely wrote:
>
>> On Mon 24/Mar/2025 20:49:32 +0100 Wei Chuang wrote:
>> > To support that use case and other scenarios where the recipient is not
>> > explicitly declared in the RFC5322 message e
This is a strawman description for the DKIM2 header signing. I know that
Richard is writing a draft for this, but as draft writing is heavyweight
and before going too deep down a particular path, I think there is benefit
to put some sort of concept out early for community feedback. In the
IETF-12
22 matches
Mail list logo
