In article
you write:
>> "DISCUSS" shouldn't really be a joke. draft-crocker-dmarc-sender suffers
>from a similar problem as PRA in the SenderId draft. There is no way to
>validate that the specific intermediary is authorized by the (From) domain
>originating the email through it's generic
In article <2e5408af-c3c1-1b34-4600-70a355ef0...@bbiw.net> you write:
>I remember back then hearing various ideas or proposals and for many of
>them thinking "I've no idea whether that will be useful or successful
>but it sounds like something worth trying." Not so much these days. Alas.
I'm
On 8/13/2020 5:21 PM, Murray S. Kucherawy wrote:
I'm disappointed that the experiment never really got its day in court,
but the consensus is clear. +1.
30 years ago, there was a generally adventurous tone in the community.
Things are a lot more cautious now.
I remember back then hearing
On Thu, Aug 13, 2020 at 8:23 PM Murray S. Kucherawy
wrote:
> On Mon, Aug 10, 2020 at 12:05 PM Tim Wicinski wrote:
>
>> During IETF 108, the chairs realized that there was interest in Dave's
>> RFC5322.Sender draft.
>>
>> This starts a Call for Adoption for draft-crocker-dmarc-sender
>>
>> The
On Mon, Aug 10, 2020 at 12:05 PM Tim Wicinski wrote:
> During IETF 108, the chairs realized that there was interest in Dave's
> RFC5322.Sender draft.
>
> This starts a Call for Adoption for draft-crocker-dmarc-sender
>
> The draft is available here:
>
On Mon, Aug 10, 2020 at 10:27 AM Dave Crocker wrote:
> > We have had a lot of attempts at third-party authorization schemes
>
> > With this in mind, I cannot see any point in designing yet another
> > vouching or authorization scheme unless we have evidence that an
> > interesting fraction
In article
you write:
>-=-=-=-=-=-
>
>During IETF 108, the chairs realized that there was interest in Dave's
>RFC5322.Sender draft.
>
>This starts a Call for Adoption for draft-crocker-dmarc-sender
It needs some work but it's worth adopting.
I might do a review or two but you know how shy I
On 8/13/20 7:13 AM, Doug Foster wrote:
> My thinking is based on these foundations:
> - the incoming email gateway is an AAA server which conditionally allows
> anonymous logins
> - The NIST framework for digital identity. https://pages.nist.gov/800-63-3/
I fail to see how NIST SP 800-63-3
Yours is the better answer!DF
Original message
From: Dotzero Date:
8/13/20 5:54 PM (GMT-05:00) To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
On Thu, Aug 13, 2020 at 5:43 PM Kurt Andersen (b)
wrote:
> On Thu, Aug 13, 2020 at 2:33 PM Doug
On Thu, Aug 13, 2020 at 5:43 PM Kurt Andersen (b) wrote:
> On Thu, Aug 13, 2020 at 2:33 PM Doug Foster 40bayviewphysicians@dmarc.ietf.org> wrote:
>
>> The current DMARC architecture supports authorizing a vendor to mail on
>> behalf of their clients if the client includes them in their SPF
On Thu, Aug 13, 2020 at 2:33 PM Doug Foster wrote:
> The current DMARC architecture supports authorizing a vendor to mail on
> behalf of their clients if the client includes them in their SPF policy or
> delegates a DKIM scope to them and they use it.
>
>
>
> I agree that SPF is too limiting
On Thu, Aug 13, 2020 at 12:06 PM Neil Anuskiewicz
wrote:
>
> Tunable! You said the magic word I have a client now getting spoofing.
>
Receiving spoofed mail or having their domain *being* spoofed?
> My point is that it sure would be nice to be able to tune so that BigCRM
> and BigCRM
If I followed Neil’s discussion of MajorCRM:
The current DMARC architecture supports authorizing a vendor to mail on behalf
of their clients if the client includes them in their SPF policy or delegates a
DKIM scope to them and they use it.
I agree that SPF is too limiting (including hard
On Thu, Aug 13, 2020 at 12:21 PM Dotzero wrote:
>
>
> On Thu, Aug 13, 2020 at 3:06 PM Neil Anuskiewicz
> wrote:
>
>>
>>
>> Tunable! You said the magic word I have a client now getting spoofing.
>> Tightening above p=none is a non starter as about 100% of MajorCRM emails
>> fail SPF
On Thu, Aug 13, 2020 at 3:06 PM Neil Anuskiewicz
wrote:
>
>
> Tunable! You said the magic word I have a client now getting spoofing.
> Tightening above p=none is a non starter as about 100% of MajorCRM emails
> fail SPF (foo.majorcrm is the RFC5321.from), 62% of MajorCRM mail fails
> DKIM, and
On Thu, Aug 13, 2020 at 1:57 AM Alessandro Vesely wrote:
> On 2020-08-12 5:16 p.m., Steve Atkins wrote:
> > On 12/08/2020 04:32, Dave Crocker wrote:
> >>
> >> Here's why I think it won't: They already have From:.
> >>
> >> The real value in DMARC is not what is displayed to the end-user but
>
-Admittedly, that's where my bias comes in. My job is working with
organizations that have paid my employer for me to be that outside help, so
it's rare for me to see how badly it can be done by people setting restrictive
DMARC policies without knowing what they're doing.
If they all talked
In brief:
My thinking is based on these foundations:
- the incoming email gateway is an AAA server which conditionally allows
anonymous logins
- The NIST framework for digital identity. https://pages.nist.gov/800-63-3/
In that regard, digital identity is the focus, not human headcount.
On 2020-08-13 1:59 a.m., John Levine wrote:
In article <01d670ee$e38f8750$aaae95f0$@bayviewphysicians.com> you write:
The author fails to recognize that we have a single-author email
architecture. Consequently, the last entity to alter the message IS the
author.
Sorry, but no. The
"I do get the instinct to be proactive but if you’re going to be proactive, get
ready to take the time and, if outside help needed, the money to do it without
breaking legit mail."
-Admittedly, that's where my bias comes in. My job is working with
organizations that have paid my employer for
On 2020-08-12 5:16 p.m., Steve Atkins wrote:
On 12/08/2020 04:32, Dave Crocker wrote:
Here's why I think it won't: They already have From:.
The real value in DMARC is not what is displayed to the end-user but
in having a required field that cites the originating domain name.
That doesn't
On 2020-08-10 9:04 p.m., Tim Wicinski wrote:
This starts a Call for Adoption for draft-crocker-dmarc-sender
+1, the I-D needs work and coordination with other I-Ds by the WG.
Please also indicate if you are willing to contribute text, review, etc.
Yes, I will.
Best
Ale
--
22 matches
Mail list logo
