I know that we took out the reference to default policy at my request, and
I think it was in section 7.1. But subsequent discussion helped me to
understand objectives that were not clear to me in the previous text. I
think we need to re-insert something specific about domain owners that want
DK
Using the reverse tree walk for alignment can become disastrous if a PSD
publishes a policy record without the PSD=Y flag. Worse yet, organizations
would be powerless to defend against its harm. To prent this harm, the
alignment tree walk needs to proceed in the upward direction only.
Additional
On Fri 11/Feb/2022 08:57:17 +0100 Douglas Foster wrote:
This section implies that publishing SPF -ALL is a risky move, which is made
worse by DMARC.SPF -ALL is a only risk when (a) the message is forwarded
without MAILFROM rewrite and (b) the evaluator does not implement DMARC.
My reading of
On Fri, Feb 11, 2022 at 7:19 AM Alessandro Vesely wrote:
> On Fri 11/Feb/2022 08:57:17 +0100 Douglas Foster wrote:
> > This section implies that publishing SPF -ALL is a risky move, which is
> made
> > worse by DMARC.SPF -ALL is a only risk when (a) the message is forwarded
> > without MAILFROM r
No. “?all” in an SPF record is a negative signal to many filters and a quick
way to the spam folder. It also exposes the domain to abuse unconnected with
DMARC.
If a sender intentionally relies on DKIM-only alignment, then that’s their
decision. Making any recommendations as to what their SPF r
On Fri, Feb 11, 2022 at 3:14 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> I know that we took out the reference to default policy at my request, and
> I think it was in section 7.1. But subsequent discussion helped me to
> understand objectives that were not clear to me in t
On 2022-02-11 08:57, Douglas Foster wrote:
This section implies that publishing SPF -ALL is a risky move, which
is made worse by DMARC. SPF -ALL is a only risk when (a) the message
is forwarded without MAILFROM rewrite and (b) the evaluator does not
implement DMARC.
+1
Rather than telling s
It appears that Dotzero said:
>> I agree with Ale. Further, it is not as if we are considering this in a
>vacuum. Since originally being made public, DMARC has been widely
>implemented and it has not been identified that this (early reject on SPF
>-all) has been a significant or even an insignifi
On 2022-02-11 17:25, John Levine wrote:
A bare -all is clearly a special case, the converse of null MX, that
means no mail at all. I agree the current wording is fine.
nullMX is supported from all mta, but spf is lotto
___
dmarc mailing list
dmarc@i
On Fri 11/Feb/2022 09:29:07 +0100 Douglas Foster wrote:
Using the reverse tree walk for alignment can become disastrous if a PSD
publishes a policy record without the PSD=Y flag. Worse yet, organizations
would be powerless to defend against its harm. To prent this harm, the
alignment tree wa
It appears that Alessandro Vesely said:
>I think it is already clear to the WG that the tree walk is screwed up.
Yes, we know we have to rewrite sections 4.5 and 4.6.
I think there are 2 1/2 situations we need to look at.
The first is finding the policy record for a domain that does not have
I don't see that the current language is in any way limited to the soecial
case of only -ALL. I read it as a general warning.
On Fri, Feb 11, 2022, 11:26 AM John Levine wrote:
> It appears that Dotzero said:
> >> I agree with Ale. Further, it is not as if we are considering this in a
> >vacu
> On Jan 25, 2022, at 10:35 AM, John R Levine wrote:
>
> Do we have any stats on how often real mail depends on sibling alignment? If
> nobody actually uses it, the spec would be simpler if we could take it out.
Stats are tricky, but here are some senders using sibling alignment like
From dom
Barry,
Your note underscored the lack of interest in engaging in discussion of
the original substance to my posting. So I will of course drop further
attempts at improving the working group's documentation effort.
However your note also underscored a basic misunderstanding in rules,
process
14 matches
Mail list logo