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:<[email protected]>
[email protected]
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
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
