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 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.
T
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 problems
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 authentic
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
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 include
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 l
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 feelings.
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 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 do
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 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 enou
> 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 enou
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 by
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 wil
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
> at
> 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
> atta
> 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 domains
> 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 a
+1 to Doug's comments. I think an expected and desired state achievable in
the foreseeable future (based on the flows I see) is to require at least
some form of authentication (whether it's SPF, DKIM or ARC).
On Mon, Apr 10, 2023, 8:18 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote
20 matches
Mail list logo
