Personally, I prefer the latter of the two, quoted below.
"to preserve interoperability, domains SHOULD NOT publish p=reject unless they are
[not general purpose]* domains"
"Publishing DMARC records with restrictive policies does cause interoperability
problems for some normal email usage
It appears that Scott Kitterman said:
>We could do I think any of the following and they are roughly semantically
>equivalent:
>
>[general purpose]* domains MUST NOT publish p=reject to preserve
>interoperability
>
>to preserve interoperability, domains SHOULD NOT publish p=reject unless they
> On Apr 8, 2023, at 3:28 PM, Scott Kitterman wrote:
>
> There are several variations of text that roughly mean the same thing,
> particularly when you keep in mind that IETF specifications are intended to
> be
> interoperability specifications, not implementation specifications.
>
> We
There are several variations of text that roughly mean the same thing,
particularly when you keep in mind that IETF specifications are intended to be
interoperability specifications, not implementation specifications.
We could do I think any of the following and they are roughly semantically
On Sat, Apr 8, 2023 at 5:10 PM Scott Kitterman wrote:
> Possible. I didn't count.
>
> I didn't see any convergence towards an alternative.
>
The fact that there hasn't been convergence on an alternative doesn't mean
there has been convergence on the proposed new txt. This also doesn't mean
the
I rather thought all of the recent discussion is on the general topic of
what to do about mailing lists, and that we were still a long ways from
consensus, as we were three years ago.
For my part, I have a hard time accepting the concept that there are
meaningful distinctions between high,
Re-looking at the definition of "SHOULD NOT", I don't see why it can't
be considered.
"SHOULD NOT - This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
Possible. I didn't count.
I didn't see any convergence towards an alternative.
I think adding explicitly that the MUST is related to interoperability
reasonably addresses the concern that there are non-interoperability reasons
people are going to publish p=reject despite the side effects.
I
Going back through the thread I find more people questioning/disagreeing
with the proposed wording than agreeing with it. I don't see a rough
consensus.
Michael Hammer
On Sat, Apr 8, 2023 at 4:17 PM Scott Kitterman wrote:
> We've gone nearly a week without any further discussion on this
We've gone nearly a week without any further discussion on this thread.
I reviewed the thread and I think this is the closest we got to anything
(most) people agreed on. I know not everyone liked it, but I doubt we're
going to get closer to a consensus on this.
Can we adopt this and move
Summary:
I would like to reintroduce the DSAP (DKIM Sender Authorization Protocol) as a
DMARC extended tag extension -dsap. The original DSAP draft covered nine 1st vs
3rd party signature policies from a verifier viewpoint, which addressed
boundary conditions for DKIM signatures. The
On Sat 08/Apr/2023 16:27:35 +0200 Scott Kitterman wrote:
On Saturday, April 8, 2023 10:24:09 AM EDT John Levine wrote:
It appears that Scott Kitterman said:
I think you have gotten yourself side tracked.
The problem with DMARC and mailing lists is that receivers doing DMARC
checks can't
On Saturday, April 8, 2023 10:24:09 AM EDT John Levine wrote:
> It appears that Scott Kitterman said:
> >I think you have gotten yourself side tracked.
> >
> >The problem with DMARC and mailing lists is that receivers doing DMARC
> >checks can't (absent a list of mailing lists) reliably
It appears that Scott Kitterman said:
>I think you have gotten yourself side tracked.
>
>The problem with DMARC and mailing lists is that receivers doing DMARC checks
>can't (absent a list of mailing lists) reliably distinguish DMARC fail due to
>normal mailing list processing and DMARC fail
It appears that Scott Kitterman said:
>I don't follow. Section 5.5 is called Domain Owner Actions.
>
>Also, that's the goal for some domains, but not others. We shouldn't
>over-generalize. Personally, I publish DMARC records for the aggregate
>reports. I find them useful.
>Publishing a
On Sat, Apr 8, 2023, at 4:12 AM, Douglas Foster wrote:
> It is pretty clear how an AOL-compatible mailing list can be configured:
>
> • All messages come from the list domain
> • Plus addressing is used to give each subscriber a unique From address..
> • To be standards-compliant the plus
On Saturday, April 8, 2023 9:49:24 AM EDT John Levine wrote:
> It appears that Seth Blank said:
> >So how do we handle this? What’s the worst case? Looking at the above
> >example, the longest “complex org” would be 5 labels long. I think we’ve
> >already agreed, backed by data from the PSL,
It appears that Eric D. Williams said:
>-=-=-=-=-=-
>
>I think the reliance upon list operators is properly placed on that role.
>It's not a DMARC problem, it's a DKIM problem, I think.
No, it's a DMARC problem. DKIM didn't cause any problems for mailing
lists (ignoring ill-advised and never
I think you have gotten yourself side tracked.
The problem with DMARC and mailing lists is that receivers doing DMARC checks
can't (absent a list of mailing lists) reliably distinguish DMARC fail due to
normal mailing list processing and DMARC fail due to abusive behavior. To
mitigate this
It appears that Neil Anuskiewicz said:
>-=-=-=-=-=-
>To this point, some inbound configurations have no record or a permerror have
>a continue disposition. Is that risky? Everything is a trade off so I� m not
>asking is there any
>risk at all but more asking about the trade offs.
It seems to
It appears that Seth Blank said:
>So how do we handle this? What’s the worst case? Looking at the above
>example, the longest “complex org” would be 5 labels long. I think we’ve
>already agreed, backed by data from the PSL, that the longest PSD would be
>4 labels long. ...
>To be clear, due to
Identifier rewrite affects the leg from MLM to subscriber. Email security in
the leg from poster to MLM is completely ignored by the draft, although MLMs
constitutes a major concern.
We joyfully rely on traditional techniques to counter potential attacks,
estimating that there is no reason
It is pretty clear how an AOL-compatible mailing list can be configured:
- All messages come from the list domain
- Plus addressing is used to give each subscriber a unique From address..
- To be standards-compliant the plus address still needs to fit within
the 64-character limit,
23 matches
Mail list logo
