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, so
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 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 t
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 m
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 iss
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 use
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, that
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 addre
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 D
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 du
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 distingui
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 (ab
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 reintroduc
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 forwa
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 thread.
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 d
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
implicat
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, medium,
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
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
eq
> 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 co
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
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 patt
23 matches
Mail list logo
