On Mon, Dec 14, 2020 at 10:26 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Sorry about the confusion caused by my typing failures.
> What I meant:
> First party - From address aligns with SMTP address. Can be validated
> with SPF or DKIM.
> Third party - From address and
On 12/14/20 7:26 PM, Douglas Foster wrote:
But what I am trying to figure out is under what circumstances a DMARC
policy can be considered actionable. Do I conclude that
"p=quarantine" means "domain is still collecting data, so results are
unpredictable"? Or do I conclude that it means
Sorry about the confusion caused by my typing failures.
What I meant:
First party - From address aligns with SMTP address. Can be validated with
SPF or DKIM.
Third party - From address and SMTP address are in different domains. Can
be validated with DKIM only.
I am open to suggestions for better
On Mon, Dec 14, 2020 at 11:10 AM Henning Krause wrote:
> Perhaps the first one is for the mail-from-domain and the other is for
> the EHLO host?
>
>
> > -Original Message-
> > From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Brotman, Alex
>
>
> >
> >
On 12/14/20 12:02 PM, Tim Wicinski wrote:
All
Can we please stop with the non constructive discussions here?
It would be helpful to just rule anything about the semantics of
p=reject as out of scope. It is what hijacked my original question for
which I haven't gotten an answer.
Mike
All
Can we please stop with the non constructive discussions here?
tim
On Mon, Dec 14, 2020 at 1:27 PM Michael Thomas wrote:
>
> On 12/14/20 10:09 AM, Dave Crocker wrote:
> > On 12/14/2020 10:00 AM, Michael Thomas wrote:
> >> When we tell you it's not a problem,
> >
> > Except that the
In article
you write:
>I'm seeing a report where the XML contains two SPF records within a single
>auth_results entity. This doesn't seem correct.
It's specifically allowed in the XML schema. In this case I'd guess it
is checking the From header domain, the org domain, and the bounce
On 12/14/20 10:09 AM, Dave Crocker wrote:
On 12/14/2020 10:00 AM, Michael Thomas wrote:
When we tell you it's not a problem,
Except that the telling was by you. Alone.
And you've yet to respond to the observable fact that receivers have
been ignoring the directive language.
Or that many
On 12/14/2020 10:00 AM, Michael Thomas wrote:
When we tell you it's not a problem,
Except that the telling was by you. Alone.
And you've yet to respond to the observable fact that receivers have
been ignoring the directive language.
Or that many folk misunderstand the semantics of DKIM,
On 12/14/20 8:12 AM, Dave Crocker wrote:
On 12/12/2020 10:57 AM, Michael Thomas wrote:
As a developer for 40 years, I can safely say that reject or
discardable or whatever it was in ssp are all abundantly clear and
that nobody writing a filter would make the error that you keep
insisting
On 12/14/2020 7:31 AM, Laura Atkins wrote:
I am agnostic about moving the ‘what to do’ section. I think it makes
sense to keep the sender definitions and the ways receivers can
interpret those declarations close together.
I'm pressing for clear separation because we've got an existing
On 12/12/2020 10:57 AM, Michael Thomas wrote:
As a developer for 40 years, I can safely say that reject or
discardable or whatever it was in ssp are all abundantly clear and
that nobody writing a filter would make the error that you keep
insisting that we would.
An appeal to authority? In
Perhaps the first one is for the mail-from-domain and the other is for the
EHLO host?
Kind regards,
Henning
> -Original Message-
> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Brotman, Alex
> Sent: Montag, 14. Dezember 2020 16:35
> To: dmarc@ietf.org
> Subject: [dmarc-ietf]
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
> -Original Message-
> From: John R Levine
> Sent: Friday, December 11, 2020 4:34 PM
> To: Brotman, Alex ; dmarc@ietf.org
> Subject: RE: [EXTERNAL] Re: [dmarc-ietf] Clarification of Subdomain
> Reporting
>
> On Fri,
I'm seeing a report where the XML contains two SPF records within a single
auth_results entity. This doesn't seem correct. I found this thread:
http://lists.dmarc.org/pipermail/dmarc-discuss/2016-April/003474.html and it
says it's a bug, though, I'm a bit surprised (guess I probably shouldn't
> On 14 Dec 2020, at 15:11, Douglas Foster
> wrote:
>
> I called that a third-party message, since the RFC5321.MailFrom domain is
> different from the RFC5322.From domain.
No, you didn’t.
Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From domain )
I think ‘first party’
> On 14 Dec 2020, at 15:10, Dave Crocker wrote:
>
> On 12/12/2020 10:51 AM, John R Levine wrote:
>> On Sat, 12 Dec 2020, Dave Crocker wrote:
p=reject: all mail sent from this domain should be aligned in a DMARC
compliant way. We believe that unaligned mail is from unauthorized
I called that a third-party message, since the RFC5321.MailFrom domain is
different from the RFC5322.From domain.
I am open to revisions of how the boundaries should be defined, but as I
said in my reply just now to Michael Hammer, we need to define those
boundaries in a way that both sender and
On 12/12/2020 10:51 AM, John R Levine wrote:
On Sat, 12 Dec 2020, Dave Crocker wrote:
p=reject: all mail sent from this domain should be aligned in a DMARC
compliant way. We believe that unaligned mail is from unauthorized
senders so we ask receivers to reject it, even though that might mean
On Sun, Dec 13, 2020 at 5:41 PM Dotzero wrote:
>
>
> On Sun, Dec 13, 2020 at 4:45 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> Based on this discussion, it seems evident that p=reject should include
>> language about in-transit modifications which are outside the
> On 13 Dec 2020, at 21:44, Douglas Foster
> wrote:
>
> Based on this discussion, it seems evident that p=reject should include
> language about in-transit modifications which are outside the control of the
> source domain, and consequently outside the ability of DMARC to guide
>
On Sat 12/Dec/2020 19:56:58 +0100 John Levine wrote:
> In article <6c5878e8-fdd8-05c0-3b60-ba180ecbc...@tana.it> you write:
>>Maybe it's me, but I don't understand the change below. The only difference
>>I
>>see between Old: and New: is the removal of «minOccurs="1"». Since that is
>>the
On Sat 12/Dec/2020 15:45:31 +0100 Dave Crocker wrote:
Repeating from the Abstract:
DMARC Builds on these protocols. DMARC permits the owner of an author's
domain name to enable validation of the domain's use, to indicate the
implication of failed validation, and to request reports
23 matches
Mail list logo
