Re: [dmarc-ietf] p=quarantine

> On 14 Dec 2020, at 15:11, Douglas Foster <dougfoster.emailstandards@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 <laura@wordtothewise.com <mailto:laura@wordtothewise.com>> wrote:
> 
> 
>> On 13 Dec 2020, at 21:44, Douglas Foster <dougfoster.emailstandards@gmail.com <mailto:dougfoster.emailstandards@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 <dcrocker@gmail.com <mailto:dcrocker@gmail.com>> wrote:
>> On 12/11/2020 9:37 AM, John Levine wrote:
>> > In article <1AC986FF-507B-4917-9C6D-D84E9337FC7A@wordtothewise.com <mailto:1AC986FF-507B-4917-9C6D-D84E9337FC7A@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
>> dcrocker@gmail.com <mailto:dcrocker@gmail.com>
>> 408.329.0791
>> 
>> Volunteer, Silicon Valley Chapter
>> American Red Cross
>> dave.crocker2@redcross.org <mailto:dave.crocker2@redcross.org>
>> 
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org <mailto:dmarc@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dmarc <https://www.ietf.org/mailman/listinfo/dmarc>
>> _______________________________________________
>> dmarc mailing list
>> dmarc@ietf.org <mailto:dmarc@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dmarc <https://www.ietf.org/mailman/listinfo/dmarc>
> 
> -- 
> Having an Email Crisis?  We can help! 800 823-9674 
> 
> Laura Atkins
> Word to the Wise
> laura@wordtothewise.com <mailto:laura@wordtothewise.com>
> (650) 437-0741		
> 
> Email Delivery Blog: https://wordtothewise.com/blog <https://wordtothewise.com/blog>	
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org <mailto:dmarc@ietf.org>
> https://www.ietf.org/mailman/listinfo/dmarc <https://www.ietf.org/mailman/listinfo/dmarc>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

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

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

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