On Wed, 23 Apr 2025, Alessandro Vesely wrote:
> On Tue 22/Apr/2025 17:17:34 +0200 Murray S. Kucherawy wrote:
> > On Tue, Apr 22, 2025 at 11:12 AM Alessandro Vesely wrote:
> >> On Tue 22/Apr/2025 16:49:29 +0200 Murray S. Kucherawy wrote:
> >>> On Tue, Apr 22, 2025 at 4:56 AM Alessandro Vesely wrot
On Tue 22/Apr/2025 17:17:34 +0200 Murray S. Kucherawy wrote:
On Tue, Apr 22, 2025 at 11:12 AM Alessandro Vesely wrote:
On Tue 22/Apr/2025 16:49:29 +0200 Murray S. Kucherawy wrote:
On Tue, Apr 22, 2025 at 4:56 AM Alessandro Vesely wrote:
On Tue 15/Apr/2025 21:21:58 +0200 Bron Gondwana wrote:
On Tue, Apr 22, 2025 at 11:12 AM Alessandro Vesely wrote:
> On Tue 22/Apr/2025 16:49:29 +0200 Murray S. Kucherawy wrote:
> > On Tue, Apr 22, 2025 at 4:56 AM Alessandro Vesely
> wrote:
> >> On Tue 15/Apr/2025 21:21:58 +0200 Bron Gondwana wrote:
> >
> >>> So I'm very interested in a discussion of
On Tue 22/Apr/2025 16:49:29 +0200 Murray S. Kucherawy wrote:
On Tue, Apr 22, 2025 at 4:56 AM Alessandro Vesely wrote:
On Tue 15/Apr/2025 21:21:58 +0200 Bron Gondwana wrote:
So I'm very interested in a discussion of *"should we have an exclude-list
rather than an include-list of signed header
On Tue, Apr 22, 2025 at 4:56 AM Alessandro Vesely wrote:
> On Tue 15/Apr/2025 21:21:58 +0200 Bron Gondwana wrote:
> > So I'm very interested in a discussion of *"should we have an
> exclude-list
> > rather than an include-list of signed headers?"*
>
> Don't sign MIME-Version: especially if it has
On Tue 15/Apr/2025 21:21:58 +0200 Bron Gondwana wrote:
So I'm very interested in a discussion of *"should we have an exclude-list
rather than an include-list of signed headers?"*
Don't sign MIME-Version: especially if it has comments.
Best
Ale
--
Francesco,
I stand corrected. I *do* see the Bcc with GMail, but not with
sendmail. I don't know what other systems are doing.
Eliot
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
__
On 4/21/2025 5:27 PM, Francesco Gennai wrote:
It is slightly off-topic, but it's interesting to me too.
In this case it is probable that the android app sends a separate copy
of the email for each BCC address (with the related BCC header).
I tested Gmail as an SMTP client for message submission a
On Mon, Apr 21, 2025 at 5:16 PM Allen Robinson
wrote:
>
>
>
> On Sun, Apr 20, 2025, 6:02 a.m. Dave Crocker wrote:
>>
>> On 4/20/2025 11:02 AM, Eliot Lear wrote:
>>
>> What system actually does this? Following the first method in Section 3.6.3
>> of RFC 5322 and a practice that goes as far back
On Sun, Apr 20, 2025, 6:02 a.m. Dave Crocker wrote:
> On 4/20/2025 11:02 AM, Eliot Lear wrote:
>
> What system actually does this? Following the first method in Section
> 3.6.3 of RFC 5322 and a practice that goes as far back as RFC 822, Neither
> Sendmail nor GMail, for instance, retain the BCC
On 4/20/2025 11:02 AM, Eliot Lear wrote:
What system actually does this? Following the first method in Section
3.6.3 of RFC 5322 and a practice that goes as far back as RFC 822,
Neither Sendmail nor GMail, for instance, retain the BCC field in the
message. Is this a matter of tracing how a me
Hang on a second:
On 20.04.2025 09:49, Dave Crocker wrote:
It is important to /retain/ the BCC field, for display to the
recipient, since it is the only way the recipient can tell why they
got the message. (and probably that they should not do a reply all.)
What system actually does this? F
On 4/16/2025 5:54 PM, Murray S. Kucherawy wrote:
On Sun, Apr 13, 2025 at 11:56 AM Richard Clayton
wrote:
>Bcc header field? Doesn’t that contradict the “blank” carbon copy?
I think "B" means "Blind".
Yup.
I would argue that any value in signing the field is defeated by the
fact that
On 4/16/2025 9:22 AM, Wei Chuang wrote:
I suspect the include-list approach will likely ignore X- headers,
while exclude-list will by default include signing all of them. The
latter will be more sensitive to the rumored MTAs that delete
arbitrary X- headers that will need help from the header a
Murray S. Kucherawy wrote in
:
|On Thu, Apr 17, 2025 at 2:47 PM Steffen Nurpmeso \
|wrote:
|
|> This only survives because DKIM specifies ~"one successful
|> verification is enough". It is a shame given that other
|> mailing-lists ensure the original==broken signature is removed or
|> ren
Steffen Nurpmeso wrote in
<20250416174856.ASXeYj5H@steffen%sdaoden.eu>:
|John Levine wrote in
| <20250416172847.8886ec4e0...@ary.qy>:
...
||We could except that the Resent-xx headers are not trace headers, even \
||though
||anything you might say about trace headers applies to them, too.
||
On Thu, Apr 17, 2025 at 2:47 PM Steffen Nurpmeso wrote:
> This only survives because DKIM specifies ~"one successful
> verification is enough". It is a shame given that other
> mailing-lists ensure the original==broken signature is removed or
> renamed, but not even a bug report can change the s
John Levine wrote in
<20250416172847.8886ec4e0...@ary.qy>:
|It appears that Murray S. Kucherawy said:
|>-=-=-=-=-=-
|>
|>On Tue, Apr 15, 2025 at 12:22 PM Bron Gondwana 40fastmailteam@dmarc.ietf.org> wrote:
|>
|>> Honestly, with the capacity to undo header changes from
|>> dkim2-modifi
Murray S. Kucherawy wrote in
:
|On Sun, Apr 13, 2025 at 11:56 AM Richard Clayton
|wrote:
|
|>>Bcc header field? Doesn’t that contradict the “blank” carbon copy?
|
|I think "B" means "Blind".
|
|> I suggest you read RFC5322 #3.6.3, which has quite a lot of text
|> explaining the complexit
It appears that Murray S. Kucherawy said:
>-=-=-=-=-=-
>
>On Tue, Apr 15, 2025 at 12:22 PM Bron Gondwana 40fastmailteam@dmarc.ietf.org> wrote:
>
>> Honestly, with the capacity to undo header changes from
>> dkim2-modification-algebra I would be more inclined to have the spec list
>> headers w
Taavi Eomäe wrote in
:
|On 16.04.2025 13:01, Steffen Nurpmeso wrote:
|> Ie, it is a quality-of-implementation issue, and standards cannot
|> cover everything. Ie dkimpy's default set, or my one with
|> one-letter shortcuts to very easily have a comprehensive default
|> set at hand (that then
Bron Gondwana wrote in
<5df9212c-5014-4323-8d70-fbc7d044b...@app.fastmail.com>:
|Honestly, with the capacity to undo header changes from dkim2-modificati\
|on-algebra I would be more inclined to have the spec list headers which \
|MUST NOT be signed (probably just trace headers), and to list ad
On Wed, Apr 16, 2025 at 12:22 AM Wei Chuang wrote:
> I think the question of whether to use the exclude-list or include-list
> approach comes down to X- headers handling. There's a large proliferation
> of these headers particularly for security gateway forwarding flows. I
> suspect the include
On Tue, Apr 15, 2025 at 10:24 PM Dave Crocker wrote:
> Honestly, with the capacity to undo header changes from
> dkim2-modification-algebra I would be more inclined to have the spec list
> headers which MUST NOT be signed (probably just trace headers), and to list
> additional headers to not sign
On Tue, Apr 15, 2025 at 12:22 PM Bron Gondwana wrote:
> Honestly, with the capacity to undo header changes from
> dkim2-modification-algebra I would be more inclined to have the spec list
> headers which MUST NOT be signed (probably just trace headers), and to list
> additional headers to not sig
On Sun, Apr 13, 2025 at 11:56 AM Richard Clayton
wrote:
> >Bcc header field? Doesn’t that contradict the “blank” carbon copy?
>
I think "B" means "Blind".
> I suggest you read RFC5322 #3.6.3, which has quite a lot of text
> explaining the complexity of what a Bcc header field can look like. Fo
On 16.04.2025 13:01, Steffen Nurpmeso wrote:
Ie, it is a quality-of-implementation issue, and standards cannot
cover everything. Ie dkimpy's default set, or my one with
one-letter shortcuts to very easily have a comprehensive default
set at hand (that then can be added to or subtracted from).
If
Steffen Nurpmeso wrote in
<20250415202743.1cAkTnbb@steffen%sdaoden.eu>:
|Bron Gondwana wrote in
| <5df9212c-5014-4323-8d70-fbc7d044b...@app.fastmail.com>:
||Honestly, with the capacity to undo header changes from dkim2-modificati\
||on-algebra I would be more inclined to have the spec list hea
Emil Gustafsson wrote in
:
|I agree with Bron. The carbon footprint discussion distracts away[.]
..from the single recipient constraint that increases I/O load for
practically all emails of this thread except for persons who care
(i do not with this very email in response), or which have
configu
I think the question of whether to use the exclude-list or include-list
approach comes down to X- headers handling. There's a large proliferation
of these headers particularly for security gateway forwarding flows. I
suspect the include-list approach will likely ignore X- headers, while
exclude-l
On Tue, Apr 15, 2025 at 10:25 PM Dave Crocker wrote:
> On 4/15/2025 9:21 PM, Bron Gondwana wrote:
>
> Honestly, with the capacity to undo header changes from
> dkim2-modification-algebra I would be more inclined to have the spec list
> headers which MUST NOT be signed (probably just trace headers
On 4/15/2025 9:21 PM, Bron Gondwana wrote:
Honestly, with the capacity to undo header changes from
dkim2-modification-algebra I would be more inclined to have the spec
list headers which MUST NOT be signed (probably just trace headers),
and to list additional headers to not sign, rather than ad
Honestly, with the capacity to undo header changes from
dkim2-modification-algebra I would be more inclined to have the spec list
headers which MUST NOT be signed (probably just trace headers), and to list
additional headers to not sign, rather than additional headers to sign.
I would also ment
It would be impolite to name names at this stage, and the appropriate time
to talk publicly about details is once those sending platforms have begun
signing the fields recommended in the RFC. That said, I'm sure you can
imagine the kinds of problems key unsigned headers might pose in the
context of
On 4/14/2025 11:41 PM, Burke, Evan wrote:
Regardless of the specific words we may use to describe it, I've seen
some very large email platforms omit some important headers in their
DKIM signatures - headers explicitly recommended by the DKIM RFC - and
I've seen that absence enable real-world ab
Regardless of the specific words we may use to describe it, I've seen some
very large email platforms omit some important headers in their DKIM
signatures - headers explicitly recommended by the DKIM RFC - and I've seen
that absence enable real-world abuse. Based on samples from multiple
senders o
Yes, the reason why each header should be signed should be documented. I
agree with you there.
I don't understand the purpose of the memory aid comment.
I think it is a good thing if a standard prevents users of the standard
defined from shooting themselves in the foot. Similar to newer versions o
On 4/14/2025 5:10 PM, Emil Gustafsson wrote:
rom what I think is the main purpose with a set of defined headers
that have to be signed: Making sure senders don't forget to sign them.
Forget? As if a normative requirement in a standard is a memory aid?
It might help to see some clear, explici
I agree with Bron. The carbon footprint discussion distracts away from what
I think is the main purpose with a set of defined headers that have to be
signed: Making sure senders don't forget to sign them.
Personally I don't have a strong opinion if those headers are explicit or
implicit. The key po
On Sun, Apr 13, 2025, at 13:17, Dave Crocker wrote:
> On 4/13/2025 6:34 PM, Richard Clayton wrote:
>> An average email received at $DAYJOB$ on Friday (UTC) to be placed into
>> the inbox was 81555 characters long; if it was automatically determined
>> to be "span" it was 28921 bytes long.
>
>
>
It appears that Richard Clayton said:
>>We made a similar optimization when designing DKIM not to include the public
>>key
>>in the signature and publish a digest of it in the DNS. This turned out to be
>>the wrong thing when public key sizes had to increase and the DNS couldn’t
>>easily acco
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Jim
Fenton writes
>On 11 Apr 2025, at 13:00, Richard Clayton wrote:
>
>> The list of header fields is currently
>>
>> Author
>> Bcc
>
>Bcc header field? Doesn’t that contradict the “blank” carbon copy?
I suggest you read
On 4/13/2025 6:34 PM, Richard Clayton wrote:
An average email received at $DAYJOB$ on Friday (UTC) to be placed into
the inbox was 81555 characters long; if it was automatically determined
to be "span" it was 28921 bytes long.
So, at the low end, less than 1/2 of 1%.
And what will the increme
On 11 Apr 2025, at 13:00, Richard Clayton wrote:
> The list of header fields is currently
>
> Author
> Bcc
Bcc header field? Doesn’t that contradict the “blank” carbon copy?
> It also reduces the size of every (cautious) email by 383 bytes (766 if
> the oversigning is not default
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Dave
Crocker writes
>> It also reduces the size of every (cautious) email by 383 bytes (766 if
>> the oversigning is not default) ... and there's a carbon footprint issue
>> here that we should not ignore without careful consideration
>
On 4/11/2025 1:00 PM, Richard Clayton wrote:
Our current thinking, which will be reflected in documents Real Soon Now
is that we will provide a standard list of header fields that will be
required to be signed by default -- signers can add to this if they
wish. In each case we will sign all insta
46 matches
Mail list logo
