> On Apr 10, 2023, at 9:38 PM, Neil Anuskiewicz wrote:
>
>
>
>>> On Apr 10, 2023, at 9:24 PM, Scott Kitterman wrote:
>>>
>>> On Tuesday, April 11, 2023 12:13:33 AM EDT Neil Anuskiewicz wrote:
>>> I’m a bit concerned that the document will discourage domain owners from
>>> working toward
> On Apr 10, 2023, at 9:24 PM, Scott Kitterman wrote:
>
> On Tuesday, April 11, 2023 12:13:33 AM EDT Neil Anuskiewicz wrote:
>> I’m a bit concerned that the document will discourage domain owners from
>> working toward an enforcing policy. I’ve seen at least one person say that
>> most
> On Apr 10, 2023, at 9:13 PM, Neil Anuskiewicz wrote:
>
> I’m a bit concerned that the document will discourage domain owners from
> working toward an enforcing policy. I’ve seen at least one person say that
> most domains don’t need to go to p=reject. I’ve seen all sorts of domains
>
On Tuesday, April 11, 2023 12:13:33 AM EDT Neil Anuskiewicz wrote:
> I’m a bit concerned that the document will discourage domain owners from
> working toward an enforcing policy. I’ve seen at least one person say that
> most domains don’t need to go to p=reject. I’ve seen all sorts of domains
>
I’m a bit concerned that the document will discourage domain owners from
working toward an enforcing policy. I’ve seen at least one person say that most
domains don’t need to go to p=reject. I’ve seen all sorts of domains attacked?
Granted, high profile domains or perceived lucrative targets
Hector, here is my take on the DSAP proposal. I am not sold.
DSAP notable features
1) DSAP policy can be used to identify and block non-mail subdomains of
registered domains.
This might be useful when mail-sending domains use p=(none|quarantine).
The equivalent result can achieved with DMARC
> On Apr 10, 2023, at 12:55 PM, Murray S. Kucherawy wrote:
>
> I think the one thing we haven't discussed is: Could the 80-20 rule apply
> here? That is, if we start off with something like what
> draft-kucherawy-dkim-transform proposed (or even a trivial subset of it),
> might it make
> On Apr 10, 2023, at 12:55 PM, Murray S. Kucherawy wrote:
>>
> I think the one thing we haven't discussed is: Could the 80-20 rule apply
> here? That is, if we start off with something like what
> draft-kucherawy-dkim-transform proposed (or even a trivial subset of it),
> might it make
On Mon, Apr 10, 2023 at 9:55 AM Murray S. Kucherawy
wrote:
> On Mon, Apr 10, 2023 at 8:15 AM John Levine wrote:
>
>> > For certain
>> >constrained but hopefully reasonable scenarios of mailing list
>> >modifications, we might be able to distinguish the sources of content.
>>
>> People have been
On Mon, Apr 10, 2023 at 8:15 AM John Levine wrote:
> It appears that Wei Chuang said:
> >1) We know that a sender intends to send a message down some path that may
> >include a mailing list, that got to me safely. This is to avoid DKIM
> >replay and FROM spoofing attacks.
>
> I think we can
I've thought about this a bit more; I could get behind "purpose> domains MUST NOT publish p=reject" (for interoperability) as
long as it is made clear the interoperability context for the "MUST NOT"
does not address the perceived security benefits of its current usage by
domain owners at large.
On Sun, Apr 9, 2023 at 3:27 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> All of which is why I sketched out a very different mailing list design.
> It's not my job or my agenda to sell it to people, not my job to build
> the product, and not my job to deal with hurt
On Mon, Apr 10, 2023 at 8:15 AM John Levine wrote:
> > For certain
> >constrained but hopefully reasonable scenarios of mailing list
> >modifications, we might be able to distinguish the sources of content.
>
> People have been suggesting this forwver, but it really doesn't scale.
> There are a
It appears that Wei Chuang said:
>1) We know that a sender intends to send a message down some path that may
>include a mailing list, that got to me safely. This is to avoid DKIM
>replay and FROM spoofing attacks.
I think we can do that by looking at the To/Cc addresses to check if
they
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 that role.
It's not a DMARC problem, it's a DKIM problem, I think.
No, it's
The AOL breach obviously just magnified a problem that was already in place
- impersonation is a useful attack vector. Email addresses do not have
restricted distribution, and they fall into the hands of unwanted senders
all the time.
We currently have a regime of semi-mandatory sender
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 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
On Sun 09/Apr/2023 20:33:54 +0200 Barry Leiba wrote:
There is an alternative, though: we can acknowledge that because of how those
deploying DMARC view their needs over interoperability, DMARC is not
appropriate as an IETF standard, and we abandon the effort to make it Proposed
Standard.
John Levine wrote on 2023-04-09 15:55:
When someone sets a DMARC policy for mail from people, it's hard to
think of a time when they asked at wll whether that was what the
people wanted. Or if they did, they asked something like "do you want
your mail to be more secure?" which misses the point.
On Sun, Apr 9, 2023 at 2:28 PM Murray S. Kucherawy
wrote:
> On Sun, Apr 9, 2023 at 2:07 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> As an evaluator, what I can accept is that "Some intermediaries could be
>> allowed to make some changes y do want unrestricto messages,
20 matches
Mail list logo
