On Wed, Apr 12, 2023 at 12:45 PM Steven M Jones wrote:
> This puts me in mind of Section 8.5, which calls out some potential
> impacts of blocking policies to "Mediators," which role doesn't otherwise
> appear very often in this document. Is there any need to add Mediator
>
On Wed, Apr 12, 2023 at 11:41 AM Todd Herr wrote:
> On Wed, Apr 12, 2023 at 2:16 PM Murray S. Kucherawy
> wrote:
>
>> I've been thinking about the point a few people have made now that DMARC
>> has two actors that cause the problem: Those who "blindly" apply
>> "p=reject", and those who
On Wed, 12 Apr 2023, Eric D. Williams wrote:
No, it's a DMARC problem. DKIM didn't cause any problems for mailing
lists ...
mailing lists the real answer is ARC not DMARC, that's what I'm saying. It's
a failure with DKIM signature invalidation as a result of relaying via
mailing lists.
My
On Mon, Apr 10, 2023 at 9:30 AM John R Levine wrote:
> On Mon, 10 Apr 2023, Alessandro Vesely wrote:
> > On Sat 08/Apr/2023 15:59:30 +0200 John Levine wrote:
> >> It appears that Eric D. Williams said:
> >>> -=-=-=-=-=-
> >>>
> >>> I think the reliance upon list operators is properly placed on
> On Apr 12, 2023, at 2:15 PM, Murray S. Kucherawy wrote:
>
> I've been thinking about the point a few people have made now that DMARC has
> two actors that cause the problem: Those who "blindly" apply "p=reject", and
> those who advertise "p=reject". You do, indeed, need two to tango;
>
On 4/12/23 11:15 AM, Murray S. Kucherawy wrote:
The MLM can then decide if it is willing to pass the message
unmodified to the list, or reject it with an error like "The policies
of this list require modification of your message, which violates your
domain's apparent policy. Your submission
My own feeling is that lists should have a service agreement / disclosure
statement that says,
"We will modify your text in {manner} for {reason}.".
"We will do {feature} to reduce the risk of unwanted or dangerous list
posts".
"We will do {feature} to minimize use of off-topic posts. The
On Wed, Apr 12, 2023 at 2:16 PM Murray S. Kucherawy
wrote:
> I've been thinking about the point a few people have made now that DMARC
> has two actors that cause the problem: Those who "blindly" apply
> "p=reject", and those who advertise "p=reject". You do, indeed, need two
> to tango;
I've been thinking about the point a few people have made now that DMARC
has two actors that cause the problem: Those who "blindly" apply
"p=reject", and those who advertise "p=reject". You do, indeed, need two
to tango; enforcement doesn't happen without an advertising sender and a
participating
On Wed, Apr 12, 2023 at 8:27 AM Brotman, Alex
wrote:
> In the case of DNSSEC, my ISP is the intermediary utilizing DNSSEC, and
> the website signs records via DNSSEC. The website I want to go to breaks
> their DNSSEC. My ISP cannot retrieve a record to return to my browser that
> can be used.
Dear Alex and all,
I appreciate your insights on the challenges of balancing security and
interoperability, particularly in the context of DMARC and its implications on
email delivery. I agree with your suggestion of adding a more detailed section
on the implications of DMARC policies in
I note that you didn't write "MUST NOT". I heartily concur with "shouldn't"
or SHOULD NOT. I still have issues with "MUST NOT".
Keep in mind that MUST NOT doesn't mean "do this and you will die", it
means "do this and you won't interoperate" which seems exactly correct
here.
SHOULD NOT
On Wed, Apr 12, 2023 at 9:41 AM John R Levine wrote:
>
> When we say that mail systems that don't fit the DMARC threat profile
> shouldn't publish DMARC policies, we have good reasons to say so, and
> that's what our standards need to say if we're serious about
> interoperating.
>
> R's,
>
> On Apr 12, 2023, at 9:41 AM, John R Levine wrote:
>
> When we say that mail systems that don't fit the DMARC threat profile
> shouldn't publish DMARC policies, we have good reasons to say so, and that's
> what our standards need to say if we're serious about interoperating.
>
With
In the case of DNSSEC, my ISP is the intermediary utilizing DNSSEC, and the
website signs records via DNSSEC. The website I want to go to breaks their
DNSSEC. My ISP cannot retrieve a record to return to my browser that can be
used. A is the browser, B is the website, C is the ISP DNS
On Wed, Apr 12, 2023 at 6:31 AM Murray S. Kucherawy
wrote:
> To my mind, there's a substantial difference between something like TLSv1
> or HTTP whose deprecation excludes you from participating in something
> until you upgrade, versus the DMARC situation where because of an
> unfortunate
On Tue, 11 Apr 2023, Neil Anuskiewicz wrote:
If DMARC can protect domains from spoofing which I believe ends up
costing over $14 billion per year. Forget about the $14 billion and
think how this crime spree affects people’s view
But it obviously can't do that, and what it does do happens
On Wed, Apr 12, 2023 at 5:20 AM Brotman, Alex wrote:
> There is a non-zero set of cases where the IETF prefers security over
> interoperability. A document like RFC8997/8996 where we've deprecated
> TLSv1 in because it was no longer secure. I assure you there are still
> systems/users who have
On April 12, 2023 9:51:14 AM UTC, Alessandro Vesely wrote:
>On Wed 12/Apr/2023 10:35:06 +0200 Scott Kitterman wrote:
>>
>>
>> On April 12, 2023 7:27:12 AM UTC, Alessandro Vesely wrote:
>>> On Fri 07/Apr/2023 00:03:49 +0200 Scott Kitterman wrote:
On April 6, 2023 5:51:50 PM UTC,
There is a non-zero set of cases where the IETF prefers security over
interoperability. A document like RFC8997/8996 where we've deprecated TLSv1
in because it was no longer secure. I assure you there are still systems/users
who have devices incapable of TLSv1.2. DNSSEC (and things that
> On 12 Apr 2023, at 12:21, Douglas Foster
> wrote:
>
> Any form of security creates inconvenience.
Yes. And we make tradeoffs between that. In this case, the security is ensuring
that users at specific domains can and should only send mail through approved
channels managed by those
Any form of security creates inconvenience.
Based on the header rewriting done by IETF, I have a hard time seeing how
its rewrite of Comcast addresses can cause any of the problems that you
cite.
But does your domain require even headers toi be rewritten?Why doesn't
IETF ask you, and omit
Thank you for returning to the topic of stream identifiers. Email
filtering is not about single messages, it is about identifying and
classifying streams into high value (whitelist), low value (allow) and
unwanted (block).
I know existing filtering configurations that will conditionally block
On Wed 12/Apr/2023 07:10:26 +0200 Neil Anuskiewicz wrote:
On Apr 11, 2023, at 9:25 PM, Murray S. Kucherawy wrote:
On Tue, Apr 11, 2023 at 8:25 PM Neil Anuskiewicz wrote:
The standard and the document should reflect that it’s already making a
massive difference and could do even more.
The
> On 12 Apr 2023, at 10:45, Alessandro Vesely wrote:
>
> On Sun 09/Apr/2023 09:50:46 +0200 Murray S. Kucherawy wrote:
>> Mike Hammer asks, reasonably, whether an IETF standard containing a "MUST
>> NOT" that we know people will ignore calls into question the IETFs relevance
>> or legitimacy.
On Wed 12/Apr/2023 10:35:06 +0200 Scott Kitterman wrote:
On April 12, 2023 7:27:12 AM UTC, Alessandro Vesely wrote:
On Fri 07/Apr/2023 00:03:49 +0200 Scott Kitterman wrote:
On April 6, 2023 5:51:50 PM UTC, Alessandro Vesely wrote:
On Thu 06/Apr/2023 00:54:15 +0200 Seth Blank wrote:
I
On Sat 08/Apr/2023 23:27:26 +0200 Douglas Foster wrote:
Even when the recipient and the evaluator have a great working relationship,
neither party may understand what exceptions are needed for the messages from
every participant, current or future, to be accepted reliably. So the list
On Sun 09/Apr/2023 09:50:46 +0200 Murray S. Kucherawy wrote:
Mike Hammer asks, reasonably, whether an IETF standard containing a "MUST NOT"
that we know people will ignore calls into question the IETFs relevance or
legitimacy. But I submit that the IETF issuing a standards track document
On April 12, 2023 7:27:12 AM UTC, Alessandro Vesely wrote:
>On Fri 07/Apr/2023 00:03:49 +0200 Scott Kitterman wrote:
>> On April 6, 2023 5:51:50 PM UTC, Alessandro Vesely wrote:
>>> On Thu 06/Apr/2023 00:54:15 +0200 Seth Blank wrote:
I don't feel strongly about N=10, but I do feel
On Fri 07/Apr/2023 00:03:49 +0200 Scott Kitterman wrote:
On April 6, 2023 5:51:50 PM UTC, Alessandro Vesely wrote:
On Thu 06/Apr/2023 00:54:15 +0200 Seth Blank wrote:
I don't feel strongly about N=10, but I do feel strongly that N=5 is
insufficient. My gut feel is that 6 or 7 is likely more
30 matches
Mail list logo
