Re: [dmarc-ietf] p=quarantine

[Douglas Foster <[e-mail]>]

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 <[e-mail]>
wrote:

>
>
> On 13 Dec 2020, at 21:44, Douglas Foster <
> [e-mail]> 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 <[e-mail]> wrote:
>
>> On 12/11/2020 9:37 AM, John Levine wrote:
>> > In article <[e-mail]>
>> 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
>> [e-mail]
>> 408.329.0791
>>
>> Volunteer, Silicon Valley Chapter
>> American Red Cross
>> [e-mail]
>>
>> _______________________________________________
>> dmarc mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>
> --
> Having an Email Crisis?  We can help! 800 823-9674
>
> Laura Atkins
> Word to the Wise
> [e-mail]
> [phone]
>
> Email Delivery Blog: https://wordtothewise.com/blog
>
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>