Re: [dmarc-ietf] Priming the Pump for Discussion - Ratchets p=quarantine
Hello, Is the period for abstentions on posting now over? The designers of DMARC anticipated this fear, and built several different transitional states, or ratchets, into the protocol, including: - "quarantine" as a value for "p=" ( https://trac.ietf.org/trac/dmarc/ticket/39) After reading several opinions on this, I do not think that “quarantine” means a transitional state between “reject” and “none”, according to the majority. The distinct “quarantine” and “reject” options exist, solely because the SMTP protocol does permit this distinction. Both options protect the domain equally good. Both options are only hints from the domain owner, which hints can be altered by the recipient (the recipient can handle all “reject” as “quarantine” and all “quarantine” as “reject”). I have not read the recent drafts. In case the drafts do not discuss, while reject is better than quarantine, it is not better: reject and quarantine are equally good final states. There are two exceptions: • Reject allows the sender of emails (the administrator/postmaster) to get an (immediate) notification, when the DKIM+DMARC implementations on sender and receiver disagree, quarantine does not allow such feedback. The administrator can take actions to fix the implementation, based on the feedback for a concrete message. • Reject allows the sender (the user, mailbox owner) to look for alternative means to contact the recipient, once the mail is immediately returned. When quarantine is used, a DMARC/DKIM implementations on an end has errors, or transitional DNS problems happen, and the recipient does not (regularly) check its spam folder, the mail is essentially lost and nobody is notified. With the above exceptions in mind, that have negative impact only when quarantine is used, it is biased to state, that quarantine is a transitional state between reject and none. Past experience showed, that reducing the ratches, by striking quarantine out, leads to endless mail threads, which nobody can follow. I think it is realistic to mention the above two exceptions. In fact, as somebody mentioned two years ago, the DMARC wording suggests that reject is stronger than quarantine. The wording at https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-02#section-6.7.4.1 (pct fallback to quarantine from reject) does currently support this concept. As far as I remember, there was consensus to remove this text. (pct=10; p=reject shall fall back to p=none, not to p=quarantine). If the reasoning on why shall QUARANTINE be kept, is taken into account (=because SMTP allows this variant), the reasoning in no way explains, why is quarantine a transitional state. My opinion is, that the current editing process does improve the situation, but DMARC/DKIM will remain complex topics. Even if a misunderstanding on why is reject stronger (better) protection than quarantine remains, there will still be improvements in other areas. The “extreme position” below is not extreme enough: since SPF is pointless in indirect mail loops, SPF records shall never be touched when dealing with DMARC. I agree with the extreme position, but I do not believe there will be consensus on it. Greetings Дилян - Message from Todd Herr - Date: Tue, 6 Jul 2021 08:45:35 -0400 From: Todd Herr Subject: [dmarc-ietf] Priming the Pump for Discussion - Ratchets To: IETF DMARC WG Greetings. The theoretical goal of any domain owner that publishes a DMARC record is to transition from an initial policy of p=none to a final one of p=reject, because it is only at p=reject that DMARC's intended purpose of preventing same-domain spoofing can be fully realized. Many domain owners see the transition from p=none to p=reject as a black box, in that they believe they have no way of knowing what the full impact of such a change might have on their mail, and they fear irreparable harm to their mail if they make a mistake. The designers of DMARC anticipated this fear, and built several different transitional states, or ratchets, into the protocol, including: - The "pct" tag (https://trac.ietf.org/trac/dmarc/ticket/47) - The "sp" tag (https://trac.ietf.org/trac/dmarc/ticket/48) - "quarantine" as a value for "p=" ( https://trac.ietf.org/trac/dmarc/ticket/39) All of these are designed to allow the domain owner to request that some, but not all, of its mail be held to stricter authentication standards so that the domain owner can dip a toe in the water before jumping in. The ratchets have introduced some problems, though: - The 'pct' tag doesn't exactly work like it's intended to, and really can't because of the nature of mail flow, unless there is a high volume of failed authentication for the domain in question. (There is a much longer discussion of this in section 6.7.4, Message Sampling, of draft-ietf-dmarc-dmarcbis-02.) - Some domain
[dmarc-ietf] Endless Email Loops with Aggregate Reports
Hello, DMARC aggregate reports can and do cause endless loops, too: A site publishes an email address for receiving aggregate DMARC reports. The rua-address bounces the messages (aggregate report) received there and the bounces does not validate the DMARC policy. So on the next reporting period a new aggregate report is sent, stating that the reply on the previous report failed DMARC validation. Unlike endless email loops caused by message-specific failure reports, the endless email loops caused by aggregate reports are by design rate-limited: one email per reported domain and reporting period. A wait to reduce the possibility into getting in such loops is toT send the reports FROM:<>. That said I propose recommending in DMARC, that both the message-specific reports and the aggregate reports are sent FROM:<> or NOTIFY=NEVER. Shall I submit an erratum to RFC7489? Regards Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy
Hello Jim, Do you want to split yourself reporiting and policy and create two separate documents, or do you know somebody wiliing to perform the separation? I cannot imagine why shall one want to read and understand only reporting or only policy and thus I do net understand for which target group will be these separated documents. The current documents are suitable to achieve their aim. (Well, to contradict myself, I would like to read and understand all the RFCs, so a single RFC containing all current RFCs would be enough, but obviously, I cannot read and understand such RFC). if you implement DMARC filtering on incoming emails you get less spam. If you implement DMARC filtenig on outgoing emails (say publish policy p=reject), you deploy DKIM and then some trust/reputation can be built in the DKIM domain, similar to IP reputation, so that your future emails are more likely to be delivered, at least in theory. You do not have interest to name this magic anyhow, you have interest on getting less spam and higher deliveribility of your emails. You do not have to implement section 8 in order to achive the aforementioned goals. When filtering incoming emails, obviously, without having to articulate this explicilty, you have to follow section 6.6. To verify that your DMARC works as expected, the reports mentioned in section 8 are a nice mean. You can call your product a DMARC implementation even if it does not do DKIM signing/verifying correctly. Why do my mails for jo...@taugh.com get rejected, unless I send them over the MLM? A propos “Is there any recommendation to send DMARC message-specific failure reports FROM:<>”: * Scott, the purpose of such a recommendation is to have a system, which does not cause mail loops, ending with stored copies of 60 000 sent reports. If that site published TXT record for mail.modernwebsite.pl, it does not ensure that in half an year I will not enter another mail loop (half an year ago I had a similar one). * I do sent now my reports ENV FROM:<> and from the correspondence so far neither somebody said that there is such a recommendation already, nor that such a recommendadion is bad. The purpose of the <>-recommendation is to prevent others falling in such a mail loop trap. Under this circumstances I put the case under “Collecting DMARC issues and nits for DMARC WG phase III - DMARC standardization”. Regards Дилян - Message from Jim Fenton - Date: Mon, 27 May 2019 10:23:42 -0700 From: Jim Fenton Subject: Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy To: Dave Crocker , John R Levine Cc: dmarc@ietf.org On 5/25/19 1:53 PM, Dave Crocker wrote: Ultimately, you are asking marketing questions, not technical ones. OK, so let me ask a technical question: What is the technical justification for the requirements in Section 8? For other protocols, there are mandatory-to-implement requirements (RFC 6376 section 3.3 for example) that exist in order to ensure interoperability between senders and receivers. But implementation of DMARC policy and DMARC reporting can separately be useful without the other. Aren't the requirements in Section 8, which effectively say "you need to do this and this to call yourself a DMARC implementation" really a marketing, not a technical consideration? Does this belong in the spec? -Jim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc - End message from Jim Fenton - ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Is there any recommendation to send DMARC message-specific failure reports FROM:<> ?
Hello John, at SMTP level the server communicates EHLO mail.modernwebsite.pl and ENVFROM:<>. There is no TXT record for mail.modernwebsite.pl so SPF fails and cannot align. The email itself contains “From: mailer-dae...@modernwebsite.pl (Mail Delivery System)” without DKIM signature. ⇒ DMARC validation fails. You can give it a try and send yourself a message to “postmas...@modernwebsite.pl”, the answer will be (expanded from ): unknown user: "template" Unfortunately I had another loop back in September 2018. I do not remember the details. Given that this can happen again to somebody else, it is better to have recommendation sending the message-specific reports with FROM:<> or NOTIFY=NEVER, or at least some text elaborating on the attack. Regards Дилян - Message from John Levine - Date: 26 May 2019 10:44:39 -0400 From: John Levine Subject: Re: [dmarc-ietf] Is there any recommendation to send DMARC message-specific failure reports FROM:<> ? To: dmarc@ietf.org Cc: dilyan.palau...@aegee.org In article <20190526050958.horde.6vaaxrzkglqyej4uov0v...@webmail.aegee.org> you write: Hello John, in case of modernwebsite.pl: DNS TXT _dmarc.modernwebsite.pl is "v=DMARC1; p=reject; pct=100; rua=mailto:postmas...@modernwebsite.pl; ruf=mailto:postmas...@modernwebsite.pl; aspf=s;adkim=s;" Emails to postmas...@modernwebsite.pl are answered with “Undelivered Mail Returned to Sender”. The answers do not align to the DMARC policy reject, so a new message-specific failure repot is sent. Just out of curiosity, where do the reports come from? I see their SPF record says "mx a". ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc - End message from John Levine - ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Improving feedback using additional status codes
Hello Douglas, RFC 7372 describes these status codes. To my knowledge these are not used. SPF helps on DMARC with MTAs, which cannot include DKIM signature under circumstances (e.g in bounces). In all othercases SPF does not provide added value to DKIM. If you want errors about failed DKIM validation, remove the SPF records, set DMARC policy reject and scan your logs for rejected messages to see on which messages DMARC/DKIM have failed. Regards Дилян - Message from "Douglas E. Foster" - Date: Sat, 25 May 2019 15:42:57 -0400 From: "Douglas E. Foster" Reply-To: fost...@bayviewphysicians.com Subject: [dmarc-ietf] Improving feedback using additional status codes To: dmarc@ietf.org The genius of DMARC, as compared to DKIM and SPF alone, is the feedback component. Unfortunately, sender authentication remains challenged by these issues: Limited deployment of DMARC feedback between senders and receivers. Significant levels of SPF and DKIM validation errors, on legitimate mail, even when indirect mail is not involved. Handling false positives becomes a significant obstacle to implementation of Sender Authentication by receivers. When the sender has not implemented DMARC, the recipient has difficulty communicating with the sender about Sender Authentication problems. Finding a knowledgeable employee is difficult and time consuming, so it will rarely be attempted. (And I have tried it.) I propose two improvements to deal with this issue. The first is to define another feedback mechanism using message reception status code. The second is intended to reduce DKIM verification errors, and will be posted later. PROPOSAL When a recipient detects an SPF or DKIM problem, it can provide immediate feedback to the sender with message status codes. I think these are a complete list of the conditions which would need a result status defined. The approach should be entirely upward-compatible with the existing infrastructure. Message Success with SPF warning Accepted despite SPF=NONE & Source IP not in MX listAccepted despite SPF=NEUTRAL Accepted despite SPF=SOFTFAIL Accepted despite SPF=FAIL Accepted despite SPF TempError Accepted despite SPF PermError Message PermFail because of SPF Rejected because of SPF=NONE & Source IP not in MX list Rejected because of SPF=NEUTRAL Rejected because of SPF=SOFTFAILRejected because of SPF=FAIL Rejected because of SPF TempError Rejected because of SPF PermError Message TempFail because of SPF TempFail due to SPF TempError Message accepted despite DKIM Accepted despite DKIM PermError Accepted despite DKIM TempError Message PermFail because of DKIM (not recommended) Rejected because of DKIM PermError Rejected because of DKIM TempError Message TempFail because of DKIM TempFail because of DKIM TempFail Since DMARC evaluation is based on SPF and DKIM evaluated together, the above codes would seem applicable even with DMARC enforcement. I think these additional codes should be sufficient: DMARC PermError (invalid policy record) DMARC TempError (problem retrieving policy record.) Is this reasonable? Doug Foster - End message from "Douglas E. Foster" - ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Is there any recommendation to send DMARC message-specific failure reports FROM:<> ?
Hello, is there already any recommendation from IETF to send DMARC message-specific failure individual (non-aggregate) reports with FROM:<> (or NOTIFY=NEVER)? Consider this scenario: an email from a domain, with DMARC policy “p=reject; ruf=postmaster@domain” fails validation. A message-specific report is sent to postmaster@domain. The report is bounced (or there is any reply on it) and the reply is again From: that domain and does not validate DMARC. In turn a new message-specific report is sent and this loop ends, when some disk gets full. With FROM:<> or NOTIFY=NEVER there would be no such loop. Note, that DMARC aggregate reports do not have this problem. Regards Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
