Re: [dmarc-ietf] p=quarantine

[Dotzero]

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 SMTP address are in different domains.  Can
> be validated with DKIM only.
> I am open to suggestions for better nomenclature.
>
> 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 "Domain is fully deployed and failure to
> validate is a highly suspicious event?"
>

You are way overthinking this.

>
> Take the case of a SMTP-aligned message which does not have a DKIM
> signature.   If it is received directly, it is DMARC compliant.   If it is
> received indirectly, it is a presumed spoof.It cannot be both valid and
> spoofed.
>

Rather than using the word "spoofed", think of it as simply "failed to
validate" if it was forwarded. Done.


>  Whether the message gets forwarded is not under the sender's control.
>  If I receive it directly it is presumed valid, but does it signal that the
> domain is still struggling to implement DMARC, so their policy should be
> ignored on future messages?   Or if I receive it indirectly, should I try
> to reverse engineer whether it was SPF-aligned before it was forwarded?
>

You appear to be venturing into an area that involves tea leaves and
crystal balls - way beyond anything a technical standard can address. An
organization publishing a p=quarantine record is making a request that
messages purporting to be from their domain be quarantined if they fail to
validate. It doesn't matter whether it was sent direct or was handled by an
intermediary. Even a certain (very small) percentage of emails sent
directly can fail for various reasons. Why is it so difficult to take
things at face value? If, as a validating receiver you have data that you
believe justifies exercising local policy then you have a choice to make.
It really is that simple.

>
> Since all messages need to be DKIM-signed to survive a possible forward,
> should SPF even be part of the DMARC criteria?
>

Yes, SPF should be a part of DMARC because even with direct mail there can
be problems with DKIM signing/signatures for various reasons. The
combination of SPF and DKIM signing provides a small but useful increase in
the percentage of mail that validates. This statement is based on my
experience of having been responsible for systems sending several billions
of emails with a p=reject policy.

>
> I am simply wondering if a DMARC policy has enough reliable information to
> be of any value, at least for any setting other than p=reject pct=100.
> This is intertwined with the ambiguity about what the sender means for any
> policy other than p=reject pct=100.   My opening post was an attempt to
> define milestones that should be associated with specific settings.   But
> maybe the only certainty is that the domain is collecting data and
> consequently spoof-prevention must be based on evidence other than the
> DMARC policy.
>

Again, "spoofing" is a convenient but inaccurate descriptor.  DMARC is a
tool intended to prevent direct domain abuse based on the RFC 5322 From
email address, nothing more and nothing less. Even if an email message
validates for DMARC, it could be a homoglyph or cousin domain email address
in the RFC 5322 field. Attempting to overlay the meaning of a published
policy with other semantics or trying to guess the underlying intentions is
a perilous path for a standards body. Other tools and techniques can and
should be applied to messages by Receivers in order to protect their users.

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] p=quarantine

[Michael Thomas]

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 "Domain is fully 
deployed and failure to validate is a highly suspicious event?"



Yeah, that's why I question whether there is something actionable and 
whether this is so much wishful thinking. Somebody did say that they 
took action on it (gmail?), but i'm not sure whether that is a good 
thing or a bad thing. For mailing lists, that would seemingly be a bad 
thing, but if you're of the mind that mailing lists are a security bug 
and not a feature that might be contradictory.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] p=quarantine

[Douglas Foster]

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 nomenclature.

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 "Domain is fully deployed and failure to
validate is a highly suspicious event?"

Take the case of a SMTP-aligned message which does not have a DKIM
signature.   If it is received directly, it is DMARC compliant.   If it is
received indirectly, it is a presumed spoof.It cannot be both valid and
spoofed.   Whether the message gets forwarded is not under the sender's
control.   If I receive it directly it is presumed valid, but does it
signal that the domain is still struggling to implement DMARC, so their
policy should be ignored on future messages?   Or if I receive it
indirectly, should I try to reverse engineer whether it was SPF-aligned
before it was forwarded?
Since all messages need to be DKIM-signed to survive a possible forward,
should SPF even be part of the DMARC criteria?

I am simply wondering if a DMARC policy has enough reliable information to
be of any value, at least for any setting other than p=reject pct=100.
This is intertwined with the ambiguity about what the sender means for any
policy other than p=reject pct=100.   My opening post was an attempt to
define milestones that should be associated with specific settings.   But
maybe the only certainty is that the domain is collecting data and
consequently spoof-prevention must be based on evidence other than the
DMARC policy.

DF


On Mon, Dec 14, 2020 at 10:36 AM Laura Atkins 
wrote:

>
>
> On 14 Dec 2020, at 15:11, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> 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’ and ’third-party’ are problematic definitions in any
> case and I’m not sure I understand what your goal is here. Who are you
> considering ‘party’?
>
> laura
>
> 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 receiver understand.  This is the
> full problem description:
>
> We have these three types of senders:
> - first-party senders
>
>
> - third-party senders
> - spoofers
>
> We have these four verification states at initial transmission:
> - none
> - spf only
> - dkim only
> - spf and dkim
>
> We have these 9 routing scenarios:
> - direct (1)
> - indirect (8)
> with and without SMTP rewrite
> with and without FROM rewrite
> with and without content modifications
>
> Upon receipt, we have these verification states:
> - Not verified
> - SPF only
> - DKIM only
> - SPF and DKIM
>
> For messages that do not verify, the evaluator uses sender policy (none,
> quarantine, reject) to categorize the message as either "verifiably
> spoofed" or "uncertain".   What is the algorithm for doing so?
>
> DF
>
>
> On Mon, Dec 14, 2020 at 5:05 AM Laura Atkins 
> wrote:
>
>>
>>
>> On 13 Dec 2020, at 21:44, 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 control of
>> the source domain, and consequently outside the ability of DMARC to guide
>> recipients.Extending from that, I thought it would be helpful to
>> specify some shared assumptions between sender and evaluator to make the
>> interpretation of the settings less subjective.   I call this the "Minimum
>> expected implementation at pct=100".
>>
>>
>> What about messages which do not have SPF verification but do have DKIM
>> verification? A significant number of email platforms use their own domains
>> in the 5321.from address but have the customer sign with DKIM. In many
>> cases, DKIM signing is actually free, whereas making the SPF align is a
>> paid service.
>>
>> p=none
>> Minimum expected implementation at pct=100:
>> All first-party direct messages (RFC5321.MailFrom domain = RFC5322.From
>> domain) are verifiable using SPF, but may not have a DKIM signature.
>> Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From
>> domain ) may or may not have DKIM signatures.
>> Consequently, indirect messages are often not verifiable using DMARC.
>>
>>
>> p=quarantine
>> Minimum expected implementation at pct=100:
>> All first-party direct messages (RFC5321.MailFrom domain = RFC5322.From
>> domain) are 

Re: [dmarc-ietf] Multiple SPF in a single auth_results

[Todd Herr]

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
>
>
> >  
> > bounce.email.peacocktv.com
> > pass
> >  
> >  
> > mta-218-134.sparkpostmail.com.
> > none
> >  
>

 I would tend to agree with Herr Krause, based on what I remember about
SparkPost's host naming convention and such.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 703.220.4153


This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] p=quarantine

[Michael Thomas]

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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] p=quarantine

[Tim Wicinski]

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 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, thinking it
> > means that message authorship is validated.
> >
>
> I'll ignore the whataboutism, but point out that you have never produced
> one piece of evidence where the language of p=reject or any of the other
> previous labels has caused software design decisions to change for the
> worst. I don't even know what would qualify as a mistake. So yes, I'll
> take my direct experience of writing code over your indirect innuendo
> any day.
>
> Mike
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Multiple SPF in a single auth_results

[John Levine]

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
address. I see that bounce.email.peacocktv.com is a CNAME for
sparkpostmail.com so it's plausible.

Checking all those things seems useless but that doesn't mean it's forbidden.

R's,
John

>  
> 
>email.peacocktv.com
>pass
> 
> 
>bounce.email.peacocktv.com
>pass
> 
> 
>mta-218-134.sparkpostmail.com.
>none
> 
>  

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] p=quarantine

[Michael Thomas]

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 folk misunderstand the semantics of DKIM, thinking it 
means that message authorship is validated.




I'll ignore the whataboutism, but point out that you have never produced 
one piece of evidence where the language of p=reject or any of the other 
previous labels has caused software design decisions to change for the 
worst. I don't even know what would qualify as a mistake. So yes, I'll 
take my direct experience of writing code over your indirect innuendo 
any day.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] p=quarantine

[Dave Crocker]

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, thinking it means 
that message authorship is validated.


Or...

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] p=quarantine

[Michael Thomas]

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 that we would.


An appeal to authority?  In this group?  Really?

So that means that my citing 50 years of writing this kind of 
networking standard and seeing exactly the kinds of misinterpretation 
I'm expressing concern about carries more sway than your own 
experience (which I suspect is a lot less than 40 years of writing 
specifications for the public Internet, as to writing them for more 
constrained environments.)


And the above is mostly meant to serve as a demonstration of just how 
inappropriate an appeal to authority is, here.




Yes. I and developers like me are the target audience, not you. When we 
tell you it's not a problem, you should listen to us rather than badger 
us and tell us you know better. You have wasted years litigating a 
non-problem, and continue to litigate conversational speech as if it 
were some gigantic problem that will never be solved unless the world 
over uses some never quite precise enough language. p=reject is 
completely clear what its meaning and intent are. This is a waste of 
time, and a major symptom of why IETF is considered sclerotic and to be 
avoided if possible.


I started this thread about p=quarantine, not p=reject as the subject 
makes abundantly clear. If you want to relitigate p=reject, kindly 
create your own thread so I can more easily ignore it, and the chairs 
can rule as out of scope because there is no ticket.


Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] p=quarantine

[Dave Crocker]

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 problem 
-- and DMARC isn't even close to the first case of this -- where people 
over-interpret the meaning of non-normative information.


So, I think that 'close together', as in 'in the same document', is fine 
and even good.  I think that  as in 'in the same paragraph' or even 'in 
the same section' is not.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] p=quarantine

[Dave Crocker]

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 this group?  Really?

So that means that my citing 50 years of writing this kind of networking 
standard and seeing exactly the kinds of misinterpretation I'm 
expressing concern about carries more sway than your own experience 
(which I suspect is a lot less than 40 years of writing specifications 
for the public Internet, as to writing them for more constrained 
environments.)


And the above is mostly meant to serve as a demonstration of just how 
inappropriate an appeal to authority is, here.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Multiple SPF in a single auth_results

[Henning Krause]

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] Multiple SPF in a single auth_results
> 
> 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:
> https://stack01.cloud.nospamproxy.com/link?id=BAgfpHeh4JGMq5wA
> AABTUQz3QBhcskBhLXvN_sPByIkTUJ_191QbNMs1tjGZXePYW51PlsXJiHzgxa
> 2k95gYKyEvascW0xCd7vkfXGIcW-SMik1X4yMySldQ-
> qHoCA66NmA7TaPPuwEtF7ZPQYLlZqdD7I5R3KNSFh2RaMp6bqp2L8XhNLlAJK
> uMYUKvKSh3RMIePwJj3aMWZVgoSUPgaHbNCkaiscGIUps1  and it says it's a
> bug, though, I'm a bit surprised (guess I probably shouldn't be) that this is 
> still
> happening.  Is there some part of the RFC that makes this appear like it's a
> legitimate report that could be misconstrued?  Is this something that should
> perhaps be clarified?
> 
>   
>  
> email.peacocktv.com
> pass
>  
>  
> bounce.email.peacocktv.com
> pass
>  
>  
> mta-218-134.sparkpostmail.com.
> none
>  
>   
> 
> Thanks
> 
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy Comcast
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] [EXTERNAL] Re: Clarification of Subdomain Reporting

[Brotman, Alex]

--
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, 11 Dec 2020, Brotman, Alex wrote:
> >> That's a somewhat incompatible change, so I'd want to be sure we
> >> agree that it's a real problem that's worth changing the report
> >> format. I suppose if we do we should encourage report consumers to be
> prepared for old and new formats.
> >
> > The goal was to clarify the language, without (to the best of our ability)
> changing the schema.  I'd welcome a other attempts at clarifications (if you
> believe mine introduces structural XML changes).
>
> So it'd say yeah, we know the XML lets you put multiple header_from
> domains in the same report row, but please don't do that, send a separate
> report row for each header_from?
>
> I suppose that could work.

So it should be clarified as such:

   o  Data for each Domain Owner's subdomain separately from mail from
  the sender's Organizational Domain, even if there is no explicit
  subdomain policy

Perhaps changed to something more like:

  o A separate report should be generated for each 5322.From subdomain, 
regardless
  of which policy domain was used during receipt of messages

For the other thread with Ale, is there anything wrong with stating both 
minOccurs/maxOccurs set at "1" so that it's more clear that it must be once, 
and only once?

>
> R's,
> John
>
> >>
> >>  
> >>
> >> >>minOccurs="0"/>
> >>
> >> >>minOccurs="1"/>
> >> Old:
> >>
> >> >>minOccurs="1"/>
> >>
> >> New:
> >>
> >>
> >>
> >>  
> >>
> >
>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
> https://urldefense.com/v3/__https://jl.ly__;!!CQl3mcHX2A!UPJ_XPLNAqIcy
> 2hcn14oeuebDZfD_i2QOE4Z0FhOoQemEIHEyov_kFTxybH4FE6WvlDw$

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Multiple SPF in a single auth_results

[Brotman, Alex]

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 be) 
that this is still happening.  Is there some part of the RFC that makes this 
appear like it's a legitimate report that could be misconstrued?  Is this 
something that should perhaps be clarified?

  
 
email.peacocktv.com
pass
 
 
bounce.email.peacocktv.com
pass
 
 
mta-218-134.sparkpostmail.com.
none
 
  

Thanks

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] p=quarantine

[Laura Atkins]

> 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’ and ’third-party’ are problematic definitions in any case 
and I’m not sure I understand what your goal is here. Who are you considering 
‘party’?

laura

> 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 receiver understand.  This is the full problem 
> description:
> 
> We have these three types of senders:
> - first-party senders

> - third-party senders
> - spoofers
> 
> We have these four verification states at initial transmission:
> - none
> - spf only
> - dkim only
> - spf and dkim
> 
> We have these 9 routing scenarios:
> - direct (1)
> - indirect (8)
> with and without SMTP rewrite
> with and without FROM rewrite
> with and without content modifications
> 
> Upon receipt, we have these verification states:
> - Not verified
> - SPF only
> - DKIM only
> - SPF and DKIM
> 
> For messages that do not verify, the evaluator uses sender policy (none, 
> quarantine, reject) to categorize the message as either "verifiably spoofed" 
> or "uncertain".   What is the algorithm for doing so?
> 
> DF
> 
> 
> On Mon, Dec 14, 2020 at 5:05 AM Laura Atkins  > wrote:
> 
> 
>> 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 
>> recipients.Extending from that, I thought it would be helpful to specify 
>> some shared assumptions between sender and evaluator to make the 
>> interpretation of the settings less subjective.   I call this the "Minimum 
>> expected implementation at pct=100".
> 
> What about messages which do not have SPF verification but do have DKIM 
> verification? A significant number of email platforms use their own domains 
> in the 5321.from address but have the customer sign with DKIM. In many cases, 
> DKIM signing is actually free, whereas making the SPF align is a paid 
> service. 
> 
>> p=none
>> Minimum expected implementation at pct=100:
>> All first-party direct messages (RFC5321.MailFrom domain = RFC5322.From 
>> domain) are verifiable using SPF, but may not have a DKIM signature.
>> Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From domain 
>> ) may or may not have DKIM signatures.
>> Consequently, indirect messages are often not verifiable using DMARC.
> 
>> p=quarantine
>> Minimum expected implementation at pct=100:
>> All first-party direct messages (RFC5321.MailFrom domain = RFC5322.From 
>> domain) are verifiable using SPF, but may not have a DKIM signature.
>> Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From domain 
>> ) are verifiable using DKIM signatures.
>> Consequently, indirect messages may or may not be verifiable, depending 
>> whether the forwarded message included a signature.
>> 
>> p=reject
>> Minimum expected implementation at pct=100:
>> All first-party direct messages (RFC5321.MailFrom domain matches 
>> RFC5322.From domain) are verifiable using SPF and DKIM.
>> Third-party direct messages ( RFC5321.MailFrom domain does not match 
>> RFC5322.From domain ) are verifiable using DKIM signatures.
>> Indirect messages which are not modified in transit are verifiable using 
>> DKIM signatures.
>> Indirect messages which are modified in transit are outside the scope of 
>> DMARC and must be evaluated by other criteria available to the recipient 
>> system.
>> 
>> Having defined the policies/categories in these terms, the logical next step 
>> would be a best practices document which discusses how an evaluator might 
>> distinguish between direct messages, indirect unmodified messages, and 
>> indirect modified messages.   ARC obviously plays a role in making these 
>> distinctions easier to determine and less error-prone.
>> 
>> Doug Foster
>>  
>> 
>> On Sat, Dec 12, 2020 at 1:42 PM Dave Crocker > > wrote:
>> On 12/11/2020 9:37 AM, John Levine wrote:
>> > In article <1ac986ff-507b-4917-9c6d-d84e9337f...@wordtothewise.com 
>> > > you write:
>> > aligned is not authorized by the domain owner and may be discarded or 
>> > rejected by the recipient.
>> > Naah.
>> >
>> > 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
>> 

Re: [dmarc-ietf] p=quarantine

[Laura Atkins]

> 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
 senders so we ask receivers to reject it, even though that might mean
 some of our authorized senders' mail is rejected too.
>>> 
>>> As soon as this specification text, here, contains language about how this 
>>> information is to be used, should be used, or could be used, it crosses 
>>> over into creating confusion about expectations of receiver handling.
>> 
>> I agree with you, which is why I said "believe" and "request".
> 
> Except that that runs contrary to my point, rather than being compatible with 
> it.
> 
> Any an all discussion of receiver /use/ of DMARC needs to be moved to a 
> separate section and it needs to refrain from any linguistic form that 
> characterizes
> that use as being in response to domain owner desires.

‘As a matter of policy we treat all unaligned mail as unauthorized use of our 
domain.’ 

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. 

>> If we're going to have any description of p=none at all it needs to 
>> emphasize the point that it's telling you that they consider the messages 
>> unusually unimportant.  This appears to be at odds with what some DMARC 
>> users believe.
> 
> It isn't about the 'importance' of the messages.  It is about the domain 
> owner's view of the implication of the success or failure of DMARC validation.

The current p=reject is that the domain owner’s view is that the mail is 
unauthorized. And, according to discussion here on the IETF list, we are to 
presume that every domain owner knows exactly what they are doing and that 
every company understands the implications of a p=reject policy statement. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] p=quarantine

[Douglas Foster]

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 receiver understand.  This is the
full problem description:

We have these three types of senders:
- first-party senders
- third-party senders
- spoofers

We have these four verification states at initial transmission:
- none
- spf only
- dkim only
- spf and dkim

We have these 9 routing scenarios:
- direct (1)
- indirect (8)
with and without SMTP rewrite
with and without FROM rewrite
with and without content modifications

Upon receipt, we have these verification states:
- Not verified
- SPF only
- DKIM only
- SPF and DKIM

For messages that do not verify, the evaluator uses sender policy (none,
quarantine, reject) to categorize the message as either "verifiably
spoofed" or "uncertain".   What is the algorithm for doing so?

DF


On Mon, Dec 14, 2020 at 5:05 AM Laura Atkins 
wrote:

>
>
> On 13 Dec 2020, at 21:44, 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 control of
> the source domain, and consequently outside the ability of DMARC to guide
> recipients.Extending from that, I thought it would be helpful to
> specify some shared assumptions between sender and evaluator to make the
> interpretation of the settings less subjective.   I call this the "Minimum
> expected implementation at pct=100".
>
>
> What about messages which do not have SPF verification but do have DKIM
> verification? A significant number of email platforms use their own domains
> in the 5321.from address but have the customer sign with DKIM. In many
> cases, DKIM signing is actually free, whereas making the SPF align is a
> paid service.
>
> p=none
> Minimum expected implementation at pct=100:
> All first-party direct messages (RFC5321.MailFrom domain = RFC5322.From
> domain) are verifiable using SPF, but may not have a DKIM signature.
> Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From
> domain ) may or may not have DKIM signatures.
> Consequently, indirect messages are often not verifiable using DMARC.
>
>
> p=quarantine
> Minimum expected implementation at pct=100:
> All first-party direct messages (RFC5321.MailFrom domain = RFC5322.From
> domain) are verifiable using SPF, but may not have a DKIM signature.
> Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From
> domain ) are verifiable using DKIM signatures.
> Consequently, indirect messages may or may not be verifiable, depending
> whether the forwarded message included a signature.
>
> p=reject
> Minimum expected implementation at pct=100:
> All first-party direct messages (RFC5321.MailFrom domain matches
> RFC5322.From domain) are verifiable using SPF and DKIM.
> Third-party direct messages ( RFC5321.MailFrom domain does not match
> RFC5322.From domain ) are verifiable using DKIM signatures.
> Indirect messages which are not modified in transit are verifiable using
> DKIM signatures.
> Indirect messages which are modified in transit are outside the scope of
> DMARC and must be evaluated by other criteria available to the recipient
> system.
>
> Having defined the policies/categories in these terms, the logical next
> step would be a best practices document which discusses how an evaluator
> might distinguish between direct messages, indirect unmodified messages,
> and indirect modified messages.   ARC obviously plays a role in making
> these distinctions easier to determine and less error-prone.
>
> Doug Foster
>
>
> On Sat, Dec 12, 2020 at 1:42 PM Dave Crocker  wrote:
>
>> On 12/11/2020 9:37 AM, John Levine wrote:
>> > In article <1ac986ff-507b-4917-9c6d-d84e9337f...@wordtothewise.com>
>> you write:
>> > aligned is not authorized by the domain owner and may be discarded or
>> rejected by the recipient.
>> > Naah.
>> >
>> > 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
>> > some of our authorized senders' mail is rejected too.
>>
>>
>> As soon as this specification text, here, contains language about how
>> this information is to be used, should be used, or could be used, it
>> crosses over into creating confusion about expectations of receiver
>> handling.
>>
>> It encourages misguided language such as the receiver 'overriding'
>> sender policy.  The sender has no policies about receiver behavior,
>> because there is no relationship between them. Using milder language
>> here doesn't help, because readers typically do not read like legal or
>> technical scholars.
>>
>> DMARC provides information, not 

Re: [dmarc-ietf] p=quarantine

[Dave Crocker]

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
some of our authorized senders' mail is rejected too.


As soon as this specification text, here, contains language about how 
this information is to be used, should be used, or could be used, it 
crosses over into creating confusion about expectations of receiver 
handling.


I agree with you, which is why I said "believe" and "request".


Except that that runs contrary to my point, rather than being compatible 
with it.


Any an all discussion of receiver /use/ of DMARC needs to be moved to a 
separate section and it needs to refrain from any linguistic form that 
characterizes that use as being in response to domain owner desires.





If we're going to have any description of p=none at all it needs to 
emphasize the point that it's telling you that they consider the 
messages unusually unimportant.  This appears to be at odds with what 
some DMARC users believe.


It isn't about the 'importance' of the messages.  It is about the domain 
owner's view of the implication of the success or failure of DMARC 
validation.


d/


--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] p=quarantine

[Douglas Foster]

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 control of
>> the source domain, and consequently outside the ability of DMARC to guide
>> recipients.
>>
>
> And the buzzer goes off. Sources and modifications outside the control of
> the domain in the RFC 5322 From is exactly what DMARC is addressing. That
> is exactly the guidance that is being provided by a domain publishing a
> DMARC record.
>

Do you mean that DMARC p=reject intends to block mailing lists that do
content alterations, so there is not a mailing list problem at all?


>
>

>> Extending from that, I thought it would be helpful to specify some shared
>> assumptions between sender and evaluator to make the interpretation of the
>> settings less subjective.   I call this the "Minimum expected
>> implementation at pct=100".
>>
>
> "Shared assumptions" is a poor assumption in writing a technical standard
> for interoperability.
>

Then change the language to SHOULD and make it a requirement.   Here is the
point:

Sender policy is intended to help the evaluator divide incoming messages
into three groups:
- verifiably sent by the From domain
- uncertain
- verifiably NOT sent by the From domain (spoofed)

The evaluator has two results to work from:   Verified or Not Verified.
 Sender policy provides guidance for splitting the unverified messages
between "uncertain" and "spoofed" by providing information about which
messages SHOULD be verifiable. This is inherently a communication
protocol and it has not been well defined, which is why the question has
been raised, "What does p=quarantine actually mean?"   It is a derivative
of the earlier Chair question, "what does it  mean to implement DMARC?"

One could argue that anything other than "p=reject pct=100" is a non-policy
which provides no useful guidance, equivalent to the SPF token ?ALL.   But
then we have the mailing list problem, so even at "p=reject pct=100" we
have a problem with false positives (messages actually sent by the source
domain but not verifiable because of in-transit changes.)   So maybe DMARC
has no ability to distinguish between spoofed and unverifiable messages.

What seems useful is to define the capabilties and the limitations of
DMARC, then define a signalling protocol so that the sender correctly
signals which messages are DMARC-protected and the evaluator understands
that signal in a manner which can be applied to an incoming message.I
do not see that we have such a protocol at present.   Rather, the evaluator
is left with a lot of guesswork,and that means that the source domain owner
is left with a lot of guesswork about how the recipients will make
their guesses.

DF
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] p=quarantine

[Laura Atkins]

> 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 
> recipients.Extending from that, I thought it would be helpful to specify 
> some shared assumptions between sender and evaluator to make the 
> interpretation of the settings less subjective.   I call this the "Minimum 
> expected implementation at pct=100".

What about messages which do not have SPF verification but do have DKIM 
verification? A significant number of email platforms use their own domains in 
the 5321.from address but have the customer sign with DKIM. In many cases, DKIM 
signing is actually free, whereas making the SPF align is a paid service. 

> p=none
> Minimum expected implementation at pct=100:
> All first-party direct messages (RFC5321.MailFrom domain = RFC5322.From 
> domain) are verifiable using SPF, but may not have a DKIM signature.
> Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From domain ) 
> may or may not have DKIM signatures.
> Consequently, indirect messages are often not verifiable using DMARC.

> p=quarantine
> Minimum expected implementation at pct=100:
> All first-party direct messages (RFC5321.MailFrom domain = RFC5322.From 
> domain) are verifiable using SPF, but may not have a DKIM signature.
> Third-party direct messages ( RFC5321.MailFrom domain = RFC5322.From domain ) 
> are verifiable using DKIM signatures.
> Consequently, indirect messages may or may not be verifiable, depending 
> whether the forwarded message included a signature.
> 
> p=reject
> Minimum expected implementation at pct=100:
> All first-party direct messages (RFC5321.MailFrom domain matches RFC5322.From 
> domain) are verifiable using SPF and DKIM.
> Third-party direct messages ( RFC5321.MailFrom domain does not match 
> RFC5322.From domain ) are verifiable using DKIM signatures.
> Indirect messages which are not modified in transit are verifiable using DKIM 
> signatures.
> Indirect messages which are modified in transit are outside the scope of 
> DMARC and must be evaluated by other criteria available to the recipient 
> system.
> 
> Having defined the policies/categories in these terms, the logical next step 
> would be a best practices document which discusses how an evaluator might 
> distinguish between direct messages, indirect unmodified messages, and 
> indirect modified messages.   ARC obviously plays a role in making these 
> distinctions easier to determine and less error-prone.
> 
> Doug Foster
>  
> 
> On Sat, Dec 12, 2020 at 1:42 PM Dave Crocker  > wrote:
> On 12/11/2020 9:37 AM, John Levine wrote:
> > In article <1ac986ff-507b-4917-9c6d-d84e9337f...@wordtothewise.com 
> > > you write:
> > aligned is not authorized by the domain owner and may be discarded or 
> > rejected by the recipient.
> > Naah.
> >
> > 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
> > some of our authorized senders' mail is rejected too.
> 
> 
> As soon as this specification text, here, contains language about how 
> this information is to be used, should be used, or could be used, it 
> crosses over into creating confusion about expectations of receiver 
> handling.
> 
> It encourages misguided language such as the receiver 'overriding' 
> sender policy.  The sender has no policies about receiver behavior, 
> because there is no relationship between them. Using milder language 
> here doesn't help, because readers typically do not read like legal or 
> technical scholars.
> 
> DMARC provides information, not direction.
> 
> The spec already contains misguided perspective by talking about 
> 'policy' records and, even worse, "policy enforcement considerations".
> 
> If the document must contain language about receiver choices in message 
> disposition, move it to an overtly non-normative discussion section that 
> legitimately covers a wide range of things that receivers do or don't do 
> (cast as things they might or might not do.)  And make sure none of the 
> language hints at sender 'policy', overrides, or the like.
> 
> 
> d/
> 
> -- 
> Dave Crocker
> dcroc...@gmail.com 
> 408.329.0791
> 
> Volunteer, Silicon Valley Chapter
> American Red Cross
> dave.crock...@redcross.org 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org 
> https://www.ietf.org/mailman/listinfo/dmarc 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> 

Re: [dmarc-ietf] Clarification of Subdomain Reporting

[Alessandro Vesely]

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 
>>default value, I see no incompatibility.  What am I missing?
> 
> If there is neither minOccurs nor maxOccurs, the field occurs exactly once.


I agree that specifying «minOccurs="1"» is redundant and could be avoided.


Best
Ale


>>> 
>>>   
>>> 
>>> >> minOccurs="0"/>
>>> 
>>> >> minOccurs="1"/>
>>> Old:
>>> 
>>> >> minOccurs="1"/>
>>> 
>>> New:
>>> 
>>> 
>>> 
>>>   
>>> 

-- 
http://www.chrismadden.co.uk/cartoon-gallery/occams-razor-ockhams-razor-too-complicated/

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposed Introduction and Abstract (was I-D Action: draft-ietf-dmarc-dmarcbis-00.txt)

[Alessandro Vesely]

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 about use of the
domain name. Mail receiving organizations can use this information when
evaluating disposition choices for incoming mail.

The 'domain' in ADMD is not the same as in 'domain name' and, arguably, DMARC 
has nothing to do with ADMDs, but only with domain names.  This is an important 
distinction.  The linkage between the two comes from operational arrangement, 
not anything inherent in DMARC.  I'm not sure how to reflect this fact in the 
text. /d



I find the phrase "owner of an author's domain name" rather ungraceful.  In all 
of its length, it doesn't contain the word "mail".  Couldn't we call it just 
the *mail domain*, the thing after the at-sign?  The concept is so common that 
hardly needs using multiple words to indicate it.


ADMD is a declining term, possibly confused with x'400 stuff (see ngram).  I'd 
rather stick to *Organizational Domain*.



Best
Ale

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc