Hector Santos writes: > o Concerning p=reject: > > - Our focus on p=reject should be expanded to include p=quarantine > as they're both challenging. We should perhaps categorize these under > 'Restrictive Policies'.
I will repeat the point I made in the mic in IETF: I think DMARC should really be explaining what the senders is doing and not trying to give instructions to the receiver. I.e., the dmarc should tell that: 1) Sender does not authenticate email (cannot be expressed in dmarc currently) 2) Sender might be authenticating email, but there is some email that significant part of email flows that are not authenticated (p=none?) 3) Sender is trying to authenticate all email, but there might be some parts where there might still be some unauthenticated emails going through (p=quarantine?) 4) Sender is authenticating all emails and emails which fails authentication are not originating from the sender or has been modified in transit (p=reject?) There was people pointing out that there would still be usefull to know the senders policy what can be done to the email after knowing whether the authentication was successfull or not, i.e., p=reject, p=quarantine etc. I am not that sure this is something that needs to be expressed. The receiver will use its own policy and other information (i.e., the actual content of the email) to decide that anyways. The policy might be that emails are accepted, but there is big warning saying the email failed authentication and can be phishing attack (I think gmail has been doing that kind of warnings, in case emails from domains which usually have dkim signature are missing dkim signature), or the policy might be that in addition that the system will render all links in email in such way they can't be clicked etc. > - I highlighted that "SPF Comes First" before DMARC or DKIM is > known. It is entirely possible that an SPF restrictive policy (-ALL, > Hard Fail) can preempt the payload transfer, causing a rejection > before the DATA is reached. DMARCbis does acknowledge this > possibility, mentioning that receivers might process SPF rejects > before DMARC is known. As those implementations do SPF outside the DMARCbis context, there is nothing we can do for them, thus we do not even need to consider them. I.e., we can safely ignore that discussion from the DMARCbis, as it is outside the scope of DMARCbis. If they are the only people who want to keep requiring SPF for DMARCbis, then we can safely remove SPF from the DMARCbis, as only people who want to keep SPF in DMARCbis are not going to be implementing DMARCbis :-) Section 5.7.2 do require that implementations MUST perform DKIM signature verification checks, and also say MUST perform SPF verification checks, so any implementation which only does one is not conforming DMARCbis. If we can't change from the MUST to not mentioning SPF at all, perhaps we should go from MUST implement SPF to MAY implement SPF, i.e., say that yes, you can still use SPF, but it is no longer mandatory to implement. As DMARC is only small piece of the whole mail recipient policy engine, the overall engine is already using lots of other pieces and can and most likely will use SPF as input anyways, regardless whether we require it in 5.7.2 or not. -- kivi...@iki.fi _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
