On Wed, Oct 25, 2023, 8:25 PM Jesse Thompson wrote:
> On Wed, Oct 25, 2023, at 4:06 PM, Todd Herr wrote:
>
> Someone posting at Security Boulevard has decreed that DMARCbis (at least
> the t= tag parts of it) are now codified:
>
>
On Wed, Oct 25, 2023, at 4:06 PM, Todd Herr wrote:
> Someone posting at Security Boulevard has decreed that DMARCbis (at least the
> t= tag parts of it) are now codified:
>
> https://securityboulevard.com/2023/10/dmarc-t-tag-replaces-pct-in-dmarcbis/
>
> This person did a fantastic job of
Someone posting at Security Boulevard has decreed that DMARCbis (at least
the t= tag parts of it) are now codified:
https://securityboulevard.com/2023/10/dmarc-t-tag-replaces-pct-in-dmarcbis/
This person did a fantastic job of cutting and pasting from DMARCbis to
"create" their "content".
--
On Wed, Oct 25, 2023 at 9:33 AM Richard Clayton
wrote:
> >The operator is making the decision to publish or enforce, not the
> >user.
>
> Looking at $DAYJOB$ logs for this week I see a shade under 300 people
> who are participating in IETF working groups using p=reject addresses.
>
> I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Murray S. Kucherawy
writes
>Do you really want to be pushing that information and decision
>burden onto users? How many of them will understand versus
>ignoring it and just blundering ahead?
I think that depends how
On Wed, Oct 25, 2023 at 8:17 AM Richard Clayton
wrote:
> So might I suggest a wording that captures what will actually happen in
> the real world
>
> Domains that choose to publish p=reject SHOULD inform the people
> using those domains of the issues that may arise if theu post to
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Brotman, Alex writes
>+1 SHOULD NOT
If there is not going to be a consensus for just a discussion of the
issue (which I would prefer) then my view, obviously is that SHOULD NOT
is to be preferred to MUST NOT
The relevant bit of
On Tue, Oct 24, 2023 at 11:11 PM Steven M Jones wrote:
> On 10/20/23 12:35 PM, Murray S. Kucherawy wrote:
>
> (1) As written, the text says (to me) that the handling of a message might
> change depending on this mapping of a broken value to "none", but only if
> "rua" is present; absent "rua",
On Wednesday, October 25, 2023 11:01:27 AM EDT Richard Clayton wrote:
> In message , Scott
> Kitterman writes
>
> >>> My reading of the discussion is:
> >>>
> >>> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
>
> sadly so, it would have been the right thing to do
>
On Wednesday, October 25, 2023 10:46:09 AM EDT Emanuel Schorsch wrote:
> > >There's the counterargument "so don't publish SPF" but it's on so many
> >
> > checklists
> >
> > >that even though that would be a fine idea, it's not practical.
> >
> > Diving into the SPF angle, if someone has a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Scott
Kitterman writes
>>> My reading of the discussion is:
>>>
>>> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
sadly so, it would have been the right thing to do
>>> 2. We did not have rough consensus to
>
> >There's the counterargument "so don't publish SPF" but it's on so many
> checklists
> >that even though that would be a fine idea, it's not practical.
>
> Diving into the SPF angle, if someone has a 'legitimate' mail source that
> also sends spoofed mail for them, they can prefix the relevant
On Tue, Oct 24, 2023 at 2:15 PM Barry Leiba wrote:
> Now that we have a consensus call on the main issue that has remained open:
>
> 1. Do we need to retain our session at IETF 118 and discuss this (or
> something else) further?
>
> ...or...
>
> 2. Do we have what we need to finish up the
On October 25, 2023 1:37:55 PM UTC, John Levine wrote:
>It appears that Scott Kitterman said:
>>>* Is there consensus on moving ahead with the idea of a way to indicate
>>>which authentication method(s) the Domain Owner wants Receivers to use? If
>>>so, it doesn't seem to be in the document
It appears that Scott Kitterman said:
>>* Is there consensus on moving ahead with the idea of a way to indicate
>>which authentication method(s) the Domain Owner wants Receivers to use? If
>>so, it doesn't seem to be in the document yet.
>
>I haven't seen any valid case for it yet. It adds
On Wed, Oct 25, 2023 at 8:56 AM Scott Kitterman
wrote:
>
>
> On October 25, 2023 11:56:25 AM UTC, Alessandro Vesely
> wrote:
> >On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
> * Is there consensus on moving ahead with the idea of a way to
> indicate which authentication method(s)
What if we were to look at re-writing this in a way that says something
like this:
In the case of optional DMARC flags (ex: sp, adkim, aspf, pct) that are
malformed, the processing system SHOULD ignore them as invalid inputs, and
MUST utilize the valid flags that are mandatory (ex: v, p) and
On October 25, 2023 11:56:25 AM UTC, Alessandro Vesely wrote:
>On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
* Is there consensus on moving ahead with the idea of a way to indicate
which authentication method(s) the Domain Owner wants Receivers to use?
If so, it doesn't
On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
* Is there consensus on moving ahead with the idea of a way to indicate
which authentication method(s) the Domain Owner wants Receivers to use? If
so, it doesn't seem to be in the document yet.
My recall is that we want to limit DMARC
On 25/10/2023 13:25, Matthäus Wander wrote:
As error reports have never gotten any traction, it would be a big
effort to make this work. Reusing the existing ecosystem of aggregate
reports is a lower hanging fruit. Tools and processes are established
and even the aggregate report format
Olivier Hureau wrote on 2023-10-25 12:56:
What about using the error report of RFC 7489 for this purpose instead
of aggregate report? (
https://datatracker.ietf.org/doc/html/rfc7489#section-7.2.2 )
I have never seen any error report but I think that error reports were a
great ideas because
On Wed, Oct 25, 2023 at 7:12 AM Barry Leiba wrote:
> > > * Is there consensus on moving ahead with the idea of a way to indicate
> > > which authentication method(s) the Domain Owner wants Receivers to
> use? If
> > > so, it doesn't seem to be in the document yet.
> >
> > My recall is that we
> > * Is there consensus on moving ahead with the idea of a way to indicate
> > which authentication method(s) the Domain Owner wants Receivers to use? If
> > so, it doesn't seem to be in the document yet.
>
> My recall is that we want to limit DMARC evaluation to DKIM only, for the edge
> cases
DMARC is a protocol that uses a published DNS record to advertise a
sending domain's policy. It's described in RFC 7489 and the DMARCbis
draft.
What anyone does in the absence of a published DMARC record is *not*
part of DMARC, in the same way that use of FTP to deliver email is not
part of
On 25/10/2023 08:10, Steven M Jones wrote:
It's not so much changing the handling as changing the reporting.
* The policy to apply is "none," because the p/sp/np value was faulty.
Done.
* Next step, if there's no "rua" target you can't report - which is
now equivalent to bailing out of DMARC
On Wed 25/Oct/2023 05:38:01 +0200 Murray S. Kucherawy wrote:
On Tue, Oct 24, 2023 at 11:15 AM Barry Leiba wrote:
2. Do we have what we need to finish up the DMARCbis document, and
should the chairs cancel the session at 118?
A few questions, but they don't demand in-person time if we want
More specifically to the asserted charter problem:
RFC 7489 provided a universally applicable rule for determining
organizational boundaries: the PSL.
Then it provided a universally applicable rule for determining
authentication: relaxed alignment, same organization for the verified
identifier
The solution then should be to fix the charter. Everything depends on
your definition of DMARC. Here is mine:
"DMARC is the use of proxy authentication to provide verification of the
FROM address and mitigate malicious impersonation of that address, combined
with supporting mechanisms to
On Tue 24/Oct/2023 20:15:22 +0200 Barry Leiba wrote:
2. Do we have what we need to finish up the DMARCbis document, and
should the chairs cancel the session at 118?
IMHO this one.
Best
Ale
--
___
dmarc mailing list
dmarc@ietf.org
On Wed 25/Oct/2023 08:10:33 +0200 Steven M Jones wrote:
PROPOSED versus draft 28 section 4.7:
If a retrieved policy record does not contain a valid "p" tag, or
contains an "sp" or "np" tag that is not valid, then:
* The Mail Receiver MUST act as if a record containing
On Tue 24/Oct/2023 15:20:02 +0200 Baptiste Carvello wrote:
Le 23/10/2023 à 19:59, Alessandro Vesely a écrit :
My opinion is that Barry's text is good as is. As far as delimiting a SHOULD
NOT with another SHOULD is legit, this sentence sounds clear to me:
It is therefore critical that
On 10/20/23 12:35 PM, Murray S. Kucherawy wrote:
(1) As written, the text says (to me) that the handling of a message
might change depending on this mapping of a broken value to "none",
but only if "rua" is present; absent "rua", the record is treated as
junk and DMARC doesn't apply.
It's
32 matches
Mail list logo
