On Fri, Feb 17, 2023 at 9:35 AM Scott Kitterman
wrote:
> Currently RFC 6376 says, "Signatures MAY be considered invalid". I think
> the practical effect as described in protocol terms would be to change the
> MAY to SHOULD under X conditions and SHOULD NOT under !X conditions. Not
> that I'd
On Fri, Feb 17, 2023 at 9:49 AM Michael Thomas wrote:
>
> Which brings up another question which is applicable to the problem
> statement: are mailbox providers like gmail, hotmail, etc getting abused
> from these replays? Some spam from whokn...@hotmail.com doesn't seem
> like a very good
I've said in multiple threads that the current problem both in the
charter and the problem draft are far too vague for us to address. Here
are some from me at least:
1. Who are the victims? Just bulk senders? Are the bulk senders signing
using their domain?
2. If there are different types
On 2/17/23 9:34 AM, Scott Kitterman wrote:
Currently RFC 6376 says, "Signatures MAY be considered invalid". I think the
practical effect as described in protocol terms would be to change the MAY to SHOULD
under X conditions and SHOULD NOT under !X conditions. Not that I'd expect to see
Currently RFC 6376 says, "Signatures MAY be considered invalid". I think the
practical effect as described in protocol terms would be to change the MAY to
SHOULD under X conditions and SHOULD NOT under !X conditions. Not that I'd
expect to see this appear in a protocol document (maybe some
On Thu, Feb 16, 2023 at 2:13 PM Barry Leiba wrote:
> I like this approach: if the issue is that an "expired" signature is
> treated as unsigned, I think we have an unacceptable level of false
> positives. But if the fact that a signature is valid but expired is
> simply another factor in the
On Thu 16/Feb/2023 21:56:52 +0100 Barry Leiba wrote:
Okay. What's the value for X - T that prevents this problem, but doesn't cause DKIM
signatures of "normal" mail to fail?
There's not one "right" value; we're talking about distributions
of timings for normal mail vs. replay, and yes,
