Re: [dmarc-ietf] p=quarantine

[Alessandro Vesely]

On Tue 22/Dec/2020 16:41:43 +0100 Todd Herr wrote:

On Mon, Dec 21, 2020 at 12:47 PM Alessandro Vesely  wrote:

On Sun 20/Dec/2020 18:10:03 +0100 Todd Herr wrote:


Lists are a specific instance of the more general case of indirect mail
flows. >>

How many kinds of indirect mail flows do rewrite From:?

Specific methods might prove more effective than general ones.


Sender Rewriting Scheme (SRS) exists for the rewriting of the RFC5321.From
address, and is sometimes used in mail that is forwarded by rule, say from
@alum.institution.edu to @consumerMailboxProvider.com



VERP as done by MLMs is more specific (and better thought) than generic SRS.  I 
don't have numbers but off the top of my head I'd reckon MLMs cover a major 
part of RFC5321.From rewriters.  If you additionally select by RFC5322.From 
rewriting, I'd guess you're left with exactly MLMs.




It seems to me that we can either work to find a way to ensure that
[forwarding] failures don't happen, or we can work to find a reliable and 
trustworthy way to record authentication results along the way so that the 
failures can be mitigated and not result in failed delivery of wanted mail.


Actually, people seem to be doing both.  Avoiding gratuitous autoconversions, 
anti-virus results as footers, and the like, have become a must for most modern 
MTA software.  And there are several mailing lists which operate that way as 
well.  OTOH, modifications are sometimes unavoidable and we still need to cope.




Since the receiver typically can't perform the same checks under the
same conditions that existed when the intermediary performed them (if it
could, we wouldn't need something like ARC) then the receiver has to
decide if the message is consistent with messages it's previously seen
through direct mail flows using that same authenticated identity that
was captured by the intermediary in the ARC header set. >>
Doesn't that assume some kind of omniscience at the receiver's? 
Consistency with previous messages by the same source is not

straightforward.  Using the same selector?  Signing more or less the same
set of header fields? Choice of vocabulary?  HTML vs. plain text style
(e.g. line length)?  A.I.? >

Not omniscience, no, but certainly a method of tracking an authenticated
identity's reputation, and consistency of reputation is what I'm speaking
of. Allow me to try again to get across the idea that I'm so far failing to
make clear.

I'm not currently working for a mailbox provider, but I have in the past,
and so I will role play as one here.

As a mailbox provider, I have a system for authenticating the identity or
identities associated with messages that come directly to me.

These authenticated identities can include some or all of:

- The DKIM signing domain(s)
- The DKIM signing domain(s) and selector(s)
- The RFC5322.From domain (authenticated using DMARC)
- The RFC5321.From domain (SPF)
- The IP address of the client that passed the message to me
- The domain associated with the PTR record of that IP address
- Others as I deem useful



Except for PTR records, that's the data I collect to send out aggregate reports.



For each of these authenticated identities, I can and will track how my
users/customers/mailbox holders engage with the mail they receive, thus
over time establishing in my system a reputation to associate with each
authenticated identity. If, for example, mail that is DKIM signed using
selector S and domain D is mail that my users demonstrate through their
actions (opening it, clicking on links in it, etc.) is wanted mail, then
that authenticated identity (S._domainkey.D) will be associated with a good
reputation (however I define "good") in my system. Lather, rinse, and
repeat for other authenticated identities associated with the message, and
allow that both good and bad reputations can be earned.



That's a delicate job.  For one point, 20161025._domainkey.gmail.com is not the 
kind of identifier you want to associate with users' liking, as it is shared 
among so many messages with diverging characteristics.  For another point, 
there are domains that change selector very often (taugh.com changes it on 
every message), so it can identify too narrow a message set.


Characterizing by author (a.k.a. RFC5322.From) probably works better.  An 
author authenticated by her submission server (a.k.a. author's domain) looks 
like a good identifier.  You still have to sort out authors having multiple 
email address and using them interchangeably.


However, as forwarding of modified messages settles on From: rewriting, 
recovering that identifier becomes fuzzy.  ARC does not cover that bit.  If we 
want to reliably use the author as an identifier, we need those forwarders who 
rewrite the From: header field —let's call'em MLMs— to adopt a standard way to 
convey the original value.  In my mlm-transform draft, I propose 
Original-From:.  IETF uses X-Original-From:.  Mailman uses Reply-To: or Cc:.

Re: [dmarc-ietf] p=quarantine

[Michael Thomas]

On 12/22/20 7:41 AM, Todd Herr wrote:


My conundrum here is "Do I trust A's claim that the message was 
correctly DKIM signed by domain D with selector S?"


which is why ARC brings nothing new to the table. it's not that it was 
correctly signed by the originator, it's whether i trust the mangler at 
all. if i do, then i implicitly trust that they handled the dkim 
verification too. it would be a lot more productive to work on that 
trust problem than hoping a renamed dkim signature is going to somehow 
change that.


Mike

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

Re: [dmarc-ietf] p=quarantine

[Todd Herr]

On Mon, Dec 21, 2020 at 12:47 PM Alessandro Vesely  wrote:

> On Sun 20/Dec/2020 18:10:03 +0100 Todd Herr wrote:
> >
> > Lists are a specific instance of the more general case of indirect mail
> flows.
>
>
> How many kinds of indirect mail flows do rewrite From:?
>
> Specific methods might prove more effective than general ones.
>
>
Sender Rewriting Scheme (SRS) exists for the rewriting of the RFC5321.From
address, and is sometimes used in mail that is forwarded by rule, say from @
alum.institution.edu to @consumerMailboxProvider.com

The larger point, though, is that mail that automatically passes through
one or more intermediary hosts on its way to its final destination can fail
authentication checks at the final destination due to the impact of changes
on the message, either in path, or content, or both, as it traverses that
journey. It seems to me that we can either work to find a way to ensure
that such failures don't happen, or we can work to find a reliable and
trustworthy way to record authentication results along the way so that the
failures can be mitigated and not result in failed delivery of wanted mail.


> > [...]
> >
> > Since the receiver typically can't perform the same checks under the
> same
> > conditions that existed when the intermediary performed them (if it
> could, we
> > wouldn't need something like ARC) then the receiver has to decide if the
> > message is consistent with messages it's previously seen through direct
> mail
> > flows using that same authenticated identity that was captured by the
> > intermediary in the ARC header set.
>
>
> Doesn't that assume some kind of omniscience at the receiver's?
> Consistency
> with previous messages by the same source is not straightforward.  Using
> the
> same selector?  Signing more or less the same set of header fields?
> Choice of
> vocabulary?  HTML vs. plain text style (e.g. line length)?  A.I.?
>
>
Not omniscience, no, but certainly a method of tracking an authenticated
identity's reputation, and consistency of reputation is what I'm speaking
of. Allow me to try again to get across the idea that I'm so far failing to
make clear.

I'm not currently working for a mailbox provider, but I have in the past,
and so I will role play as one here.

As a mailbox provider, I have a system for authenticating the identity or
identities associated with messages that come directly to me.

These authenticated identities can include some or all of:

   - The DKIM signing domain(s)
   - The DKIM signing domain(s) and selector(s)
   - The RFC5322.From domain (authenticated using DMARC)
   - The RFC5321.From domain (SPF)
   - The IP address of the client that passed the message to me
   - The domain associated with the PTR record of that IP address
   - Others as I deem useful

For each of these authenticated identities, I can and will track how my
users/customers/mailbox holders engage with the mail they receive, thus
over time establishing in my system a reputation to associate with each
authenticated identity. If, for example, mail that is DKIM signed using
selector S and domain D is mail that my users demonstrate through their
actions (opening it, clicking on links in it, etc.) is wanted mail, then
that authenticated identity (S._domainkey.D) will be associated with a good
reputation (however I define "good") in my system. Lather, rinse, and
repeat for other authenticated identities associated with the message, and
allow that both good and bad reputations can be earned.

Now here comes a message that is DKIM-signed by D with selector S, and it
fails DKIM validation when I do my checks. However, in scanning the
message, I see that there is an ARC header set, one that was signed and
sealed by A, and in that ARC header set is an ARC-Authentication-Results
header that says that the message passed DKIM validation with signing
domain D and selector S when A did its check.

My conundrum here is "Do I trust A's claim that the message was correctly
DKIM signed by domain D with selector S?"

The answer to that question will depend on how my users treat the message
and others like it, assuming that I accept it and deliver it. If my users
treat such messages in a manner that's consistent with how they treat
direct mail flow that is DKIM-signed by D with selector S, then A's
reputation as an ARC-sealer/signer will be positive, because A will
establish with me a history of being a source of ARC-sealed/signed mail
with ARC header sets that can be believed. On the other hand, if my users
consistently treat such messages differently than they do direct mail flow
that is DKIM-signed by D with selector s, then A's reputation as an
ARC-sealer/signer will be negatively impacted with me, because I will not
have evidence in hand that this is a path for mail with an authenticated
identity of S._domainkey.D to take.

The point here is that ARC (or any system designed to capture intermediate
authentication results) can only succeed if the downstream recipients of
the 

Re: [dmarc-ietf] p=quarantine

[Alessandro Vesely]

On Sun 20/Dec/2020 18:10:03 +0100 Todd Herr wrote:


Lists are a specific instance of the more general case of indirect mail flows.



How many kinds of indirect mail flows do rewrite From:?

Specific methods might prove more effective than general ones.



[...]

Since the receiver typically can't perform the same checks under the same 
conditions that existed when the intermediary performed them (if it could, we 
wouldn't need something like ARC) then the receiver has to decide if the 
message is consistent with messages it's previously seen through direct mail 
flows using that same authenticated identity that was captured by the 
intermediary in the ARC header set.



Doesn't that assume some kind of omniscience at the receiver's?  Consistency 
with previous messages by the same source is not straightforward.  Using the 
same selector?  Signing more or less the same set of header fields?  Choice of 
vocabulary?  HTML vs. plain text style (e.g. line length)?  A.I.?



Best
Ale
--























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

Re: [dmarc-ietf] p=quarantine

[Douglas Foster]

Like any security problem, we need to minimize false positives (desired
mail being blocked) and false negatives (unwanted or malicious mail being
allowed).  ARC will hopefully address the false positives, but the false
negative issue remains.   The situation does not seem hopeless, but
the topic does appear to be underdeveloped.   Here are some observations:

SPF PASS means the message was received directly from the stated domain,
but it does not indicate whether or not the stated domain was the
originator, since the SMTP address may have been rewritten.   Similarly,
SPF FAIL indicates that the message was not received directly from the
stated domain, but it cannot distinguish between a message that originated
from an unauthorized source and a message that originated from an
authorized source but was then forwarded without SMTP rewrite.The FAIL
could also be the result of a DNS configuration error, such as a domain
that changed hosting services without changing their SPF policy record.
The issues with failed DKIM signatures and From rewrite are similar.

A forwarded message may have:
- no address rewrite causing SPF FAIL but no masking of the
originator address,
- transparent address rewrite using SRS or ARC, or
- non-transparent replacement of prior SMTP and/or From addresses, without
SRS or ARC clues being included (as this list).

Consequently, the only reliable way to detect an untrusted source behind a
forwarder is to evaluate the entire message header chain.

Blacklisting
---
For purposes of filtering unwanted messages, verifiable header data is not
required.   (If someone wants to spoof an untrusted sender, I am happy to
consider that spoofer untrusted also.)   The Received chain can be checked
for IP addresses and DNS names with negative reputation.   Similarly, any
Received-SPF, Authentication-Results, ARC-Authenticated-Results,
Authenticated-As or similar headers can be checked for email domain names
with negative reputation.   All of this can and should be done regardless
of the SPF and DMARC status, because SPF and DMARC are designed around
direct mail flows, and SPF and DMARC pass can be achieved by pretending to
be a direct mail flow.

An additional test is to count the number of organizations that handled the
message along the delivery path.First, consolidate out the
Received headers with private IPs or loopback IPs, then (probably) drop any
messages transferred over LMTP, and any transfers where the ReverseDNS and
HELO domains are unchanged in the handoff.   What should be left is a small
number of entries where the FROM information indicates the IP and hostnames
of the sending organization and the HELO name should be an MX of the
receiving organization.   (SPF checks and Forward-confirmed DNS checks can
then be performed on this data.)

For direct messages, I assume that the maximum number of organization
boundaries should be three:
- Cloud-based SMTP submitting client to mailstore organization,
- mailstore organization to cloud-based outbound filtering service,
- then outbound filtering service to destination domain.
Additionally, the cloud-based outbound filtering services are relatively
few and well known, which should simplify determining whether an
intermediate organization is a filtering service or a forwarding service.

It seems axiomatic that a forwarder will have an unreliable reputation with
recipients.   If the forwarder blocks a message, the recipient system will
not directly know that it was blocked, whether the blocked message was
wanted or unwanted.   But if the forwarder allows a message that the
recipient does not want, the forwarder takes a hit on its reputation.   An
automated forwarding service has an incentive to avoid false positives, so
it is almost certain to have a spam filtering policy which is weaker than
the final recipient system.Rather than blaming the forwarding service
for unwanted messages getting through, the evaluator should look at the
entire received chain.

Whitelisting
---
It is much riskier to perform whitelisting based on the header data,
because one must allow for the possibility that a nation-state attacker
will construct a convincing but fraudulent header chain, if they perceive
that doing so will succeed.   But I cannot imagine whitelisting a message
from a random forwarder based on header data alone.  I would only do that
if the forwarding service, message originator, and forwarding path were
well understood from external sources.   In that case, a message from a
well-identified forwarding service with a sufficiently-identified message
originator might be a candidate for whitelisting.   But those situations
seem likely to be rare.

Conclusion
---
The overall conclusion is that if a message's only negative indicator is an
authentication failure, the best practice would be to send it to
administrative quarantine for local policies to be tailored to the
situation.   It seems foolish to block a 

Re: [dmarc-ietf] p=quarantine

[Todd Herr]

On Fri, Dec 18, 2020 at 4:55 PM Michael Thomas  wrote:

>
> On 12/15/20 8:01 AM, Todd Herr wrote:
>
>
> I'm not sure there's anything actionable about DMARC's policy values.
>
> you mean p=quarantine, or p=* in general?
>

Depending on the level of sophistication of a receiving email system, a
given email message can have dozens of signals (or data points) associated
with it, of which the relevant DMARC policy record, if it exists, is one.
Those signals can all be actionable, individually or collectively, or
ignored entirely, in that receiving system's decision to accept or reject
the message, and if it accepts it, the decision of where to place that
message.

If an applicable DMARC policy record exists for the RFC5322.From domain in
a message, the receiver can:

   - Perform the necessary authentication checks for DMARC validation, and
   use those validation results and the p= value as the sole or primary
   determining factor in how to handle the message, strictly applying the p=
   value in cases where it's not 'none' and validation checks fail
   - Perform the necessary authentication checks for DMARC validation, and
   use those validation results and the p= value as the sole or primary
   determining factor in how to handle the message, loosely applying the p=
   value in cases where it's not 'none' and validation checks fail (e.g.,
   placing the message in the spam folder even if p=reject is specified in the
   policy record)
   - Perform the necessary authentication checks for DMARC validation, and
   use those validation results and the p= value as one data point in a larger
   data set in how to handle the message
   - Ignore the DMARC policy record entirely



> Obviously indirect mail flows, such as mailing lists and forwarding,
> complicate matters greatly here, as the handling by the intermediary
> host(s) can and will lead to a higher percentage of authentication
> failures. The community has attempted to mitigate this problem;
> RFC5322.From header rewriting, RFC5321.From header rewriting (e.g., SRS),
> and ARC are among the attempts put forth so far, but none have been deemed
> The Solution(tm) yet. In my opinion, ARC has promise, because if a message
> reaches me as a receiver or even intermediary and fails the authentication
> checks I perform, ARC header sets in the message can tell me whether or not
> such checks passed at previous hops *if I trust the entities that inserted
> those ARC header sets*. In an earlier thread, I floated an idea about ARC
> sealer reputation, but it didn't draw much response, so I'll float it here
> again in the hopes that it does.
>
> We've always been able to check the reputation of lists that resign the
> message. The reputation is the previously (un)solved problem.
>
>
> Lists are a specific instance of the more general case of indirect mail
flows.

Any intermediate host can ARC seal and ARC-sign (a term I use as distinct
from re-sign) a message, an act that is meant to capture the results of
authentication checks done when it reached the intermediary. Whether or not
the receiver trusts those results (especially those results that claim that
authentication checks passed at the intermediary) when the message reaches
the receiver depends on the intermediary's reputation for being a truthful
sealer and signer, meaning whether or not it has established a history of
capturing authentication results that are true and accurate.

Since the receiver typically can't perform the same checks under the same
conditions that existed when the intermediary performed them (if it could,
we wouldn't need something like ARC) then the receiver has to decide if the
message is consistent with messages it's previously seen through direct
mail flows using that same authenticated identity that was captured by the
intermediary in the ARC header set.

If the indirect mail flow looks like the direct mail flow, then the sealer
is showing evidence that it can be trusted, and so the indirect mail flow
can receive the same treatment by the receiver that it would give to the
direct mail flow associated with the authenticated identity.

If the indirect mail flow looks different than the direct mail flow, then
the receiver can either decide to not trust the sealer and so treat the
indirect mail flow as unauthenticated, or perhaps it can dig into matters
further to see why the difference exists. A mailing list, for example, that
has subscribers whose domain is a consumer mailbox provider might just show
an indirect mail flow for that domain to the receiver that has a
substantially better overall reputation than the direct mail flow for that
domain to the receiver; rather than letting this difference impact the
level of trust in its sealing reputation that a receiver would assign to
the list, it may very well have to put in an override to its system for
tracking sealer trust.

-- 

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


This email and 

Re: [dmarc-ietf] p=quarantine

[Alessandro Vesely]

On Fri 18/Dec/2020 22:54:54 +0100 Michael Thomas wrote:
In my opinion, ARC has promise, because if a message reaches me as a receiver 
or even intermediary and fails the authentication checks I perform, ARC 
header sets in the message can tell me whether or not such checks passed at 
previous hops *if I trust the entities that inserted those ARC header sets*. 
In an earlier thread, I floated an idea about ARC sealer reputation, but it 
didn't draw much response, so I'll float it here again in the hopes that it 
does.


We've always been able to check the reputation of lists that resign the 
message. The reputation is the previously (un)solved problem.



Yesterday 34 new domains —domains I never heard of before— sent 35 messages to 
my MX.  I count identifiers.  Some of them are subdomains of known domains, so 
they might inherit their parent's reputation.  Several others, however, are new 
organizational domains.  I'm just looking at the first 8, and none of them 
looks like a throw-away, freshly registered domain.


Now my tiny MX stores 115,225 domains total.  And I have no idea how I could 
add a trust-ARC-seals boolean field to each domain record.


Except for a few gigantic mailbox providers, I'd say the reputation problem is 
not quite solved.



Best
Ale
--



















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

Re: [dmarc-ietf] p=quarantine

[Michael Thomas]

On 12/15/20 8:01 AM, Todd Herr wrote:


I'm not sure there's anything actionable about DMARC's policy values.


you mean p=quarantine, or p=* in general?


Obviously indirect mail flows, such as mailing lists and forwarding, 
complicate matters greatly here, as the handling by the intermediary 
host(s) can and will lead to a higher percentage of authentication 
failures. The community has attempted to mitigate this problem; 
RFC5322.From header rewriting, RFC5321.From header rewriting (e.g., 
SRS), and ARC are among the attempts put forth so far, but none have 
been deemed The Solution(tm) yet. In my opinion, ARC has promise, 
because if a message reaches me as a receiver or even intermediary and 
fails the authentication checks I perform, ARC header sets in the 
message can tell me whether or not such checks passed at previous hops 
*if I trust the entities that inserted those ARC header sets*. In an 
earlier thread, I floated an idea about ARC sealer reputation, but it 
didn't draw much response, so I'll float it here again in the hopes 
that it does.


We've always been able to check the reputation of lists that resign the 
message. The reputation is the previously (un)solved problem.


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] p=quarantine

[Douglas Foster]

Thank you Todd.   I found this very helpful because it sets appropriately
low expectations but also describes a framework that I can envision
integrating into my filtering process.

Some version of these concepts need to be worked into the bis or BCP
document, so that product developers do not continue to implement SPF and
DMARC as on-off switches without integration to a local policy system which
implements the local reputation database.

Your comments about ARC do a better job of articulating its use case than I
have read anywhere else.   I have some ideas for elaborating them, but I
will save them for later, to avoid being reminded that forwarding is off
topic.

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

Re: [dmarc-ietf] p=quarantine

[Todd Herr]

On Mon, Dec 14, 2020 at 10:36 PM Michael Thomas  wrote:

>
> 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.
>
>
I'm not sure there's anything actionable about DMARC's policy values.

For receivers, attempts at manually tracking which RFC5322.From domains
appear in mail that's authenticated or not with SPF and/or DKIM are ones
that are bound to fail due to scaling issues. DMARC provides a solution to
this problem, in that if a domain owner publishes a DMARC policy, the
receiver now has some information that the owner of the RFC5322.From domain
may have an expectation that mail with that domain in the RFC5322.From
domain might be authenticated in some fashion, using SPF and/or DKIM.
The receiver can use that data point, and the data points collected from
DMARC validation checks for that message, as part of the sum total of data
it uses to decide its handling of that message. If there is a published
DMARC policy for the RFC5322.From domain, and the receiver so chooses, the
receiver can also use the p= value in that policy as another data point
contributing to the message handling decision, but the receiver is not
compelled or required to do so (nor is the receiver compelled or required
to even perform DMARC validation checks, or send aggregate and/or failure
reports, or even check for the existence of a DMARC policy record for the
RFC5322.From domain).

For domain owners that publish DMARC policies, the best case is that the
owner is announcing to the internet at large that

   - It is on a journey to ensure that if it's domain (or a sub-domain
   thereof) is the RFC5322.From domain in a message, then such a message will
   pass SPF and/or DKIM authentication checks, and
   - It is interested in seeing data from receivers about what kind of
   traffic the receivers are seeing where the domain is used in the
   RFC5322.From address, perhaps as a way of increasing the rate at which
   those authentication checks are passing, and
   - It is providing to DMARC validators some information, in the form of
   the p= value, that expresses its own level of confidence in how
   well-implemented its email authentication practices are, with such
   confidence levels probably roughly approximating:
  - none - Not at all confident, just starting the process, we know or
  at least think that some of our mail streams aren't authenticating
  - quarantine - We think we've got it all locked down, but even a very
  small risk of bouncing a big campaign is very scary to us,
and/or we don't
  fully trust SPF and DKIM to pass validation checks 100% of the time when
  they should, and it's better for us and our customer service staff if the
  mail we originate at least gets delivered to the recipients'
spam folders,
  regardless of the risk of our domain being spoofed.
  - reject - We've got everything locked down, we're confident in our
  choices, and if you, Mr. Receiver, accept messages that fail DMARC
  validation checks and your mailbox holders fall victim to a scam
because of
  it, it's your fault, not ours. Alternatively, 'reject' could also mean
  'this domain should never appear as the domain in the
RFC5322.From header',
  but with the same messaging about whose fault it is if messages are
  accepted and lead to a bad outcome.

In the worst case, the domain owner is just checking a box because they
think that "publishing a DMARC policy" means "my mail will make it to the
inbox".

Obviously indirect mail flows, such as mailing lists and forwarding,
complicate matters greatly here, as the handling by the intermediary
host(s) can and will lead to a higher percentage of authentication
failures. The community has attempted to mitigate this problem;
RFC5322.From header rewriting, RFC5321.From header rewriting (e.g., SRS),
and ARC are among the attempts put forth so far, but none have been deemed
The Solution(tm) yet. In my opinion, ARC has promise, because if a message
reaches me as a receiver or even intermediary and fails the authentication
checks I perform, ARC header sets in the message can tell me whether or not
such checks passed at previous hops *if I trust the entities that inserted
those ARC header sets*. In an 

Re: [dmarc-ietf] p=quarantine

[Alessandro Vesely]

On Tue 15/Dec/2020 04:26:03 +0100 Douglas Foster 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.



I'm neutral about the nomenclature.  However, the definitions lack something.

First party is clear.

Third party is not:

For a nit, albeit unusual, one can use a different bounce address, for any 
convenience reason.  If SPF helo is aligned it is still a first party message.


There are other considerations that indicate a the presence and the quality of 
a third party, such as multiple DKIM signatures, and a Sender: field.


Then there are dumb forwarders, who neither sign nor modify messages, nor even 
the bounce addresses.  Second parties?  Hm... external aliases?  Artifacts of 
email address portability?



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?"



I think quarantine is not necessarily an intermediate step.  It is adequate for 
human mail, where one is not equipped to resend in case of reject.  It doesn't 
cover first/third party differences.  I wish there was an intermediate policy, 
call it p=mlm-validate, that directs a third party to reject if not 
authenticated, while final recipients can accept it as if p=none.



Best
Ale
--



















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

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] 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] 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] 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] p=quarantine

[Dotzero]

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.

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



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

"Shared assumptions" are not definitions, they are hopes. Again, not a good
basis for a technical standard.

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

Re: [dmarc-ietf] p=quarantine

[Douglas Foster]

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

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
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] p=quarantine

[Michael Thomas]

On 12/12/20 10:42 AM, Dave Crocker wrote:


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.




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. The only thing all of this hand wringing has done is waste time 
and added to the length of time it takes to get specs out the door.


Quarantine however -- which is why I started this thread -- is not clear 
at all. Why are we still talking about "reject"?


Mike

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

Re: [dmarc-ietf] p=quarantine

[John R Levine]

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

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.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] p=quarantine

[Dave Crocker]

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

Re: [dmarc-ietf] p=quarantine

[Hector Santos]

On 12/11/2020 11:19 AM, Dotzero wrote:>


On Fri, Dec 11, 2020 at 11:11 AM Hector Santos


 We are not doing reporting at this time.  Not the main focus.
 That can come later as an augmented feature, in fact, we might
 consider it as a paid service to be sending thousands report out
 to domains.


That's good community spirit.


eh, thanks?


I doubt many would be willing to pay you for your reports.


Customers are already paying for the total platform (not open source, 
not free, its expensive commercial hosting software). It comes without 
any DMARC reporting except with the description to add DMARC report 
tags to collect the reports and instructions to redirect the 
notifications to specific admin-only mail areas. No Doubt, this is an 
easy added-value feature when we are ready to offer the ad-hoc 
reporting capability added to their existing Wildcat! Ad-hoc Reporting 
tools (an paid for add-on).


How do you benefit from DMARC? What is your rejection (or protect 
domain action) average? Do you allow subscriptions to your mailing 
list services or you do rewriting?


-- Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


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

Re: [dmarc-ietf] p=quarantine

[John Levine]

In article <1ac986ff-507b-4917-9c6d-d84e9337f...@wordtothewise.com> you write:
>p=none: mail sent by authorized users of this domain may or may not be aligned 
>in a DMARC compliant way.
>
>p=quarantine: mail sent by authorized users of this domain should be aligned 
>in a DMARC compliant
>way. Mail that is unaligned may or may not be legitimate messages from this 
>organization.

So far so good.

>p=reject: all mail sent from this domain should be aligned in a DMARC 
>compliant way. Mail that is
>unaligned 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.

R's,
John

PS: I had more or less this same discussion leading to ADSP discardable.

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

Re: [dmarc-ietf] p=quarantine

[Laura Atkins]

> On 11 Dec 2020, at 17:07, Dave Crocker  wrote:
> 
> On 12/11/2020 8:32 AM, Kurt Andersen (b) wrote:
>> Perhaps:
>>  none: not certain at all
>>  quarantine: I believe I've got control of all my sending, but am 
>> not 100% positive
>>  reject: I have control of all my sending; if it doesn't pass DMARC, 
>> it's use of the domain is bogus.
>> 
>> But the problem case in our off-topic rabbit trail meanderings is that 
>> people who "have control of all their sending" still don't necessarily send 
>> mail of consistent seriousness nor do they have any control of the paths by 
>> which that mail takes to get to the ultimate recipient. There is a 
>> conflation of "control of emission" with "control of path".
> 
> A specification providing a choice of labels/settings needs to have a shared 
> understanding of what those labels mean.  
> 
> It seems pretty clear that DMARC's p= hasn't had that, to date.  There is no 
> consistency to the criteria used to set the label and, I suspect, little 
> consistency to how a receiver's filtering engine uses it.
> 
> We need to settle on text that resonates with a consistent interpretation, by 
> both domain owners and email receivers.
> 
> I've offered an approach that might permit reaching that community -- not 
> just IETF -- rough consensus.  
> 
> At this point we need to get suggested revisions for improvement. For now, I 
> don't have better text to suggest.
> 

There’s probably better phrasing than ‘DMARC compliant’ here, but here’s my 
stab at describing the processes. note, this is very close to the language I 
use with clients.

p=none: mail sent by authorized users of this domain may or may not be aligned 
in a DMARC compliant way.

p=quarantine: mail sent by authorized users of this domain should be aligned in 
a DMARC compliant way. Mail that is unaligned may or may not be legitimate 
messages from this organization.

p=reject: all mail sent from this domain should be aligned in a DMARC compliant 
way. Mail that is unaligned is not authorized by the domain owner and may be 
discarded or rejected by the recipient. 

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

[Dave Crocker]

On 12/11/2020 8:32 AM, Kurt Andersen (b) wrote:


Perhaps:
 none: not certain at all
 quarantine: I believe I've got control of all my sending, but am
not 100% positive
 reject: I have control of all my sending; if it doesn't pass
DMARC,
it's use of the domain is bogus.


But the problem case in our off-topic rabbit trail meanderings is that 
people who "have control of all their sending" still don't necessarily 
send mail of consistent seriousness nor do they have any control of 
the paths by which that mail takes to get to the ultimate recipient. 
There is a conflation of "control of emission" with "control of path".



A specification providing a choice of labels/settings needs to have a 
shared understanding of what those labels mean.


It seems pretty clear that DMARC's p= hasn't had that, to date. There is 
no consistency to the criteria used to set the label and, I suspect, 
little consistency to how a receiver's filtering engine uses it.


We need to settle on text that resonates with a consistent 
interpretation, by both domain owners and email receivers.


I've offered an approach that might permit reaching that community -- 
not just IETF -- rough consensus.


At this point we need to get suggested revisions for improvement. For 
now, I don't have better text to suggest.


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

[Kurt Andersen (b)]

On Thu, Dec 10, 2020 at 6:26 PM Dave Crocker  wrote:

> On 12/10/2020 6:01 PM, Kurt Andersen (b) wrote:
> > I think that is much closer to the right semantic but highlights a
> > problem that the mail coming from a particular domain probably doesn't
> > rate a single broad-brush characterization of seriousness.
>
> I've assumed the none, quarantine, reject choices are meant to indicate
> just how certain the domain owner is that the mail is problematic.
>
> Perhaps:
>
>  none: not certain at all
>
>  quarantine: I believe I've got control of all my sending, but am
> not 100% positive
>
>  reject: I have control of all my sending; if it doesn't pass DMARC,
> it's use of the domain is bogus.
>

But the problem case in our off-topic rabbit trail meanderings is that
people who "have control of all their sending" still don't necessarily send
mail of consistent seriousness nor do they have any control of the paths by
which that mail takes to get to the ultimate recipient. There is a
conflation of "control of emission" with "control of path".

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

Re: [dmarc-ietf] p=quarantine

[Hector Santos]

On 12/11/2020 11:10 AM, Hector Santos wrote:


* SPF -ALL, REJECT - Receiver rejects at MAIL FROM state with a 550
response.


Correction:

* SPF -ALL, REJECT - Receiver rejects at RCPT TO state with a 550
response.  SPF is only tested once a valid (existing) RCPT TO is provided.

This was the very first major optimization done with SPF back in 
2003/2004 when it was first changed from MAIL FROM to RCPT TO.   It 
resulted in a DNS lookup overhead savings of 60% because at the time, 
60% of the RCPT TO were "unknown, not locally hosted" addresses.


This mode of operation is on-par with the SMTP RFC5321 Section 3.3 
recommendation:


   3.3 Mail Transactions

   .

   Despite the apparent scope of this requirement, there are
   circumstances in which the acceptability of the reverse-path may
   not be determined until one or more forward-paths (in RCPT
   commands) can be examined.  In those cases, the server MAY
   reasonably accept the reverse-path (with a 250 reply) and then
   report problems after the forward-paths are received and
   examined.  Normally, failures produce 550 or 553 replies.




--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos


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

Re: [dmarc-ietf] p=quarantine

[Dotzero]

On Fri, Dec 11, 2020 at 11:11 AM Hector Santos  wrote:

> We are not doing reporting at this
> time.  Not the main focus.  That can come later as an augmented
> feature, in fact, we might consider it as a paid service to be sending
> thousands report out to domains.
>

That's good community spirit. I doubt many would be willing to pay you for
your reports.

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

Re: [dmarc-ietf] p=quarantine

[Hector Santos]

On 12/10/2020 9:26 PM, Dave Crocker wrote:

On 12/10/2020 6:01 PM, Kurt Andersen (b) wrote:

I think that is much closer to the right semantic but highlights a
problem that the mail coming from a particular domain probably
doesn't rate a single broad-brush characterization of seriousness.


I've assumed the none, quarantine, reject choices are meant to
indicate just how certain the domain owner is that the mail is
problematic.

Perhaps:
+
 none: not certain at all

 quarantine: I believe I've got control of all my sending, but am
not 100% positive

 reject: I have control of all my sending; if it doesn't pass
DMARC, it's use of the domain is bogus.



When it comes to keeping focus with the purpose of SPF and DKIM-POLICY 
protocols and its implementation out of the box, default behavior:


1) The main purpose is Receiver Abuse Control.

2) Special attention to Port 25 Unsolicited Anonymous Senders and 
Message Authors.


3) For authenticated, authorized, white listed clients, SPF and DKIM 
do not apply, mail is always accepted.


Hard policies with SPF and DKIM-POLICY are honored aggressively. 
Softer policies are processed, classified and passed through to next 
filters, if any remaining, i.e. GreyListing.


* SPF -ALL, REJECT - Receiver rejects at MAIL FROM state with a 550 
response.


* ADSP DKIM=DISCARDABLE, Receiver rejects at SMTP DATA state with a 
negative 550 DATA response.


* DMARC p=reject, Receiver rejects at SMTP DATA state with a negative 
550 DATA response.


* DMARC p=quarantine, Receiver accepts at SMTP. Mail is moved outside 
targeted users' main inbox mail stream, i.e. can not be picked up by 
user's POP3 or normal mail pickup process. The user has to login in 
online to see the mail in another non-inbox folder, i.e. spam box.


Thats it.  No reporting. Period.

The domain should be grateful their public mail policy instructions is 
being honored for strict operations at compliant receivers. I hope 
their compliant receivers are also honoring our strict public mail 
policies as well to help protect fraudulent usage. I really do not 
need a report for the expected action when fraudulent mail is detected.


Overall, the receiver is doing the domain a favor by helping them 
protect their domain reputation from possible fraudulent usage of 
their domains, and at the same time, it is helping its own system and 
the target hosted user from potential abuse as well -- a win win 
situation.


For List-related situations, the receiver follows the 2006 DSAP 
recommendations:


https://tools.ietf.org/html/draft-santos-dkim-dsap-00

1) If a new subscribing domain has a restrictive public mail policy 
with ADSP and/or DMARC, the subscription is denied.


2) Incoming messages are checked for mailing list destinations. If the 
submitter's domain have restrictive public mail policies with ADSP or 
DMARC, the submission is rejected with a 550.


With these two simple peripheral filters, there was no need to modify 
the legacy list server source code for Rewriting or anything else 
related to the "in-direct" mail problem.


The DMARCbis codification/changes I am looking for are:

1) Improvements in the DNS lookup algorithm, optional additional 
lookups should be provided or referenced.


2) Recognition and support for ATPS to cover 3rd party authorization.

and other fine tunning, clarifications, for example, in another 
thread, it was stated:


"When you switch to p=quarantine pct=0, no one should apply quarantine 
(so it's equivalent to p=none),"


I thought the "pct=" was related to when reporting should be applied. 
I apparently read it wrong.  This needs to be code reviewed and 
corrected on our end, if needed.  We are not doing reporting at this 
time.  Not the main focus.  That can come later as an augmented 
feature, in fact, we might consider it as a paid service to be sending 
thousands report out to domains.


Keep it simple folks.  Be safe and have a great weekend.

Thanks

--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos




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

Re: [dmarc-ietf] p=quarantine

[Michael Thomas]

On 12/10/20 6:44 PM, Dave Crocker wrote:

On 12/10/2020 6:32 PM, Michael Thomas wrote:

Semantic nit picking at best.


Because semantics do not matter in a specification?


It's ok, I guess but I wouldn't want to make a career of nit picking. 
It's a lot more useful to get intent across of what the actual intent is 
rather than trying to express what is ultimately a code point for a 
filter that doesn't care about the ascii string.


Mike

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

Re: [dmarc-ietf] p=quarantine

[Dave Crocker]

On 12/10/2020 6:32 PM, Michael Thomas wrote:

Semantic nit picking at best.


Because semantics do not matter in a specification?

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

[Dave Crocker]

On 12/10/2020 6:25 PM, Michael Thomas wrote:

I think this all should be driven by "what are you asking me to do?"


The domain owner has no business asking the receiver to do anything.  
The receiver has no relationship with the domain owner.


However, the receiver might like to hear the domain owner's opinion 
about usage of the domain when DMARC fails.  But that's different from 
attempting to give direction to the receiver (who demonstrably will 
ignore that direction and make their own decision.)


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

[Dave Crocker]

On 12/10/2020 6:01 PM, Kurt Andersen (b) wrote:
I think that is much closer to the right semantic but highlights a 
problem that the mail coming from a particular domain probably doesn't 
rate a single broad-brush characterization of seriousness. 


I've assumed the none, quarantine, reject choices are meant to indicate 
just how certain the domain owner is that the mail is problematic.


Perhaps:

    none: not certain at all

    quarantine: I believe I've got control of all my sending, but am 
not 100% positive


    reject: I have control of all my sending; if it doesn't pass DMARC, 
it's use of the domain is bogus.


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

[Michael Thomas]

On 12/10/20 6:01 PM, Kurt Andersen (b) wrote:
On Thu, Dec 10, 2020 at 5:03 PM Dave Crocker > wrote:


On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote:

to quibble with the "*unauthorized use*"  situation. This
situation devolves into use-as-imagined vs. use-as-really-used
when one considers various intermediary scenarios.


(to respond to the content...)

So, the driving issue is that it's characterizing problematic
usage; use that did not achieve a DMARC pass.

And, yeah, that doesn't mean the use was unauthorized, given the
other possible explanations for failure.

So, without suggesting a label, I'd describe this factor as "how
serious is a failure to get a DMARC pass"?  If that's the right
semantic, what's a reasonable label to use?  If it's not the right
semantic, what is?

I think that is much closer to the right semantic but highlights a 
problem that the mail coming from a particular domain probably doesn't 
rate a single broad-brush characterization of seriousness.


I think this all should be driven by "what are you asking me to do?". 
p=quarantine is asking for a specific thing, but it doesn't seem to mean 
literally what it's asking for. it seems to mean "i'm not comfortable 
with this except in certain situations that i can't enumerate with any 
accuracy". maybe p=quarantine is my "only if you trust the intermediary" 
state I was talking about the other day.


Mike

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

Re: [dmarc-ietf] p=quarantine

[Kurt Andersen (b)]

On Thu, Dec 10, 2020 at 5:03 PM Dave Crocker  wrote:

> On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote:
>
> to quibble with the "*unauthorized use*"  situation. This situation
> devolves into use-as-imagined vs. use-as-really-used when one considers
> various intermediary scenarios.
>
> (to respond to the content...)
>
> So, the driving issue is that it's characterizing problematic usage; use
> that did not achieve a DMARC pass.
>
> And, yeah, that doesn't mean the use was unauthorized, given the other
> possible explanations for failure.
>
> So, without suggesting a label, I'd describe this factor as "how serious
> is a failure to get a DMARC pass"?  If that's the right semantic, what's a
> reasonable label to use?  If it's not the right semantic, what is?
>
I think that is much closer to the right semantic but highlights a problem
that the mail coming from a particular domain probably doesn't rate a
single broad-brush characterization of seriousness.

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

Re: [dmarc-ietf] p=quarantine

[Dave Crocker]

On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote:
to quibble with the "*unauthorized use*"  situation. This situation 
devolves into use-as-imagined vs. use-as-really-used when one 
considers various intermediary scenarios.


(to respond to the content...)


So, the driving issue is that it's characterizing problematic usage; use 
that did not achieve a DMARC pass.


And, yeah, that doesn't mean the use was unauthorized, given the other 
possible explanations for failure.


So, without suggesting a label, I'd describe this factor as "how serious 
is a failure to get a DMARC pass"?  If that's the right semantic, what's 
a reasonable label to use?  If it's not the right semantic, what is?



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

[Dave Crocker]

On 12/10/2020 4:46 PM, Kurt Andersen (b) wrote:

but I'd have to quibble with the "*unauthorized use*"  situation.


please do quibble. or more.

I intended the text to prime the pump, and don't have any expectation is 
is already perfect.


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

[Kurt Andersen (b)]

On Wed, Dec 9, 2020 at 10:09 AM Dave Crocker  wrote:

> It might be worth a bit of thinking about what, exactly, DMARC can
> reasonably do and how it should be summarized, for popular consumption:
>
> *Alignment - *DMARC defines a basis for authenticating use of the domain
> name in the rfc5322.From addr-spec.  (But nothing else in that header field
> or elsewhere in the message, neither header nor body.
>
> *Severity of unauthorized use - *DMARC provides a means of indicating to
> receivers how serious the domain owner considers unauthorized use of that
> domain name to be.
>
> *Reporting -* DMARC defines a mechanism for reporting DMARC-related
> activity by a receiver
>
> I've tried to state each of these precisely and accurately, in terms of
> real-world pragmatics.
>
These seem like a good starting point, but I'd have to quibble with
the "*unauthorized
use*"  situation. This situation devolves into use-as-imagined vs.
use-as-really-used when one considers various intermediary scenarios. Does
a domain owner really have the prerogative to define recipient behaviour as
"unauthorized"?

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

Re: [dmarc-ietf] p=quarantine

[Dave Crocker]

On 12/9/2020 9:52 AM, tjw ietf wrote:
Obviously the domain owner has no 'authority' over those using the 
domain without authorization.  For this latter set of folk, the most 
the domain owner can do is provide information to receivers of 
unauthorized use.



It might be worth a bit of thinking about what, exactly, DMARC can 
reasonably do and how it should be summarized, for popular consumption:


   *Alignment - *DMARC defines a basis for authenticating use of the
   domain name in the rfc5322.From addr-spec.  (But nothing else in
   that header field or elsewhere in the message, neither header nor body.

   *Severity of unauthorized use - *DMARC provides a means of
   indicating to receivers how serious the domain owner considers
   unauthorized use of that domain name to be.

   *Reporting -* DMARC defines a mechanism for reporting DMARC-related
   activity by a receiver

I've tried to state each of these precisely and accurately, in terms of 
real-world pragmatics.


Comments?

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

[tjw ietf]

I agree strongly with Dave on creating boring and precise 
terminology/references, and they are used over and over. 



Tim

Sent from my iPhone

> On Dec 9, 2020, at 12:40, Dave Crocker  wrote:
> 
> On 12/8/2020 12:11 PM, Dotzero wrote:
>> Note that I asked Two questions. Your answer appears directed to the second 
>> question. The answer to the first question appears fairly clear to me. 
>> Administrators of a system can restrict or delete a user account. It really 
>> is as simple as that. So in that respect the answer is that ultimately an 
>> individual account users do not supersede the wishes/policy of the domain 
>> owners representatives.
>> 
>> The second question is a bit more interesting, but ultimately leads one back 
>> to the first question. As far as being long settled, I would think that NSF 
>> AUP is an interesting precedent.
>> 
>> Michael Hammer
>> 
>> On Tue, Dec 8, 2020 at 2:42 PM Dave Crocker  wrote:
>>> On 12/8/2020 10:50 AM, Dotzero wrote:
>>> > And here we get to some of the crucial unresolved questions involving 
>>> > email: "Does the wishes of a user of an account at a domain supercede 
>>> > the policies of the domain owner/administrator of a domain?"
> 
> Sorry, I misread the text I responded to.  To some extent, we all tend to be 
> ambiguous in our references -- though the specific text I misread was not -- 
> and it will help if we are all a lot more consistently precise. 
> 
> 
> 
> For example:
> 
> Author: creates content
> 
> Author Domain: controls the use of the domain, per the statement I misread.  
> And yes, the domain owner has ultimate authority over polices of how the 
> domain is used, by those subject to administration by the domain owner.  
> Obviously the domain owner has no 'authority' over those using the domain 
> without authorization.  For this latter set of folk, the most the domain 
> owner can do is provide information to receivers of unauthorized use.
> 
> Receivers: They have full and complete authority over their operations.  
> Period, full stop.  There is no 'overriding' the so-called policies of anyone 
> with whom they do not have a pre-existing relationship.
> 
> Recipients: They are, of course, subject to the policies of the owner of the 
> platform being used.  They, to, are not subject to the desires of authors or 
> author domain owners, except as the recipient themselves desire.
> 
> 
> 
> Really, it will help to be boringly, redundantly precise with every 
> reference, to leave no room for misunderstanding which actor is being 
> referenced.
> 
> 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
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] p=quarantine

[Dave Crocker]

On 12/8/2020 12:11 PM, Dotzero wrote:
Note that I asked Two questions. Your answer appears directed to the 
second question. The answer to the first question appears fairly clear 
to me. Administrators of a system can restrict or delete a user 
account. It really is as simple as that. So in that respect the answer 
is that ultimately an individual account users do not supersede the 
wishes/policy of the domain owners representatives.


The second question is a bit more interesting, but ultimately leads 
one back to the first question. As far as being long settled, I would 
think that NSF AUP is an interesting precedent.


Michael Hammer

On Tue, Dec 8, 2020 at 2:42 PM Dave Crocker > wrote:


On 12/8/2020 10:50 AM, Dotzero wrote:
> And here we get to some of the crucial unresolved questions
involving
> email: "Does the wishes of a user of an account at a domain
supercede
> the policies of the domain owner/administrator of a domain?"



Sorry, I misread the text I responded to.  To some extent, we all tend 
to be ambiguous in our references -- though the specific text I misread 
was not -- and it will help if we are all a lot more consistently precise.



For example:

Author: creates content

Author Domain: controls the use of the domain, per the statement I 
misread.  And yes, the domain owner has ultimate authority over polices 
of how the domain is used, by those subject to administration by the 
domain owner.  Obviously the domain owner has no 'authority' over those 
using the domain without authorization.  For this latter set of folk, 
the most the domain owner can do is provide information to receivers of 
unauthorized use.


Receivers: They have full and complete authority over their operations.  
Period, full stop.  There is no 'overriding' the so-called policies of 
anyone with whom they do not have a pre-existing relationship.


Recipients: They are, of course, subject to the policies of the owner of 
the platform being used.  They, to, are not subject to the desires of 
authors or author domain owners, except as the recipient themselves desire.



Really, it will help to be boringly, redundantly precise with every 
reference, to leave no room for misunderstanding which actor is being 
referenced.


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

[John Levine]

In article  
you write:
>-=-=-=-=-=-
>
>Note that I asked Two questions. Your answer appears directed to the second
>question. The answer to the first question appears fairly clear to me.
>Administrators of a system can restrict or delete a user account.

It depends what agreements they might have with the users but in general
I agree, users can only do what their system managers permit.

>The second question is a bit more interesting, but ultimately leads one
>back to the first question. As far as being long settled, I would think
>that NSF AUP is an interesting precedent.

Huh? NSFNET shut down decades ago. I would be surprised if its
agreements with the systems it served, all of which had some
contractual relationship with the NSF, had any relevance beyond
a tiny handful of government funded academic networks.

R's,
John

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

Re: [dmarc-ietf] p=quarantine

[Benny Pedersen]

Dotzero skrev den 2020-12-08 19:50:


And here we get to some of the crucial unresolved questions involving
email: "Does the wishes of a user of an account at a domain supercede
the policies of the domain owner/administrator of a domain?" "Does a
domain owner/administrator have the right to externalize enforcement
of their internal usage policies?" These questions and associated
answers go far beyond DMARC but certainly impact how one views policy
statements made by DMARC.


i have solved it by using fuglu :=)

when i used milters in postfix i just did that in postfix to tell dont 
use milters on maillists ips, pretty simple


but there might be more options, eq dont break dkim

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

Re: [dmarc-ietf] p=quarantine

[Dotzero]

Note that I asked Two questions. Your answer appears directed to the second
question. The answer to the first question appears fairly clear to me.
Administrators of a system can restrict or delete a user account. It really
is as simple as that. So in that respect the answer is that ultimately an
individual account users do not supersede the wishes/policy of the domain
owners representatives.

The second question is a bit more interesting, but ultimately leads one
back to the first question. As far as being long settled, I would think
that NSF AUP is an interesting precedent.

Michael Hammer

On Tue, Dec 8, 2020 at 2:42 PM Dave Crocker  wrote:

> On 12/8/2020 10:50 AM, Dotzero wrote:
> > And here we get to some of the crucial unresolved questions involving
> > email: "Does the wishes of a user of an account at a domain supercede
> > the policies of the domain owner/administrator of a domain?"
>
> It's not only not crucial, it's entirely resolved, and always had been,
> in terms of real-world practice. The view that it hasn't been is frankly
> an arrogance of author domain owners.
>
> Author domain owners do not have a relationship with receivers or
> recipients, so their policies have no enforcement potential. Receivers
> and recipients are completely independent.  They do not 'override' the
> domain owner policies.  Rather, they apply their own policies.  Always
> have.
>
> This is why the language in DMARC would be far more constructive to
> remove any hint of attempting to direct receiver or recipient behavior,
> and instead merely reflect the domain owner's assessment of message
> validity, along the lines of the language I offered.
>
> 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

[Dave Crocker]

On 12/8/2020 10:50 AM, Dotzero wrote:
And here we get to some of the crucial unresolved questions involving 
email: "Does the wishes of a user of an account at a domain supercede 
the policies of the domain owner/administrator of a domain?"


It's not only not crucial, it's entirely resolved, and always had been, 
in terms of real-world practice. The view that it hasn't been is frankly 
an arrogance of author domain owners.


Author domain owners do not have a relationship with receivers or 
recipients, so their policies have no enforcement potential. Receivers 
and recipients are completely independent.  They do not 'override' the 
domain owner policies.  Rather, they apply their own policies.  Always have.


This is why the language in DMARC would be far more constructive to 
remove any hint of attempting to direct receiver or recipient behavior, 
and instead merely reflect the domain owner's assessment of message 
validity, along the lines of the language I offered.


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

[Dotzero]

On Tue, Dec 8, 2020 at 12:42 PM Michael Thomas  wrote:

>
> If you take the literal meaning of quarantine, that means that every
> piece of email from this and every other mailing list would end up in a
> quarantine folder, or some such. I'm fairly certain that is not what
> people want, and I'm doubtful that many receivers implement that. The
> question to my mind is whether there actually exists a state between "we
> don't know" and "trash it because it's not from us". "Quarantine" seems
> to mean "be more suspicious of this", but I'm not sure if that is of any
> help to filters. Ultimately it's whether filters find these policies
> useful is what actually matters. Don't we have enough data lying around
> these days to inform us? If filters are ignoring it, then it's rather
> pointless. This discussion (and many others) should be data driven, IMO.
>
> Mike
>

And here we get to some of the crucial unresolved questions involving
email: "Does the wishes of a user of an account at a domain supercede the
policies of the domain owner/administrator of a domain?" "Does a domain
owner/administrator have the right to externalize enforcement of their
internal usage policies?" These questions and associated answers go far
beyond DMARC but certainly impact how one views policy statements made by
DMARC.

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