On Mon, Jul 3, 2023 at 10:29 AM Hector Santos wrote:
>
>
> > On Jul 3, 2023, at 10:06 AM, Barry Leiba
> wrote:
> >
> >> Anyway, discussing whether spf+dkim verification can mitigate DKIM
> replay
> >> belongs to the ietf-dkim list. (In case, it could also be expressed
> outside
> >> DMARC, for
> On Jul 3, 2023, at 10:06 AM, Barry Leiba wrote:
>
>> Anyway, discussing whether spf+dkim verification can mitigate DKIM replay
>> belongs to the ietf-dkim list. (In case, it could also be expressed outside
>> DMARC, for example by an additional DKIM tag.)
>
> I do agree with this, yes.
>
> Anyway, discussing whether spf+dkim verification can mitigate DKIM replay
> belongs to the ietf-dkim list. (In case, it could also be expressed outside
> DMARC, for example by an additional DKIM tag.)
I do agree with this, yes.
Barry
___
Ietf-dkim
On Fri 30/Jun/2023 19:22:28 +0200 Barry Leiba wrote:
Ale, you're venue-shopping; please don't do that.
Sorry, I understood the discussion was banned from the dmarc list.
In fact, messages that would only be blocked by auth=dkim+spf are either
messages that pass DKIM but fail SPF, or
Ale, you're venue-shopping; please don't do that.
> Discussions about solutions that only cover DKIM replay are now declared to be
> out of scope for DMARC. In fact, messages that would only be blocked by
> auth=dkim+spf are either messages that pass DKIM but fail SPF, or messages
> that
> pass
Hi,
for those of you who don't subscribe to dm...@ietf.org, I resume this proposal,
which was aired there last week.
The idea is to let a domain specify which mechanisms to consider when
validating DMARC alignment. The default would be auth=dkim/spf, meaning that
either an aligned
