Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication

[Hector Santos <[e-mail]>]

On 6/11/2019 1:01 PM, Дилян Палаузов wrote:
> Hello Alessandro,
>
>> I'd propose bullets like the following for Section 12.4:
>>      o  The authentication status of the message should be visible.
>>
>
> For DMARC policy reject, the failed status will not be visible in the MUA, because the mail will not reach the
> recipient.  Likewise for the policy quarantine, because this policy means “do not deliver” (and do not reject, but do
> something different).

Like move to "spam/junk box" which potentially exposes the failed 
transaction to the user's eyeballs.

> So if the DMARC evaluation status for policies Quarantine or Reject is shown, it will be PASS.

I agree with you, a reject policy should not expose the user to the 
message at any level and if followed by the hosting server, the MUA 
will never see a FAIL but a PASS status.

However, there is also a school of thought where the written 
"rejection" semantics was not to be taken literally because in their 
opinion, no big guy rejects mail.  It was proven incorrect, but the 
philosophy is such in always letting the user decide, which means, all 
suspect mail goes into a "spam box."   This is part of the local 
policy concept how a receiver hands this at the system wide level 
and/or per user level.

SPF had a similar problem too especially now when it is combined with 
DMARC.

SPF -ALL Hard Policies allows for instant rejection before the DATA 
(payload) is transferred.  For DKIM, the DATA is needed in order to do 
DKIM processing.  If no DATA, no DKIM, therefore no DKIM POLICY 
concept can be processed.

However, for the sake of DMARC, some believe SPF -ALL should not 
reject before DMARC can be processed.  So if the DMARC policy is 
p=none and SPF policy is -ALL, this is, imo, a conflict in protocol 
design unless DMARC has it explicitly stated that it policies 
overrides SPF.  I don't think it does but I believe there is new breed 
and school of thought among DMARC administration that believe that is 
the case.  DMARC is always processed which means it is already 
received and SPF never rejects until DMARC is known.

Back when SPF and SenderID were "invented,"  SenderID was a Payload 
version of SPF.  So it basically did the same thing as SPF but it 
required the DATA because it wanted to get the SPF policy by 
extracting the 5322.From address called the PRA  "Purported 
Responsible Address."  See https://tools.ietf.org/html/rfc4407

In general, the PRA domain will equal the Return Path Domain for 
private 1 to 1 mail, but differ for list mail.  This is what we have 
today with DKIM and List Messages causing all the issues we are having 
-- why we are still here 13+ years later.

With PRA,  the SMTP client can sent the Author's address as part of 
the MAIL FROM command.  See https://tools.ietf.org/html/rfc4405   It 
used the ESMTP key word SUBMITTER:

   C: MAIL FROM:<return-path> SUBMITTER=pra

If your receiver supported this ESMTP extension, you will definitely 
have some clients use it. An example in today's log:

   C: MAIL FROM:<[e-mail]> 
SUBMITTER=[e-mail]

So what the client is saying, you can use the return-path domain 
"mail.areopency.us" for SPF lookup and/or the submitter domain 
"aeropency.us" for SenderID lookups.

The PRA protocol served as an optimization because you could avoid 
receiving the payload data if the SPF policy failed. But you can also 
use the PRA domain to look up too if the SPF record did not exist. You 
would not need to get the DATA just to read the From: address.

In my opinion, this is what is needed now with DMARC.

An SMTP receiver having the "Author domain" passed via the MAIL FROM 
would do a lot for optimization.  You can see if there a DMARC policy 
at the SMTP level and go from there. We are always comparing to two 
anyway. More can done to reduce major overhead by using filters at 
SMTP before DATA is transferred.

SenderID and SUBMITTER was recently marked as historic. I have 
proposed the idea to use SUBMITTER keyword to leverage the existing 
implementation for DMARC purposes.

> For policy None, I doubt that showing the authentication status has added value.

There is also DKIM verification which can VALID or INVALID where 
INVALID can be promoted to NONE (view invalid as no signature).  That 
can have value.  POLICY is just how failure should be handled. So a 
MUA seeing status:

    DKIM=FAIL, POLICY=NONE

can tell the user not to trust the message over just seeing the 
promoted label.

    DKIM=NONE, POLICY=NONE

I say "promoted" because the concept took something clearly invalid to 
appear as it never existed, which logically is a "better" unknown 
position to be in.

Anyway, I agree with you, I would not want to pass failed messages 
with a domain policy p=reject|quarantine getting to user's eyeballs.

-- 
HLS