As you prepare for the meeting, I'm reposting the attached summary from April
when I tried to explore where there might be some consensus on the
interoperability question. In it, I tried out the generic formulation:
> [some appropriate description] domains MUST NOT publish restrictive DMARC
> p
On Thu, Jul 6, 2023 at 3:00 PM Barry Leiba wrote:
> That's fine, as long as we're all understanding that it's still just a
> proposal and we'll be discussing it at IETF 117 and on the mailing list.
>
Absolutely. I just wanted to have a fresh draft in place before the cut off
date, and today was
As I've said before, I think we should specify what we think is right,
and allow implementers to make their decisions. We can't and won't
police them.
b
On Thu, Jul 6, 2023 at 2:59 PM Brotman, Alex wrote:
>
> I suspect the portion that instructs receivers to not act solely on p=reject
> may be
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Domain-based Message
Authentication, Reporting & Conformance (DMARC) WG of the IETF.
Title : Domain-based Message Authentication, Reporting, and
Conformance (DM
That's fine, as long as we're all understanding that it's still just a
proposal and we'll be discussing it at IETF 117 and on the mailing list.
Barry
On Thu, Jul 6, 2023 at 2:07 PM Todd Herr wrote:
> I'll prepare a new rev incorporating this proposed text (and some other
> unrelated stuff that
I suspect the portion that instructs receivers to not act solely on p=reject
may be ignored by a fair set of receivers. I'm not necessarily opposed to the
language below, just that it seems odd to create language that we know will be
ignored. Additionally, I find it odd that we won't tell forw
I'll prepare a new rev incorporating this proposed text (and some other
unrelated stuff that's been lying fallow for a few months) and release it
today.
On Thu, Jul 6, 2023 at 12:02 PM John Levine wrote:
> It appears that Barry Leiba said:
> >This makes it explicitly clear that any MUST/SHOULD
It appears that Barry Leiba said:
>This makes it explicitly clear that any MUST/SHOULD stuff with regard
>to using and honoring p=reject is an issue of interoperating with
>existing Internet email features. I can accept that mechanism also,
>and so, below is my attempt at writing that proposal u
Hey Douglas,
Thank you for your response. Full disclosure this is the subject of my talk
I’ll be presenting at defcon next month, I thought I’d reach out cause the more
I dig into this the more nuance I find.
Just to clarify, is it possible having this “bad” ARC header is skewing the
final spa
I don't think this is the place to tell mailing lists what to do, and
that's all discussed in Section 4.1.3 of RFC 7960.
Barry
On Thu, Jul 6, 2023 at 11:48 AM Alessandro Vesely wrote:
>
> Hi,
>
> the only issue I'd put about the new section is that it doesn't mention From:
> munging. Isn't that
Hi,
the only issue I'd put about the new section is that it doesn't mention From:
munging. Isn't that practice widespread enough that it deserves being considered?
Best
Ale
On Thu 06/Jul/2023 16:55:02 +0200 Barry Leiba wrote:
I had some off-list discussions with Seth, who was very much ag
Whatever works within our constraints. It is certainly an
interoperability consideration, and evaluators will have a hard time
reverse engineering why the signature fails verification.
df
On Thu, Jul 6, 2023, 11:25 AM Barry Leiba wrote:
> > This language works well for me.
>
> Excellent; than
> This language works well for me.
Excellent; thanks.
> I suggest adding some language about why MTAs should not rearrange message
> headers or MIME
> sections, even though earlier documents grant permission to do so.
>
> Additionally, when adding headers, an MTA must add them at the top if (a)
> For clarity: When you say, "AD will call consensus on this issue", you mean
> after the results of the discussion
> are brought to the list and reviewed by the working group, not at the
> meeting, right?
Yes, correct. I wanted to make it clear that Seth and I both have a
conflict on this, an
This language works well for me.
I suggest adding some language about why MTAs should not rearrange message
headers or MIME sections, even though earlier documents grant permission to
do so.
Additionally, when adding headers, an MTA must add them at the top if (a)
the header type is included in a
For clarity: When you say, "AD will call consensus on this issue", you mean
after the results of the discussion are brought to the list and reviewed by the
working group, not at the meeting, right?
Also, I expect to have a proposal on protocol reliability related to the "drop
SPF" discussion,
Below is the agenda I am posting for the session at IETF 117.
Comments, changes, and additions are welcome; please post them here.
Barry
---
DMARC working group session at IETF 117
Friday, 28 July, 2023 — 12:00-13:30 PDT (UTC-7)
- Introduction
I had some off-list discussions with Seth, who was very much against
my original proposed text, and he suggested an alternative
organization that would be more palatable to him. I've attempted to
set that out below. The idea is to remove the normative requirements
about using p=reject from Sectio
"Cloudfare" is not qualified, so it does not credibly mean "This message
was submitted by user Cloudfare with his correct password.". This guess can
be validated by checking where the ARC set appears relative to the Received
chain.
Since we know that Cloudfare is a large hosting service, I suspect
19 matches
Mail list logo
