On Fri, Aug 26, 2022 at 8:52 AM Alessandro Vesely wrote:
> > NEW
> > If the set produced by the DNS Tree Walk contains no DMARC policy record
> > (i.e., any indication that there is no such record as opposed to a
> > transient DNS error), then the DMARC mechanism does not apply to this
> >
I agree with Scott. We do need to be that blunt given what people have
thrown out there because DMARC doesn't say it's not ok. One thing we have
been firm about is that if there isn't a DMARC record it isn't DMARC. For
"other things", people are free to go off and experiment with consenting
I do. Maybe I'm wrong and I've just read far to many crazy ideas preceded by
"It doesn't actually say you CAN'T do that". I would strongly prefer we be as
direct and blunt about this as possible, even though that's probably
insufficient to the task in at least some cases.
I know Ale liked
You really think it needs to be BCP 14 key words, rather than saying in
plain English that if there’s no DMARC record we are outside the realm of
DMARC?
Barry
On Sat, Aug 27, 2022 at 5:15 PM Scott Kitterman
wrote:
> On Friday, August 26, 2022 11:51:51 AM EDT Alessandro Vesely wrote:
> > On Fri
On Friday, August 26, 2022 11:51:51 AM EDT Alessandro Vesely wrote:
> On Fri 26/Aug/2022 17:21:09 +0200 Barry Leiba wrote:
> > Personally, I'm fine with the text here, but I would also be happy
> > with removal of the BCP 14 key words here, like this:
> >
> > NEW
> > If the set produced by the
On Fri 26/Aug/2022 17:21:09 +0200 Barry Leiba wrote:
Personally, I'm fine with the text here, but I would also be happy
with removal of the BCP 14 key words here, like this:
NEW
If the set produced by the DNS Tree Walk contains no DMARC policy record
(i.e., any indication that there is no such
I'm going to respond to some of this out of order, because I think it
will help the flow.
> We have these situations where the verification result is unambiguous, with
> or without a DMARC policy:
> - A verified identifier that has the same domain as the RFC5322.From address
> is always a PASS.
Yes Todd, this is the problem language:
"If the set produced by the DNS Tree Walk contains no DMARC policy record
(i.e., any indication that there is no such record as opposed to a
transient DNS error), Mail Receivers MUST NOT apply the DMARC mechanism to
the message."
There are really two
On Wed 24/Aug/2022 17:11:30 +0200 Murray S. Kucherawy wrote:
On Wed, Aug 24, 2022 at 4:25 AM Alessandro Vesely wrote:
On Wed 24/Aug/2022 07:56:41 +0200 Murray S. Kucherawy wrote:
However, the charter, at paragraph 4, demands that any change made
by this working group which does not preserve
On Wed, Aug 24, 2022 at 2:09 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> I understand the need to limit scope, if DMARC limits its claims to what
> it covers. This complaint was triggered largely with the "MUST NOT" claim
> in the draft, which implied that DMARC is the
> I understand the need to limit scope, if DMARC limits its claims to
> what it covers. This complaint was triggered largely with the "MUST
> NOT" claim in the draft, which implied that DMARC is the all-inclusive
> tool for validating the RFC5322.From address using SPF and DKIM. If
> it is all
I understand the need to limit scope, if DMARC limits its claims to what it
covers. This complaint was triggered largely with the "MUST NOT" claim in
the draft, which implied that DMARC is the all-inclusive tool for
validating the RFC5322.From address using SPF and DKIM. If it is all
inclusive,
On Wed, Aug 24, 2022 at 4:25 AM Alessandro Vesely wrote:
> On Wed 24/Aug/2022 07:56:41 +0200 Murray S. Kucherawy wrote:
> > I believe your "policy is useful when present but not required" remark
> is a
> > re-statement of your claim that DMARC should yield a "pass" for any
> aligned
> >
On Wed 24/Aug/2022 07:56:41 +0200 Murray S. Kucherawy wrote:
I believe your "policy is useful when present but not required" remark is a
re-statement of your claim that DMARC should yield a "pass" for any aligned
identifier irrespective of the presence or absence of a published policy.
The
On Tue, Aug 23, 2022 at 4:52 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> As best I understand the chair position, DMARC supports domain owners:
> - via PASS, which might improve delivery rates, and more importantly
> - via FAIL, by providing a way to deflect blame and
>> The reason an evaluator expends compute cycles on validation is to
>> meet their own needs, which are to accept messages that they want and
>> block messages that they do not want. Source filtering is the most
>> important part of that process.
>
> Sure, but in the absence of a published
On Tue, Aug 23, 2022 at 7:52 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> As best I understand the chair position, DMARC supports domain owners:
> - via PASS, which might improve delivery rates, and more importantly
> - via FAIL, by providing a way to deflect blame and
> On 23 Aug 2022, at 12:51, Douglas Foster
> wrote:
>
> As best I understand the chair position, DMARC supports domain owners:
> - via PASS, which might improve delivery rates, and more importantly
This is an incorrect interpretation of what DMARC does.
DMARC allows evaluators to reliably
As best I understand the chair position, DMARC supports domain owners:
- via PASS, which might improve delivery rates, and more importantly
- via FAIL, by providing a way to deflect blame and liability when others
are harmed by messages impersonating the domain's identity.
This requires a DMARC
On Mon, Aug 22, 2022 at 9:14 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> If an ARC chain with SPF PASS demonstrates that a list post is legitimate,
> it only does so because the evaluator is testing alignment (exact match)
> between the domain reported in the ARC results and
If an ARC chain with SPF PASS demonstrates that a list post is legitimate,
it only does so because the evaluator is testing alignment (exact match)
between the domain reported in the ARC results and the domain of the FROM
address on the message. This is the DMARC verification algorithm, without
On Mon, 22 Aug 2022, Wei Chuang wrote:
I agree with the OP's premise that there needs to be a better
authentication method that works with mailing lists. ...
Google seems pretty enthusiastic about ARC.
Since large mail systems already know where the mailing lists are, I asked
why not just
On Mon, Aug 22, 2022 at 6:32 AM Barry Leiba wrote:
> > Mailing lists are supposed to be a closed group. This means that posts
> should only be accepted if they are verifiably
> > from the subscriber indicated in the RFC5322.From address. This
> requirement means that a list needs a mechanism
> Mailing lists are supposed to be a closed group. This means that posts
> should only be accepted if they are verifiably
> from the subscriber indicated in the RFC5322.From address. This requirement
> means that a list needs a mechanism
> for verifying the RFC5322.From address, and the
Mailing lists are supposed to be a closed group. This means that posts
should only be accepted if they are verifiably from the subscriber
indicated in the RFC5322.From address. This requirement means that a list
needs a mechanism for verifying the RFC5322.From address, and the mechanism
needs
25 matches
Mail list logo
