On Wed 27/Jan/2021 12:31:51 +0100 Douglas Foster wrote:
Is this already a settled issue?
There doesn't seem to be a consensus, yet.
I repeat what I already proposed:
* max number of DKIM signatures: 1024 (say)
* min number of DKIM signatures: 0
* can report unverified signatures (none)
*
Is this already a settled issue? The specification already calls for a
complete A-R data set, so all signatures are supposed to be included if
they are evaluated. Are the largest reporting sources already providing a
complete list of DKIM signatures?
However, there are significant technical prob
For indirect mail, the aligned
signature selector tells you where to look for the message origin. The last
hop information tells you where it ended up.
For direct messages, the last hop tells you whether it came from a third
party or internal server, and the aligned signature selector confirms the
On Tue 26/Jan/2021 15:12:57 +0100 Douglas Foster wrote:
At some point, an investigator will ask, "which of our systems sent these
messages?"
Possibly none. In that case this is either an abuse or a forward. Or maybe
the report generator lies.
I know how to search my logs for messages to
At some point, an investigator will ask, "which of our systems sent these
messages?"
I know how to search my logs for messages to domain example.com. I do not
know how to search my logs for messages to domains hosted by
hostingservice.tld. That is why I would expect SMTP To domain to be useful.
On Tue 26/Jan/2021 13:02:46 +0100 Douglas Foster wrote:
DKIM Scopes
I have not heard a compelling argument to require information about
authentication tests that are unrelated to alignment testing. For DKIM
specifically, I think one scope should be sufficient, on this hierarchy:
- The best
This topic becomes much more than "which signature". It is really about
"what is needed to identify and correct alignment problems".
Based on the authentication discussion, we have several inter-related
issues:
- I started with a concern about putting excessive data collection
requirements on th
Can we go slightly off topic to review why the report does not include the
destination domain?
That data element seems a lot more relevant than a tertiary signature.
I can see that domain identification and disaggregation could significantly
increase the size of reports from Gsuite and Office365,
On Mon 25/Jan/2021 18:59:16 +0100 Brotman, Alex wrote:
I’m not suggesting that we add anything that would report “Signature
validation not attempted”, that sounds horrible. Will the original source
potentially care that the message was signed in three other places as the
message bounced around?
On Mon 25/Jan/2021 13:21:37 +0100 Douglas Foster wrote:
This is an interesting issue. Perhaps we need another ticket just to discuss
how to handle signature transition.
Reporting the selector suffices. Ticket #57.
Best
Ale
--
_
On Mon 25/Jan/2021 01:25:13 +0100 Brotman, Alex wrote:
Some time ago, an issue[1] was brought to the list where which DKIM(s) being
reported is not clear in RFC7489 [2]. There was a short discussion, though no
clear resolution before conversation trailed off. It seems like there were
points
wy
Sent: Monday, January 25, 2021 12:20 PM
To: Brotman, Alex
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)
On Sun, Jan 24, 2021 at 4:25 PM Brotman, Alex
mailto:40comcast@dmarc.ietf.org>>
wrote:
Some time ago, an issue[1] was brought to
C WG
Subject: Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)
Currently, my filter only evaluates signatures that are relevant to From
alignment, and stops after the first success. For that decision process, all
that I need returned (and stored) is a Pass/Fail result; I don&#x
In article you write:
>lets say a site signs an email with both rsa and ed25519 algorithms. This
>site wants to know, whether the recipient can
>validate the ed25519 signatures, so that in the future rsa signing for that
>receiving site can be skipped (or errors in the
>ed25519 implementation f
On Sun, Jan 24, 2021 at 4:25 PM Brotman, Alex wrote:
> Some time ago, an issue[1] was brought to the list where which DKIM(s)
> being reported is not clear in RFC7489 [2]. There was a short discussion,
> though no clear resolution before conversation trailed off. It seems like
> there were poin
This is an interesting issue. Perhaps we need another ticket just to
discuss how to handle signature transition. My first thought is that it
will be more effective to announce support for ed25519 in the report
header, rather than in each message result. Another possibility is for a
recipient to
Hello,
lets say a site signs an email with both rsa and ed25519 algorithms. This site
wants to know, whether the recipient can validate the ed25519 signatures, so
that in the future rsa signing for that receiving site can be skipped (or
errors in the ed25519 implementation fixed).
For this to
Currently, my filter only evaluates signatures that are relevant to From
alignment, and stops after the first success. For that decision process,
all that I need returned (and stored) is a Pass/Fail result; I don't need
the details of the algorithm evaluated. Any additional information
collectio
Hello folks,
Some time ago, an issue[1] was brought to the list where which DKIM(s) being
reported is not clear in RFC7489 [2]. There was a short discussion, though no
clear resolution before conversation trailed off. It seems like there were
points that may need to be discussed. One was whe
19 matches
Mail list logo
