On Thu 22/Jun/2023 19:34:43 +0200 Jan Dušátko wrote:
Dne 21. 6. 2023 v 10:59 Alessandro Vesely napsal(a):
On Tue 20/Jun/2023 09:29:13 +0200 Wei Chuang wrote:
Our proposal would be for DMARCbis to maintain the default for SPF and DKIM
support, and to support senders that want to drop SPF as one
Dne 21. 6. 2023 v 10:59 Alessandro Vesely napsal(a):
On Tue 20/Jun/2023 09:29:13 +0200 Wei Chuang wrote:
Our proposal would be for DMARCbis to maintain the default for SPF
and DKIM support, and to support senders that want to drop SPF as one
of their DMARC authentication methods to avoid the
On Wed 21/Jun/2023 23:24:57 +0200 John Levine wrote:
It appears that Alessandro Vesely said:
After sleeping on it, I think the new tag could also specify DKIM /and/ SPF,
besides or and one only, ...
I am reasonably sure that when DMARC was designed they considered that and
rejected it.
It appears that Alessandro Vesely said:
>After sleeping on it, I think the new tag could also specify DKIM /and/ SPF,
>besides or and one only, ...
I am reasonably sure that when DMARC was designed they considered that and
rejected it. So, no, and certainly not at this late state in the WG.
On Wed, Jun 21, 2023 at 1:59 AM Alessandro Vesely wrote:
> After sleeping on it, I think the new tag could also specify DKIM /and/
> SPF,
> besides or and one only, for domains that want that extra security.
> Possible
> values, for example, auth=dkim|spf (default value), auth=dkim+spf,
>
On Tue 20/Jun/2023 09:29:13 +0200 Wei Chuang wrote:
Our proposal would be for DMARCbis to maintain the default for SPF and DKIM
support, and to support senders that want to drop SPF as one of their DMARC
authentication methods to avoid the SPF upgrade vulnerability. We could
have a DMARC
