Re: [dmarc-ietf] Some Proposed Language for a New pct Tag Defintion
Hello, for me this wording of pct=0 is not clear enough, why the value is necessary. Why the value is necessary can be explained by: When seeing pct=0 mail intermediaries should munge the From: header. This allows mail operators to detect problems with DMARC deployment, before strict DMARC policy is applied. Greetings Дилян On Fri, 2021-07-30 at 16:06 -0400, Todd Herr wrote: > Following on to the recent discussion about the pct tag, and > specifically the disallowing of any values other than 0 and 100, I > propose the following text and look forward to your comments: > > pct: (plain-text integer; OPTIONAL; default is 100). For the > RFC5322.From domain to which the DMARC record applies, the > "pct" > tag is the percentage of messages producing a DMARC result of > "fail" to which the Domain Owner wishes its preferred handling > policy be applied. However, this MUST NOT be applied to the > DMARC-generated reports, all of which must be sent and received > unhindered. Possible values are as follows: > > 0: A request that zero percent of messages producing a DMARC > "fail" result have the specified policy applied. While this > is > seemingly a non-sensical request, this value has been given > special meaning by some mailbox providers and intermediaries > when combined with "p=" values other than "none". In those > cases, in can result in changes to message handling, and/or > DMARC reporting for the domain publishing such a policy. In > some instances of altered reporting, it is possible that the > altered reports may reveal intermediaries whose handling of > the > domain owners' mail could cause it to produce a DMARC result > of > "fail" when it reaches its final destination. > > 100: The default, in which a request is made that every > message > that produces a DMARC "fail" result will be subject to > application of the specified policy. > > I'll check on this thread on Monday to see where things stand... > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ratchets - Disallow PCT 1-99
Hello Ale, please explain why this recommendation is done … On Thu, 2021-07-22 at 20:32 +0200, Alessandro Vesely wrote: > > How about something more or less like the following? > For uniform behavior, MLMs are better off applying the same > mitigation > technique irrespective of the current content of any DMARC > records. > However, some MLMs are known to decide whether to apply that > change or > not based on the existence of an author's domain DMARC record and > the > value of the "p" tag therein. In any case, MLMs MUST NOT consider > the > value of the "pct" tag in order to make such decision. by appending: The reason is, that operators can verify the correct setup, before switching to a strict DMARC policy. After installing “pct=0;p=reject" the domain owner can verify by reading the aggregate reports that 100% of the messages from the owned domain have aligned DKIM. (Otherwise MLM-NOT-mаngled messages will be reported as failed, too). See also the last paragraph of https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-dmarcbis-02#section-6.7.4.2 Shortcomings of the "pct" Tag >>> * "0" - A request that zero percent of messages producing a DMARC "fail" result have the specified policy applied. While this is seemingly a non-sensical request, this value has been given special meaning by some mailbox providers when combined with certain "p=" values to alter DMARC processing and/or reporting for the domain publishing such a policy. <<< I think this paragraph needs to be changed. Proposed new wording: * "0" - A request that zero percent of messages producing a DMARC "fail" result have the specified policy applied. While this is seemingly a nonsensical request, MLM modifying the message shall rewrite the From: header in this case. This way the initial domain owners, by evaluating aggregate reports, can verify, that their setup is correct, before enforcing strict DMARC policy. Greetings Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)
Hello, lets say a site signs an email with both rsa and ed25519 algorithms. This site wants to know, whether the recipient can validate the ed25519 signatures, so that in the future rsa signing for that receiving site can be skipped (or errors in the ed25519 implementation fixed). For this to work the receiving site must put in the report information about each aligned dkim signature, saying which public key-name was used. Greetings Дилян On January 25, 2021 2:25:13 AM GMT+02:00, "Brotman, Alex" wrote: >Hello folks, > >Some time ago, an issue[1] was brought to the list where which DKIM(s) >being reported is not clear in RFC7489 [2]. There was a short >discussion, though no clear resolution before conversation trailed off. >It seems like there were points that may need to be discussed. One was >whether the reporting SHOULD report all signatures, regardless of >alignment or validity, or perhaps just the one that aligns (if there is >one). There was also another question if there should be a limit to >the number of signatures reported so that it remains sane. > >We'd like to try to get this resolved within about two weeks. Thank >you for your feedback. > >1: >https://mailarchive.ietf.org/arch/msg/dmarc/9-V596yl2BBaUzCNaDZB1Tg1s4c/ >2: https://tools.ietf.org/html/rfc7489#section-7.2 > >-- >Alex Brotman >Sr. Engineer, Anti-Abuse & Messaging Policy >Comcast > >___ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Forensic report loops
Hello, Am Freitag, dem 15.01.2021 um 16:31 -0500 schrieb Douglas Foster: > I would think this should prevent problems if at least one complies: > > Reports should be sent from a no-reply account so that any auto-reply > will be rejected as invalid recipient. DMARC reporting SHOULD NOT > occur for such messages, even if the DATA section is accepted before > rejecting or discarding the message. > > Report reception accounts should be dedicated to this purpose. > Unacceptable incoming messages to this account SHOULD be excluded > from DMARC reporting, regardless of reason. Accepted messages MAY > also be excluded from DMARC reporting. > this text suggests WHAT to do, but not WHY to do it. In my opinion any suggested workflow shall be accomplished by problem description, so that the implementers can understand the rationale of the proposed solution (and thus higher the chances, that the endless loops are prevented). I put the problem description in my previous mail on this mailing list. Greetings Дилян > Doug Foster > > On Fri, Jan 15, 2021, 11:25 AM Murray S. Kucherawy > wrote: > > On Thu, Jan 14, 2021 at 9:51 AM Kurt Andersen (b) > > wrote: > > > I thought that we discussed that ticket and decided that the > > > incidence of problems was low enough to warrant a "WONT FIX" > > > determination. > > > > > > > > > https://mailarchive.ietf.org/arch/browse/dmarc/?gbt=1&index=W3uGPEpT3Yi5lqKntZXyL8jkNjk > > > > > > > > > We did, and if it had only ever come up exactly once, I might think > > nothing of it. But here it is again. Now I'm inclined to think > > where there's smoke there's fire, and this might require more > > consideration. > > > > -MSK, participating > > ___ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Forensic report loops
Hello, Am Donnerstag, dem 14.01.2021 um 01:22 -0800 schrieb Steven M Jones: > On 1/13/21 20:29, Murray S. Kucherawy wrote: > > > > How are implementers dealing with forensic report loops? > > The question of whether such a thing is actually ever seen in the > wild > should be asked, if only to document that it was asked and answered. > See > prior "this is a vanishingly small number who cares" discussions. Imagine a case, where two sites sending forensic reports on failures exchange messages and the one site is misconfigured: on each received forensic report it sends a bounce, which bounce does not DMARC-align. This the same problem as with a misconfigured site sending Aggregate reports, but does happen once a second, not once a day. By sending reports with return-path:<> you prevent the misconfigured recipient of the report to generate a bounce, which bounce must DMARC-align, but does not DMARC-align. I want to remind on real-world cases addressed on this mailing list • On 25 May 2019 with Subject “Is there any recommendation to send DMARC message-specific failure reports FROM:<>”? • On 31 May 2019 with Subject “Endless Email Loops with Aggregate Reports” • On 4 JUne 2019 with Subject “Endless Loops with DKIM reports” which addresses reporting per “RFC 6651 Extensions to DKIM for Failure Reporting” - this is not much different than forensic reports that lead to https://trac.ietf.org/trac/dmarc/ticket/30 “Endless Email Loops with Aggregate Reports”. I have not read the thread “Ticket #28 - Failure report mail loops”. A possible approach is not to send failure reports for messages received on the address for accepting aggregate/forensic reports. These messages shall just be excluded from all calculations. Does anybody compare the number of messages sent from her host1 to the host2 of somebody else, with the number of reported messages in the aggregate report? If the numbers do not match, does somebody apply negative spam weights for host2? Greetings Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #39 - remove p=quarantine
Hello, I do no see the point of having all the discussions here, as nobody is capable to read and understarstand all written emails in their whole quantity. I personally do not follow the discussions anymore, apart from reading the subjects… On Mon, 2020-12-07 at 17:55 -0800, Brandon Long wrote: > > > On Wed, Dec 2, 2020 at 11:09 AM Murray S. Kucherawy > wrote: > > On Wed, Dec 2, 2020 at 6:47 AM Dotzero wrote: > > > p= DID NOT mistakenly choose to use the language of receiver > > > actions. p= represents the domain-owner request to the receiver > > > as to the disposition of messages which fail to validate. Any > > > reading of "concern" is supposition on the part of yourself or > > > other self appointed interpreters of the mind of the domain-owner > > > or administrator. The vocabulary is perfectly fine as it > > > accurately describes the request being made. It makes no attempt > > > to read the underlying reasoning behind the request because, > > > surprisingly, there is likely to be a wide range of underlying > > > reasoning behind why various domains publish the policies they > > > publish. This is an interoperability standard, not a seance. > > > > > > > > > Not sure I agree. > > > > I have long held a quiet dislike for "quarantine" because that has > > a particular meaning to milter implementations. Specifically, > > milter can render one of several final results about a message, one > > of which is actually called "quarantine". It means "park this in > > the queue indefinitely until a human decides what to do with it." > > There's no indication to the operator that such a job is waiting > > for review unless one goes and looks for such things. The upshot > > of this is that quarantining in that environment can become a > > denial of service attack if I send you enough messages that end up > > getting handled that way and your queue disk fills, or the queue > > takes an inordinately long time to process because these have piled > > up and need to be inspected. > > > > Certainly not all implementers will trip on this (maybe none will) > > but it's an argument to me in favor of picking a word or set of > > words that describe what the domain owner thinks of the message, > > rather than what the domain owner thinks you should do with it. > > > > > Hmm, reading this thread, I think one missing feature in the dmarc > spec is passing the expected disposition in the authres header, since > presumably the evaluation is at smtp time, but the mailbox > delivery itself would need to know it. One could use the dmarc= > names and look up the dmarc policy itself to also figure that out > with some amount of work. … and in July 2019 there was a discussion with the subject „Reporting DMARC policy in A-R header fields“ on this mailing lists. Below is an off-list consensensus to put the applied policy in the A-R from that thread, that was not sent eventually over the mailing list: From: Scott Kitterman To: Дилян Палаузов Subject: Re: Reporting DMARC policy in A-R header fields Date: Wed, 31 Jul 2019 10:49:32 + I agree with your statement. MTA does the percentage test and puts the policy to be applied in A-R for the MDA to consume. I'm working off my phone, so typing is slow. I don't mind being more verbose once I'm at my laptop, but it will have to wait. Please let me know if it's still uncertain. Scott K On July 31, 2019 10:35:15 AM UTC, "Дилян Палаузов" wrote: >Hello Scott, > >you are too spare in your words. > >My understanding of the conversation so far is that only the MTA does >the sampling for failed messages based on p= and >pct= . The A-R header is supposed to carry information, whether the >message validated or failed DMARC and for failed >validation, what the MDA shall do with the message (basically >quarantine or deliver). > >If you put the policy to be applied in the A-R, then it is not the >policy from DNS, but rather the disposition to be >applied. > >Regards > Дилян > >On Wed, 2019-07-31 at 10:28 +, Scott Kitterman wrote: >> I suppose you could also add something like dmarc.pct=50 too, but I >think that would add complexity to no benefit. As long as you make the >sample decision once, it works out the same. For the case where a >message wasn't selected due to sampling then I'd put the policy to be >applied in A-R so the MDA doesn't have to worry about the percentage. >> >> Scott K >> >> On July 31, 2019 5:56:26 AM UTC, "Дилян Палаузов" > wrote: >> > He
Re: [dmarc-ietf] Ticket #39 - remove p=quarantine
Post Scriptum: DMARC can say one of two things: -- all mails for a domain are DKIM-signed and aligned, according to the domain owner -- not all mails for a domain are DKIM-signed and aligned (e.g. when the DMARC policy is absent, or p=none) according to the domain owner Does the DMARC specification need to propose what to do with emails in the first case above, when the DKIM-signature is not-valid/aligned? Some people will say yes. I say no: there is no need to give one of two possible advices on this (and there is no means to enforce the advice) Anyway, as I said I do not expect any consensus on this. Please consider including in the DMARC specificaiton a discussion on what is reasonable, e.g as outlined in the email below, and elaborate pros and cons on r=reject and r=quarantine. As the topic is controversal, it shall be presented as controversal in the specification. I do not follow the discussions here, I suppose that by now is addressed, that „p=quarantine;pct=0“ should be interperted as „do MLM- mungling”, and p=none to mean „no MLM mungling”. ⇐ From: Vladimir Dubrovin To: Dotzero , Vladimir Dubrovin CC: IETF DMARC WG , Дилян Палаузов Subject: Re: [dmarc-ietf] Abolishing DMARC policy quarantine Date: Fri, 14 Jun 2019 19:25:02 +0300 Nope, I mean 2 different things. 1. Why quarantine is useful (with pct=0). For example this mailing list (dmarc@ietf.org) performs From rewrite (aka From munging), e.g. dubro...@corp.mail.ru is replaced with dubrovin=40corp.mail...@dmarc.ietf.org. It's because corp.mail.ru has a strict DMARC policy (reject). dotz...@gmail.com is not overwritten, because gmail.com has p=none and ietf.org only overwrites From only for domains with "quarantine" and "reject" policies. It's quite common behavior. If you are implementing DMARC for a new domain (let's say example.org), you usually start with "p=none". With p=none you receive reports for failed DMARC for different lists, like ietf.org. Before switching to stronger policy (p=reject), you may want to know which mailing list will still fail DMARC, and which lists perform From munging and, as a result, do not fail DMARC. For this purpose, before switching to "p=reject" it's useful to switch to "p=quarantine;pct=0". After this, you will only see mailing lists without From munging in DMARC reports. 2. Why quarantine should not be used with pct different from 0 If you start enforsing strong DMARC policy with "p=reject" and you have some previously uncatched misconfiguration (e.g. wrong envelope-from address in some once-in-the-month mailing), you see DMARC failures in your logs and you can react to this failures and even re-send the messages affected. If you start with "p=quarantine" you have no feedback except reports, and reports are received with a huge lag (up to 2 days) and do not provide sufficient information to catch the exact problem and you can not re-send the quarantined messages. ⇒⇒ On Wed, 2020-12-02 at 13:15 +0200, Дилян Палаузов wrote: > Hello, > > On Tue, 2020-12-01 at 15:55 -0800, Dave Crocker wrote: > > On 12/1/2020 3:17 PM, John R Levine wrote: > > > #39 proposes that we remove p=quarantine. I propose we leave it > > > in, > > > even if it > > > is not very useful, because trying to remove it would be too > > > confusing. > > > > process, I suggest this issue gets some meaningful discussion. My > > email > > archive indicates it hasn't gotten any discussion at all. > > This was discussed under the subject “Abolishing DMARC policy > quarantine” in June 2019. There was no consensus. SMTP offers this > distinciton and this is mirrored in DMARC. In particular, senders > are > free to publish p=quarantine and receipients are free to interpret it > as p=reject. Senders can publish p=reject and receivers are free to > interpret it as p=quarantine. > > Moreover, some destination addresses do not have the concepts of a > quarantine. E.g an address that accepts commands for mailing lists > managements. Such addresses can either accept or reject the message > - > there is no quarantine, so interpreting published p=quarantine as > p=reject is feasible. > > Recalling the discussion from June 2019 I do not count on any > different > consensus, if it the discussion happens here again now. > > Greetings > Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #39 - remove p=quarantine
Hello, On Tue, 2020-12-01 at 15:55 -0800, Dave Crocker wrote: > On 12/1/2020 3:17 PM, John R Levine wrote: > > #39 proposes that we remove p=quarantine. I propose we leave it > > in, > > even if it > > is not very useful, because trying to remove it would be too > > confusing. > > process, I suggest this issue gets some meaningful discussion. My > email > archive indicates it hasn't gotten any discussion at all. This was discussed under the subject “Abolishing DMARC policy quarantine” in June 2019. There was no consensus. SMTP offers this distinciton and this is mirrored in DMARC. In particular, senders are free to publish p=quarantine and receipients are free to interpret it as p=reject. Senders can publish p=reject and receivers are free to interpret it as p=quarantine. Moreover, some destination addresses do not have the concepts of a quarantine. E.g an address that accepts commands for mailing lists managements. Such addresses can either accept or reject the message - there is no quarantine, so interpreting published p=quarantine as p=reject is feasible. Recalling the discussion from June 2019 I do not count on any different consensus, if it the discussion happens here again now. Greetings Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] About user notification in the MUA
Hello, when a message is wrongly evalutated as spam, and is left therefore unnoticed, it is nobody’s fault. You can signal the users as you want, including the users, which just redirect mails on your host, and do not utilize the “Spam” store there. A message is either likely spam (subject to signaling), or it is not likely spam. When the message is likely spam, you can signal the sender by sending a non delivery report. That report can contain information, entered by the intended recipient, like snail mail address or phone number. If you signal the sender (by rejecting at SMTP level) you do not need a signaling method on the recipients’ side, that works across all MUAs. Besides, there is no “nobody is fault for the overseen signaled message”. If you run a server with 10 local users and 10 000 redirecting addresses (aliases), you have to use a signaling method, that does not break the DKIM-signature, and works for redirected emails. For users that utilize just redirecting there is no “neither likely spam, nor unlikely spam” category. And the other users also do not need such category. Greetings Дилян On Sun, 2020-06-07 at 23:04 +, Douglas E. Foster wrote: > I am trying to play by the rules and not chase topics outside the one > assigned, but since several have jumped on my comment, I will follow > up briefly. > > Dave Crocker wrote > Since there has been a demonstrated lack of efficacy in this sort of > display, there needs to be an objective basis for knowing that any > new such requirement will be useful. > > Every email filtering product that I have examined has provided a > user-signaling system, using one or more of the following: > * tagging the subject, > * adding text as a body header or body footer > * converting the suspect message into an attachment of a > replacement message, > * soft-quarantining, where the user has unrestricted control to > release the message from quarantine. > Given that market reality, I conclude that most vendors and their > customers believe that user-signalling is useful. The signalling > system does not have to prevent every mistake for the signal to be > useful. > > The problem with all current notification methods is that they are > relatively primitive, often communicating nothing substantive about > the suspicious message characteristics. They also work against other > security mechanisms. > * Any form of tagging breaks DKIM signatures, reducing the > credibility of the message if it is auto-forwarded for any reason. > > * The tagging also becomes tattooed to the message and its replies, > rather than being restricted to the trust domain that assigned the > tag. One example should suffice: a message was tagged with [SPAM?] > because the sender had an error in his SPF record and I was trying to > enforce SPF. Then when my staff replied, the originator treated the > reply as spam because the word SPAM was still in the subject line > when he received it! > We need a user notification mechanism that is local to the trust > domain and does not break DKIM signatures. You have already done the > heavy lifting for this interoperability problem with Authentication- > Results and ARC I am not expecting a "Standard" that requires every > implementation to notify every user in the same way. I am looking > for a guidance document that helps vendors to deliver products which > permit an organization to implement a notification policy which they > find to be effective and appropriate. IETF is the right > organization to take this on because the email filter, the mail > system, and the multiple MUAs are almost always a multi-vendor > configuration. > > df > > > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis / Re: Collecting DMARC issues and nits for DMARC WG phase III - DMARC standardization
Hello Murray, no, I am not volunteering. Regards Дилян On Tue, 2019-12-03 at 12:54 -0800, Murray S. Kucherawy wrote: > > > On Mon, Nov 18, 2019 at 7:49 AM Дилян Палаузов > wrote: > > who is going to work on DMARCbis document and is it realistic to finish it > > within a year? > > Are you volunteering too? > > -MSK > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARCbis / Re: Collecting DMARC issues and nits for DMARC WG phase III - DMARC standardization
Hello, who is going to work on DMARCbis document and is it realistic to finish it with a year? Regards Дилян On Thu, 2019-05-09 at 14:23 -0700, Seth Blank wrote: > With the group officially in Phase III of the DMARC WG charter, our work is > now to explicitly review and refine the DMARC specification, with the goal of > generating a standards track document. > > The draft-ietf-dmarc-psd experiment is part of this process, as is the > conversation about defining proper ARC reporting XML for DMARC reports. > > This email is an explicit CALL FOR ISSUES AND NITS about the DMARC spec which > you believe should be officially discussed as part of the DMARCbis process. > Please start a separate thread for each item you have. I'll make sure all are > properly in the issue tracker and get addressed. > > Please send in your items no later than *Friday, May 24th*. After this point, > we'll be focusing on progressing the DMARCbis process, not gathering new > issues. > > Below are a list of nits already in the datatracker. I'll be kicking off > threads for several other issues I'm aware of shortly. > > Thanks everyone! > > Seth, as Secretary > > Active issues for DMARCbis in the data tracker: > - SPF 4408 vs 7208: https://trac.ietf.org/trac/dmarc/ticket/1 > - Flow of operations text: https://trac.ietf.org/trac/dmarc/ticket/2 > - Two tiny nits in 6.6.2 and 6.6.3: https://trac.ietf.org/trac/dmarc/ticket/2 > - Definition of "fo" parameter: https://trac.ietf.org/trac/dmarc/ticket/4 > - Definition of "pct" parameter: https://trac.ietf.org/trac/dmarc/ticket/5 > - Fuzzy normative language around filenames: > https://trac.ietf.org/trac/dmarc/ticket/6 > - ABNF for dmarc-record is slightly wrong: > https://trac.ietf.org/trac/dmarc/ticket/7 > - Perverse incentives to use p!=none & pct=0: > https://trac.ietf.org/trac/dmarc/ticket/22 > - objection to maintaining registry for all participating public suffixes: > https://trac.ietf.org/trac/dmarc/ticket/24 > - Link to "URI" reference broken in several sections: > https://trac.ietf.org/trac/dmarc/ticket/25 > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Purpose of aggregate reports / Re:Two new fields in aggregate reports
On Fri, 2019-10-25 at 13:49 -0400, John Levine wrote: > In article you > write: > > What is the purposes of the aggregate and non-aggregate reports? What are > > non-goals? I asked several times here, > > nobody answered. Perhaps a discussion on the goals and non-goal would help. > > As far as I know, the point of DMARC reports is to help domain owners > understand who is sending mail that purports to be from them. In a > large organization it can be remarkably hard to track down every mail > server in every department or every subcontractor that might be sending > real mail with the domain in the From: header. > > The domain owners use the reports to do things like update SPF records > to include all of the sending hosts, update server configs to add DKIM > signatures, or to fix servers that are adding invalid signatures, and > often to shut rogue servers down that shouldn't have been sending mail > in the first place. > An additional purpose of the aggregate reports, currently missing but should be present in the future, is permit the domain owner to migrate from one software for DKIM signing to another software and from one type of signatures to another type of signatures (RSA→ED25519), allowing smooth transition. I mean: I domain owner uses software A for DKIM signing with a=rsa-sha256; when communicating to site B. This works reliably, as demonstrated by the aggregate reports. If the domain owner wants to check if software C also works reliably, when communicating to site B, the domain owner has to use software A and software C at the same time for signing (with differecnt selectors). The aggregate reports shall show, if software C (the other selector) causes any problems, while software A continues to sign the messages. The other use case is when software A continues to sign the messages, but in addition adds a=ed25519 signatures. There must be a way to evaluate, looking in the aggregate reports, if ed25519 between both sites works reliably, while rsa- sha256 does not cause any problems. This was previously rised on this list (Subj: spec nit - which DKIM to report, From: Tomki, on 21st June), I just want to make clear that this belongs to the purpose the aggregate reports should have. Regards Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Two new fields in aggregate reports
Hello Alessandro, I do not see how this helps for DMARC. An email either validates DMARC, or fails DMARC and the aggregate repors say per sending IP server (only direct mail flow is reported), whether DMARC validates or fails. With this information it is sufficient to determine, if the DMARC/DKIM implementations on sender and receiver are either both bug-free, or both have the same bugs. I do not see, how the information you ask to add, while interesting, does help DMARC. What is the purposes of the aggregate and non-aggregate reports? What are non-goals? I asked several times here, nobody answered. Perhaps a discussion on the goals and non-goal would help. If it is a goal to reuse the dmarc-reporting mechanism to report also about perceived spam probability, then it can be discussed in more details how this can be achieved. My experience is, that asking a provider, why an obviously non-spam mail was evaluated as spam, virtually never leads to a useful answer. So nobody wants to reveal how its spam system weigths factors and if there is lack of such interest, extending the report format will not help, as nobody will be willing the report the data. Exchanging information on hard-coded rules in Spam-Assassing (IP reputation, HTML mime part without text/plain, the “Nigeria money” phrase), that is not based on filter training, does not help neither, as sender can run the tests on its own and predict how the recipient will evaluate these set of criteria. Regards Дилян On Thu, 2019-10-24 at 19:53 +0200, Alessandro Vesely wrote: > Hi all, > > it is difficult to tell what is each aggregate report's record. It is easier > if the source IP is known. Mailing lists can be told by their (unaligned) SPF > domain. Otherwise, it is difficult to tell abuse from legitimate users using > the wrong server. > > Getting a failure report for each source IP is not easy, because few mailbox > providers send failure reports. > > In order to ease the understanding of aggregate reports, I propose two > additional per-record fields: > > > *score*: The average score of the messages in the row; let's say an SA-like > number (< 0 good, > 10 bad, values in between may be worth human inspection). > > *list*: An enumerated type, for example "none", "black", "white", "both", > indicating if the source IP is listed in some public or private DNSxL that the > reporting MTA uses. > > > They're obviously subjective stuff. However, most MTAs deploy at least one of > them, and summing up per-IP results every day can bring useful indications. > > I haven't added those fields to http://bit.ly/dmarc-rpt-schema, yet. Let's > discuss. I hope they will make it to rfc7489bis. > > > Best > Ale ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Purposes of aggregate and per message failure Reports
Hello, the purposes of the reports shall be first articulated and then the content of the reports shall be augmented to fulfil the purposes. * * * Purpose of Aggregate Reports * * * Some purposes are clarified in the email from Michael Hammer/2019-07-31: “ Having both passes and failures is incredibly useful. The percentage of failures is very useful. Any set of mail streams will always have some failures. Once you know what the baseline rate for a (sub)domain is, simply seeing changes in that rate will help you identify problems.. An increase in the failure rate is generally either 1) someone trying to abuse your domain name; or 2) something has gone wrong with DKIM signing or someone associated with the domain organization has started sending mail from somewhere without appropriate SPF or DKIM.” -- The email from Tomki/2019-06-21: “ As mentioned by Elizabeth recently: (Elizabeth please chime in if this doesn't capture your meaning) The spec does not define *which* DKIM signature should be reported in the DMARC RUA created by a receiver. The proposed resolution to this is that if the receiver does not provide the complete set of DKIM signatures found, they should provide (in order of preference) 1. a signature which passed DKIM in strict alignment with the From: header domain 2. a signature which passed DKIM in relaxed alignment with the From: header domain 3. some other signature that passed DKIM 4. some other signature that didn't pass DKIM” Once the RSA-SHA256 signatures between two sites function properly, the aggregate reports do not allow to verify, that the ED25519 signatures also work correctly. Thus two sites exchanging emails cannot know, if switching to only ED25519 signatures will work reliably. With this in mind, a new purpose of the aggregate reports is to allow for two sites, having proper RSA-SHA256 implementations, to verify, whether the ED25519 implementations are also correct. -- For what purpose the envelope sender is communicated? My understanding of recent communications is, that this information is exchenged, I do not reread the specification now. * * * Purpose of Per Message Failure Reports (also known as forensic report) My understanding for the purpose of the failure reports is, that these can serve only one of two purposes: * Either verify whether the DMARC/DKIM implementations of sender or receiver match, * Or spread information about scammer actions (The concerns for not sending failure reports for privacy reasons are only for the second case. The concerns about not sending reports in the first case is about silencing improper DMARC implementations). The case, where the implentations match, but the sender forgets to sign messages from its servers, is uncovered by the aggregate reports, and for fixing this case, the aggregate reports provide sufficient information. Regards Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] New proposed wording for p=quarantiine
Hello, to the idea to amend the existing definition of p=: quarantine: The Domain Owner wishes to have email that fails the DMARC mechanism check be treated by Mail Receivers as suspicious. Depending on the capabilities of the Mail Receiver, this can mean "place into spam folder", "scrutinize with additional intensity", and/or "flag as suspicious". the text “ The Domain Owner wishes in addition, that the sender of messages failing DMARC are notified about the suspicious handling with an appropriate rejection message. Senders not willing to be notified that their message is suspicious, shall use the NOTIFY=NEVER service extension. In the past, Domain Owner could express as wish either to reject or to quarantine. Considering that from the options: only reject; only qurantine; and quarantine, while notifying the sender about the suspicious handling of the message; nobody will choose only to quarantine, the interpretation of what the Domain Owner wishes by publishing quarantine was changed to include the rejection component.” so far two voices were against. The reasoning against the amendment is that writing what the domain owner wants is just its preference, not anything binding, and the current definition is sufficient. My motivation in favour the amendment is, that currently nobody has the practice to quarantine messages and inform the sender of the special delivery status at the same time. Spelling more precisely what the domain owner wants will suggest the implementations to implement precisely that preference. With other words, the sole reason why a receiving host does not notify the sender for quarintined message might be, that the receiving site has not come to this idea. The additional text removes the cause. If there was a common practice by now to deliver as junk and reject with appropriate text at SMTP level, then the amendment would have been less necessary. Regards Дилян On Wed, 2019-08-07 at 08:13 -0700, Murray S. Kucherawy wrote: > On Sat, Aug 3, 2019 at 12:02 AM Scott Kitterman wrote: > > Policy is an indication of sender preference, not a directive the receiver > > must follow. I think the definition is fine. If the sender prefers > > failing messages be quarantined, then they should use that policy. They > > won't get what they want in all cases and that's fine. > > This matches my understanding. > > -MSK > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Concerns for not Sending a Failure Report?
Hello Alessandro, what is the purpose of the failure reports? If the purpose is align DKIM, SPF and DNS implementations of senders and receivers, then I am proposing ways to exchange information for debugging. I do not propose how to obtain information about scammers’ actions. DMARC is invented to make the workflow of scammers impossible, it is not about exchanging information of performed scammers’ action. If a site promises to its users, that all emails will be encrypted, then publishing a ruf= address likely violates that promise. This is not necessary true, if the failure report is delivered (encrypted) only to the person who sent the original message. This creates a big fuzz, whether forwarding always the failure reports to the sender of the original message is a good idea and goes out of scope. I changed my mind: The DKIM—Signature has a tag r=y. It is a matter of adding a new value r=a, that means both: • The writer of the message, or a site which has received the message at some moment, is willing that a failure report for failed DKIM validation is sent, for every present DKIM-Signature that aligns to DMARC. The one who adds r=a can have a copy of the message. • Receiving sites can assume, that whoever adds r=a has a already a copy of the message and sending failure report with the content of the email does not reveal information to the recepient of the report about the content of the email. Now, if nearly all mails from a domailn, that pass DMARC have r=a and emails that fail DMARC from the domain, have no r=a, then the lack of r=a on its own, makes the mail suspicious. Will scammers start inserting r=a? Will be there a doubt, when both r=a and ruf= are present, that both the writer of the message and the domain owner are willing to receive failure reports and neither of them has concerns, when the reports are sent? Regards Дилян On Sun, 2019-08-04 at 12:56 +0200, Alessandro Vesely wrote: > Hi Dilyan, > > On Sun 04/Aug/2019 12:10:51 +0200 Дилян Палаузов wrote: > > > The receiving server knows, which IP address sent the mail and it knows, to > > which IP addresses set the failure report will go. If there is a match in > > the IP addresses, then the receiving server knows that the one who will get > > the report is also the one, who has anyway access to the message. > > That's not always true. For example, I know of mailbox providers who, on > delivery, automatically encrypt cleartext messages to the public key of the > recipients, including the Sent folder. Operators at that provider's aren't > able to sniff message contents unless they're sent back on failure by > receiving > sites. In general, users trust their mailbox providers also because of the > policies they enact. Matching those policies with unwarranted disclosure of > messages is not straightforward. > > In addition, the most interesting reports are messages not coming from my IP. > Scammers abusing may domain name use their own IPs. I see those failures in > the aggregate reports, but don't know if the IPs mentioned there correspond to > mailing lists or other legitimate forwarders, or even some ill-informed users > of mine who send their mail through their ISPs. That's why I need failure > reports. It would be enough if the aggregate reports contained an indication > of the spamminess of those messages, or the reputation of those IPs. > > Failure reports for messages originating from my IP are only useful for > debugging. An activity which I can more easily do by using free mailboxes, as > you said, or sites specifically dedicated to testing email. > > > Best > Ale ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Concerns for not Sending a Failure Report?
On Sun, 2019-08-04 at 10:10 +, Дилян Палаузов wrote: > > The mailbox provider has no way of knowing that you sent the mail. If it > > was authenticated as coming from you this > wouldn't be an issue. > > The receiving server knows, which IP address sent the mail and it knows, to > which IP addresses set the failure report > will go. If there is a match in the IP addresses, then the receiving server > knows that the one who will get the report > is also the one, who has anyway access to the message. Nope. This does not work for redirected messages. The assumption is that no host (sending spam) is going to forge headers in order to entitle another host to receive failure reports. A mail receiving host can obtain the IP addresses that receive emails for a domain (@a.int). If a message, failing DMARC validation, is either sent from an IP address that receives emails for a domain (MX a.int), or has such an address in its Received: headers, then the receiving site shall not have concerns that the one who would receive the failure report would have anyway access to the message in question. If the above validation of the IP address fails, but the DKIM-Signature contains "ruf=y", this means, that the receiving site can assume, that the writer of the message is willing that a failure report is sent for the message and the receiving site shall not have concern about sending reports. As with the b= tag, when calculating or verifying the signature, the value of the "ruf=" tag (signature value) of that DKIM-Signature header field MUST be treated as though it were an empty string. Or NOT? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ESC for Failed DMARC Validation
Hello Alessandro, if a site wants to emit X.7.30, it will find a way to do so (sometimes or always). I prefer an ESC over an SMTP service extension, since I consider ESCs as much easier to implement and otherwise both options are the same. Regards Дилян On Sat, 2019-08-03 at 18:27 +0200, Alessandro Vesely wrote: > Hi, > > On Fri 02/Aug/2019 23:27:48 +0200 Дилян Палаузов wrote: > > these are already now two ESC: 2.7.30 and 5.7.30. X.7.30 means in both > > cases, that DMARC validation failed. > > > > For a domain with policy p=reject; pct=0 the mail is delivered (250 > > 2.7.30), despite failed DMARCр and for a domain with > > p=reject; pct=100 when DMARC failed and the mail is rejected (550 5.7.30). > > A message can be rejected as soon as a reason to do so it is found. That > principle uniquely defines the reject response. The accept response cannot > collect what every filter thought about the message. To act as you propose, > the DMARC filter should be granted the special privilege to set the text of > the > response in any case. > > On Courier-MTA there's no API to support that. Do Postfix or Sendmail provide > one? I doubt, since SMTP doesn't attach a special significance to the text of > the response, except for the 220, 221, 251, 421, and 551 reply codes. > > > Best > Ale ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Concerns for not Sending a Failure Report?
Hello Steve, do you mean, that a mailhost sending emails for a particular domain, protected by restrictive DMARC policy, has no authority to decide, that persons appointed by the mailhost provider can read any email and any report? I mean, a domain @A.int publishes “p=reject; ruf=z...@a.int” and sends all emails over host mail.a.int . The provider gives access to all (sent) emails to person Z. Does publishing ruf=z...@a.int, by the domain owner mean, that the domain owner is capable to ensure that the persons who receive the failure reports and the persons who can read all sent mails from @a.int are the same persons? Or it means, that the domain owner is not capable to make such decision? Z is capable to sent a copy of all outgoing mails indended for a particular provider to a dedicated mailbox at that provider, fetch then the emails from the dedicated mailbox and filter the ones with Authentication-Result: dmarc=fail . > The mailbox provider has no way of knowing that you sent the mail. If it was > authenticated as coming from you this wouldn't be an issue. The receiving server knows, which IP address sent the mail and it knows, to which IP addresses set the failure report will go. If there is a match in the IP addresses, then the receiving server knows that the one who will get the report is also the one, who has anyway access to the message. I think now, that not sending failure reports has nothing to do with (privacy) concerns. It is either laziness of the receiving site to make the appropriate setup, or unwillingness to reveal information about mismatching DKIM implementation of sender and receiver. With willingness to align the implementations, a receiving site having (privacy) concerns, can offer a mailbox to the sending site, where the sending mailhost duplicates each email from the sending to the receiving host. Then the sending host can fetch the mails and look for A-R: dmarc=fail. That said I would like to see some text in the revisited DMARC specification about obtaining information about messages failing DMARC, sent from a particular mailhost to another mailhost, when the receiving site does not send failure reporst (for any reason), but is otherwise willing to exchange information about messages, failing DMARC validation. Regards Дилян On Sun, 2019-08-04 at 10:35 +0100, Steve Atkins wrote: > > On Aug 4, 2019, at 9:18 AM, Дилян Палаузов > > wrote: > > > > Hello Steve, > > > > in both cases it is about information that was sent over from the same > > mailhost. > > The mailbox provider has no way of knowing that you sent the mail. If it was > authenticated as coming from you this wouldn't be an issue. > > One mail was sent to *you*. It's OK for you to have access to it. > > The other mail was sent to someone *not you*. There's no a priori reason you > should have access to the content of the message. > > Cheers, > Steve > > > > To whom the information was sent > > decides the operator of the mailhost, not the one who suppresses failure > > reports. > > > > In any case, for a failure report containing only the Message-Id it does > > not matter what information the email carried > > and to whom the information was sent. > > > > Regards > > Дилян > > > > On Sun, 2019-08-04 at 09:07 +0100, Steve Atkins wrote: > > > > On Aug 2, 2019, at 10:41 PM, Дилян Палаузов > > > > wrote: > > > > > > > > Hello, > > > > > > > > I just thougth once again on this. > > > > > > > > Some of the senders of aggregate reports offer free mailboxes. > > > > > > > > Aggregate reports show that emails from a host to a provider of free > > > > mailboxes sometimes do not validate DMARC. > > > > > > > > The one provider sending emails opens a free mailbox on the receiver > > > > and then sends a secret copy of each, otherwise > > > > ordinary delivered email, to that special mailbox. > > > > > > > > Then the mails from that mailbox are downloaded, and the A-R header is > > > > checked. By this way the sender finds out, which > > > > messages exactly have failed DMARC validation. > > > > > > > > At the end the same information is obtained, that can be obtained by > > > > exchanging a failure report: which messages have > > > > failed. > > > > > > Information found in mail mail headers in accounts that you have created > > > includes email that's been sent to you. > > > > > > Information found in failure reports includes email that generally was > > > not sent to you. > > > > > > Cheers, > > > Steve > > > ___ > > > dmarc mailing list > > > dmarc@ietf.org > > > https://www.ietf.org/mailman/listinfo/dmarc > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Concerns for not Sending a Failure Report?
Hello Steve, in both cases it is about information that was sent over from the same mailhost. To whom the information was sent decides the operator of the mailhost, not the one who suppresses failure reports. In any case, for a failure report containing only the Message-Id it does not matter what information the email carried and to whom the information was sent. Regards Дилян On Sun, 2019-08-04 at 09:07 +0100, Steve Atkins wrote: > > On Aug 2, 2019, at 10:41 PM, Дилян Палаузов > > wrote: > > > > Hello, > > > > I just thougth once again on this. > > > > Some of the senders of aggregate reports offer free mailboxes. > > > > Aggregate reports show that emails from a host to a provider of free > > mailboxes sometimes do not validate DMARC. > > > > The one provider sending emails opens a free mailbox on the receiver and > > then sends a secret copy of each, otherwise > > ordinary delivered email, to that special mailbox. > > > > Then the mails from that mailbox are downloaded, and the A-R header is > > checked. By this way the sender finds out, which > > messages exactly have failed DMARC validation. > > > > At the end the same information is obtained, that can be obtained by > > exchanging a failure report: which messages have > > failed. > > Information found in mail mail headers in accounts that you have created > includes email that's been sent to you. > > Information found in failure reports includes email that generally was not > sent to you. > > Cheers, > Steve > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] New proposed wording for p=quarantiine
Hello John, I am really saying, that some addresses, like majordomo@ , which send answer to each received and accepted message, have no capability to perform a form of “quarantine”. It does not matter, whether this is an edge case. Once it is clarified how to act in this case, the same procedure can be applied to mailboxes, where users want to have no Spam folder. So mailboxes, which capability to quarantine messages is disabled and for users, who do not want to receive messages with SUSPICIOUS in the subject line or have any corresponding headers. Or for users who statistically never open their Spam folder. So it is a matter of clarifying what the domain owner wishes by publishing p=quarantine to happen to messages failing DMARC validation, when the receiving address, voluntary or not voluntary, does not offer quarantining capability. I have no problem, if the text "... reject at SMTP level" is not attached to the quarantine definition, but is implied by reading other passages. Then it does not make a difference. Regards Дилян On Fri, 2019-08-02 at 23:05 -0400, John Levine wrote: > In article <97b7d4320e77f9be84703677eba79686ec769f75.ca...@aegee.org> you > write: > > Hello John, > > > > the "... reject at SMTP level" is at least for messages, directed to an > > address, which does not support the > > concept of > > quarantining. > > > > Please propose what shall a site do, receiving a message, subject to > > quarantining, for an address, that does > > not support quarantining. > > It should do what RFC 7489 says: > > ... Depending on the capabilities of the Mail > Receiver, this can mean "place into spam folder", "scrutinize > with additional intensity", and/or "flag as suspicious". > > Are you really saying your mail system has no spam folders, no way to > adjust spam filtering, and no way to mark messages as suspicious > (e.g., add "PROBABLY SPAM" to the subject line)? > > If the problem is that it's an address that goes to some software > robot rather than being seen by people, do whatever you want. That's > an edge case for DMARC. > > R's, > John > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] New proposed wording for p=quarantiine
Hello John, the "... reject at SMTP level" is at least for messages, directed to an address, which does not support the concept of quarantining. Please propose what shall a site do, receiving a message, subject to quarantining, for an address, that does not support quarantining. Regards Dilyan On Fri, 2019-08-02 at 18:49 -0400, John Levine wrote: > In article you > write: > > Current wording for p=quarantine > > quarantine: The Domain Owner wishes to have email that fails the > > DMARC mechanism check be treated by Mail Receivers as > > suspicious. Depending on the capabilities of the Mail > > Receiver, this can mean "place into spam folder", "scrutinize > > with additional intensity", and/or "flag as suspicious". > > > > Amendment to the wording for p=quarantine: > > > > … or reject at SMTP level. ... > > No. We really, really, don't like changes that aren't backward > compatible. You can do what you want but there is no chance I would > ever make p=quarantine a signal to reject, and I think I am not > atypical. > > R's, > John > > PS: You can of course do whatever you want on your own system. > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] New proposed wording for p=quarantiine
Current wording for p=quarantine quarantine: The Domain Owner wishes to have email that fails the DMARC mechanism check be treated by Mail Receivers as suspicious. Depending on the capabilities of the Mail Receiver, this can mean "place into spam folder", "scrutinize with additional intensity", and/or "flag as suspicious". Amendment to the wording for p=quarantine: … or reject at SMTP level. The Domain Owner wishes in addition, that the sender of messages failing DMARC are notified about the suspicious handling with an appropriate rejection message. Senders not willing to be notified that their message is suspicious, shall use the NOTIFY=NEVER service extension. In the past, Domain Owner could express as wish either to reject or to quarantine. Considering that from the options: only reject; only qurantine; and quarantine, while notifying the sender about the suspicious handling of the message; nobody will choose only to quarantine, the interpretation of what the Domain Owner wishes by publishing quarantine was changed to include the rejection component. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Concerns for not Sending a Failure Report?
Hello, I just thougth once again on this. Some of the senders of aggregate reports offer free mailboxes. Aggregate reports show that emails from a host to a provider of free mailboxes sometimes do not validate DMARC. The one provider sending emails opens a free mailbox on the receiver and then sends a secret copy of each, otherwise ordinary delivered email, to that special mailbox. Then the mails from that mailbox are downloaded, and the A-R header is checked. By this way the sender finds out, which messages exactly have failed DMARC validation. At the end the same information is obtained, that can be obtained by exchanging a failure report: which messages have failed. Has somebody done this? Why does it have to be that complicated? Regards Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ESC for Failed DMARC Validation
Hello, these are already now two ESC: 2.7.30 and 5.7.30. X.7.30 means in both cases, that DMARC validation failed. For a domain with policy p=reject; pct=0 the mail is delivered (250 2.7.30), despite failed DMARCр and for a domain with p=reject; pct=100 when DMARC failed and the mail is rejected (550 5.7.30). Please propose a different wording, I do not see a contradiction in my wording. Who will use it? I asked, why failure reports are not sent by some sites, and would the ones, who do not send failure reports, use the X.7.30 code. (Thus, if for failure reports there are concerns, while for ESC X.7.30 there are no concerns). I expect that at least parties who want to fix their DMARC/DKIM implementation will use it. The aggregate reports provide hints, that the DKIM implementation does not work. This ESC is not meant as a shortcut to collecting a lot of reports and analyzing them, it is a mean to act when no reports are sent. Regards Дилян On Fri, 2019-08-02 at 23:06 +0200, Rolf E. Sonneveld wrote: > On 02-08-19 22:54, Murray S. Kucherawy wrote: > > The wording you're using seems inconsistent to me.. Specifically, > > you're saying that x.7.30 means one thing when attached to a > > 200-series reply, but the opposite when attached to a 500-series > > reply. I would prefer to see two separate codes if you're going to do > > this. > > > > But the bigger question is implementation. Who would make use of > > this, either as a sender or a receiver? > > a receiver could assist a sender in adjusting its egress mail process > without the need for the receiver to collect a lot of DMARC reports and > analyse them. A sender could use it to improve its outbound mailflow. I > doubt however whether anyone will implement this as it assists possible > adversaries as well... > > /rolf > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ESC for Failed DMARC Validation
Hello Murray, ESC X.7.20, X.7.21 and X.7.22 are glued to return code 550, while I propose an ESC, that works also with 250. Apart from this, X.7.20 and X.7.21 cannot be used instead of the proposed X.7.30: If a site sees a valid DKIM signature, and previous experience with the domain signing DKIM leads to increased trust in this domain, then the signature is acceptable, but it does not have to align with the From: address. With X.7.22: Description:This status code is returned when a message contains one or more passing DKIM signatures, but none are acceptable because none have an identifier(s) that matches the author address(es) found in the From header field. This is a special case of X.7.21. (This violates the advice of Section 6.1 of RFC 6376.) If “none have an identifier that matches the author address found in the From header field” means, that the DKIM part of DMARC fails, then this ESC can be recommended by the DMARC specification to signal to the sender, that the DKIM implementations of sender and receiver disagree, as a light substitute to the failure reports. Greetings Дилян On Fri, 2019-08-02 at 13:01 -0700, Murray S. Kucherawy wrote: > On Fri, Aug 2, 2019 at 10:52 AM Дилян Палаузов > wrote: > > I mean an enhanced status code, as at > > https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml > > . > > RFC7372 registered some for exactly this purpose (though not specific to > DMARC). Its Security Considerations section talks about the privacy risks. > > I don't know if they're actually in use. > > -MSK > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ESC for Failed DMARC Validation
Hello Alessandro, I mean an enhanced status code, as at https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml . Would you reply to messages failing DMARC with such a code, irrespective of whether the message was accepted or rejected? Are there privacy risks connected with such ESC? Regards Дилян On Fri, 2019-08-02 at 19:18 +0200, Alessandro Vesely wrote: > Hi Dilyan, > > > I'm not clear if you refer to the "DSN" extension (rfc3461). In fact, > positive > DSNs contain the A-R header field, and so can inform the sender when a message > is accepted although some of SPF/ DKIM/ DMARC failed. > > I don't send failure reports, as they look plenty of privacy risks. Perhaps > they could be sent to trusted sites only, but that way they'd lose generality. > > It's unfortunate that FR seem to be the only means to tell unwanted failures > from real spam/ phishing successfully blocked by the protocol. Perhaps that > distinction could be added to aggregate reports, even if it's not an exact > science. > > > Best > Ale > > > On Fri 02/Aug/2019 18:00:11 +0200 Дилян Палаузов wrote: > > why sites do not sent failure reports? > > > > Will a site, not sending failure report, be willing to use an Enhanced > > Status Code, to signal, that the DKIM/SPF > > implementations of the receiver and sender disagree? > > > > * * * New Enhanced Status Code for Failed DMARC Validation > > > > Code: X.7.30 > > Assocaited basic status code: Any > > Description: Used as partial substitution to failure reports, when DMARC > > validation fails. 250 2.7.30 means, that the > > message was delivered, ordinary or as junk, despite failed DMARC > > validation. 550 5.7.30 is used when the message is > > rejected, because the DMARC validation failed. This status code is only > > usefull, when the receiving site does not send > > failure reports. > > > > Regards > > Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARC and Redirecting Messages
Hello, current text in https://tools.ietf.org/html/rfc7489#section-6 (DMARC Policy): Since email streams can be complicated (due to forwarding, existing RFC5322.From domain-spoofing services, etc.), Mail Receivers MAY deviate from a Domain Owner's published policy during message processing [... and SHOULD make available the fact of and reason for the deviation to the Domain Owner via feedback reporting, specifically using the "PolicyOverride" feature of the aggregate report (see Section 7.2).] I propose this amendment to the first part of the sentance, (writen in a more abstract way, where the receiving site decides on the policy. The wording is subject to further adjustments): * * * DMARC and Redirecting Messages For a site, that is supposed to redirect a message with failed DMARC validation, to another site, if the PCT with the policy is 100 the recommendation is not to redirect the message but reject it at SMTP level. The rationale is, that this message might be evaluated by the next hop site as Spam, while this hop does not consider the message as spam. In turn, the next hop can conclude, that this hop is sending spam. If the next hop decides to apply DMARC policy reject for the domain of the message, this hop will have to generate a bounce for the message, risking to be blacklisted by some backscatters IP reputation lists. For a site, that is supposed to redirect a message with failed DMARC validation, to another site, if the PCT with the policy is between 1 and 99, the recommendation is to reject the message at SMTP level and not forward it further. For redirected messages, the PCT sampling is applied at least twice, thus there is a probabily that the next hop rejects the message based on the PCT parameter, even if this hop has calculated not to reject the message. It is in unknown, whether the next hop will reject or quarantine messages failing DMARC validation and from the sender's perspective there is no difference, whether this hop or the next hop will reject the message. The recommendations above do not fully apply, when the current hop changes the From: address, as if the recipient on the next hop were a mailing list with one recipient, doing From: mungling. It is not recommended to tell the sender that the message was delivered in the Junk folder of the recipient, and to forward the message further, as the sender can get two rejections for the same message, from two different hops, which is confusing. This can happen, even if the From: address is mungled. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] ESC for Failed DMARC Validation
Hello, why sites do not sent failure reports? Will a site, not sending failure report, be willing to use an Enhanced Status Code, to signal, that the DKIM/SPF implementations of the receiver and sender disagree? * * * New Enhanced Status Code for Failed DMARC Validation Code: X.7.30 Assocaited basic status code: Any Description: Used as partial substitution to failure reports, when DMARC validation fails. 250 2.7.30 means, that the message was delivered, ordinary or as junk, despite failed DMARC validation. 550 5.7.30 is used when the message is rejected, because the DMARC validation failed. This status code is only usefull, when the receiving site does not send failure reports. Regards Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Abolishing DMARC policy quarantine
Hello Hector, you state, that a domain owner can request p=quarantine over p=reject because of concers of false positives. Why shall one have concers about false positives, but will not be willing to fix them? I do repeat myself, but the way to fix the false positives is to introduce p=reject, see which emails fail and are returned and then fix the DKIM implementation for that messages. That said, if you have concerns of false positives and want to get rid of them, the way to go is do p=reject. If there are concerns about false positives, but nobody wants to fix them, you end having an unreliable system. Besides, I do not see when a false positive happens, due DKIM stuff not running correctly, whose problem is this: • Of the sending domain owner, • Of the user sending the mail (the only one who has nothing to say, except switching the provider), • Of the site receiving the mail, • Of the user receiving the mail? Among several valid answers, a correct one is, that this is a problem of the one who has wrong DKIM implementation and this is either the sending or the receiving site. Since the problem is not of the sender, the sender shall have no say. Note, that quarintining a message for a user, that never checks her spam folder, is equivalent to discarding the message and for such users the choise is in practice reject or discard. On Thu, 2019-08-01 at 09:48 -0400, Hector Santos wrote: > On 7/31/2019 11:32 PM, Murray S. Kucherawy wrote: > > How the receiver implements mail filters SHOULD always remain as local > policy. > > [...] > > If we take quarantine out, there is still going to be receivers who will > perform a quarantine concept regardless of a hard reject policy. > This is not exactly what I’m proposing with abolishing policy quarantine. I propose, that there are only two policies that can be annouced by the domain owner: • “none”, meaning that not all mails have DKIM-Signature that alings to From: to that domain • “not none”, meaning that the domain owner announces, that all messages From: that (sub)domain are supposed to have valid, aligned DKIM-Signatures. For pragmatical reasons, the name for “not none” will be “reject”. Moreover, I propose, that when the policy is “not none”, the recipient decides how to punish messages, that fail DMARC validation and the specification elaborates the possibilitis. So, with “not none” policy, some recipients will do hard reject and others not. Just like sites which have not deployedd DMARC. In any case, if the consens is to keep policy quarantine, and the specification states, that implementations can allow receiving sites to override the policy to reject (or to quarantine) and implementations can allow individual users to override the policy (to reject or to quarantine), recommending what to do with messages that go simultaneously to users which have not overridden the policy and to users which have overriden the sender policy, then I am fine. Regards Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] if policy quarantine will be kept
Hello, yes, it requires different receivers to know each other capabilities. Here a new proposed wording, if policy quarantine will be kept: Messages, subject to the quarantine policy, directed to a single recipient that does not support the concept of quarantining, can be either accepted and delivered, accepted and discarded, accepted and bounced, or rejected at SMTP level. Messages, subject to the quarantine policy, directed to many recipients, some of which support the concept of quarantining, and the others not supporting this concept, can be either: * accepted, quarantined for the first group of recipients and discarded for the other recipients, * accepted, quarantined for the first group of recipients and delivered to the other recipients, * accepted, quarantined for the first group of recipients and bounced for the other recipients, * segmented, * rejected as whole, or * quarantined for the first group of recipients, discarded for the other recipients, and at the same time rejecting the message at SMTP level, spelling in the reply to which recipients the message was delivered and to which not. An example for a reply line for the last case is: 550-5.7.1 The mail was delivered in the Junk folder for us...@example.org and 550 us...@example.org. The mail was not delivered to us...@example.org. Discarding and bouncing are to be avoided. Accepting and delivering the message ignores completely the DMARC policy. Segmentation imposes delivery delays. This specification recommends in both cases overriding the policy and rejecting the message at SMTP level. For a message, subject to the quarantine policy, if the receiving server does not know whether a recipient supports the concept of quarantining, the recommendation is to override the policy and reject the message. [...] In the absense of failure reports, rejecting messages with failed DMARC validation allows the sender to determine for which messages the validation failed. When messages with failed DMARC validation are quarantined, the sender cannot find out for which messages the validation failed. I propose this text irrespective of whether policy quarantine will be kept: When the DMARC validation fails, the enacted actions are up to the receiving site. It can simultaneoulsy quarantine the message and reject it at SMTP level, spelling in the rejection reason that the message was delivered in the Junk folder. Regards Дилян On Wed, 2019-07-31 at 20:34 -0700, Murray S. Kucherawy wrote: > On Tue, Jul 30, 2019 at 7:29 AM Дилян Палаузов > wrote: > > if policy quarantine will be kept, I propose including this text in the > > specification: > > > > Messages, subject to the quarantine policy, directed to a single recipient > > that does not support the concept of > > quarantining, can be either accepted and delivered, accepted and discarded, > > or rejected. > > > > Messages, subject to the quarantine policy, directed to many recipients, > > some of which support the concept of > > quarantining, and the others not supporting this concept, can be either: > > * accepted, quarantined for the first group of recipients and discarded for > > the other recipients, > > * accepted, quarantined for the first group of recipients and delivered to > > the other recipients, > > * segmented or > > * rejected as whole > > Doesn't this, as proposed, require different receivers to know each other's > capabilities? > > -MSK > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Aggregate reporting options tag name 'ao'
Hello Fredie, DMARC limits the amount of servers that can generate emails for a particular domain. The aggregate reports show to which extend DMARC does work correctly and when it fails for a domain. The aggregate reports to not tell you how to fix your DKIM implementation, so that sender and receiver agree on the DKIM signature. The per message failure reports tell you which messages were not signed correctly, so that you can check the DKIM implementation. I thought some hours ago it could be useful to reduce the amount of reports, by not sending a report when things are 100% correct, but now I am not so sure. The aggregate reports contain information, if something is not working correctly, but they also prove, if everything is running correctly. If there is an option to reduce the reports to contain only information about failures, you don’t have a prove, that everything is working correctly. Let’s say if you write a message to site S and don’t get an aggregate report back, this can mean, that DMARC passed, but it can also mean, that S does not evaluate DMARC or that DMARC failed and S does not send aggregate reports. Is the lack of success-reports a prove of correctness or not? I am inclined. What do you want to do with the information about failures from the DMARC aggregate reports? Regards Дилян On Wed, 2019-07-31 at 19:31 +0200, Freddie Leeman wrote: > Hi Дилян, > > Thanks for your input and feedback. Maybe a single tag, that allows the > domain owner to avoid receiving aggregate reports for messages that align, > would be enough? I personally have little experience with mailing lists > which, I understand, can be a real pain when it comes to SPF/DKIM. So would a > tag that instructs the receiving party to only send an aggregate report > whenever the DMARC policies is applied be a better option? > > Kind regards, > Freddie > > Van: Дилян Палаузов [mailto:dilyan.palau...@aegee.org] > Verzonden: woensdag 31 juli 2019 17:29 > Aan: dmarc@ietf.org > Onderwerp: Re: [dmarc-ietf] Aggregate reporting options tag name 'ao' > > Hello Freddie, > > if a message has 5 DKIM-Signatures, some of them fail DKIM validation and > some of them do not align, irrespective of validation status, you want to > receive a report for the failed DKIM signatures. The proposed option d is in > the DKIM domain. DMARC without alignment is DKIM or SPF. To get a report for > failed DKIM signature you put in the DKIM-Signature header r=y. After the > mail passes over a mailing list, the signature is invalidated and you get a > useless report. Your intension is to limit the amount of useless reports, but > this particular option goes in the opposite direction. > > If you remove the SPF records and ensure that each leaving message is signed, > you do not need the ao=1 option, as each report on failure will be about DKIM. > > With ao=s whenever a mail is sent to an alias and redirected to another > server, you will get a useless report. I am not exactly sure, but I think SPF > contained some reporting mechanisms, so this option might duplicate them. > > Perhaps you want to propose a mechanism, that hides the successful deliveries > (useless report) and only reports problematic cases? > > Regards > Дилян > > > On July 31, 2019 5:58:18 PM GMT+03:00, Freddie Leeman > wrote: > > Would it be useful to add an ‘ao’ tag name for aggregate reporting options? > > Something like: > > > > ao: Aggregate reporting options (plain-text; OPTIONAL; default is > > "0"). > > Provides requested options for generation of aggregate reports. This tag's > > content MUST be ignored if a "rua" tag is not specified. The value of this > > tag is a colon-separated list of characters that indicate aggregate > > reporting options as follows: > > > > 0: Generate a DMARC aggregate report for every message, regardless of its > > alignment. > > 1: Generate a DMARC aggregate report if any underlying authentication > > mechanism produced something other than an aligned "pass" result. > > d: Generate a DMARC aggregate report if the message had a signature that > > failed evaluation, regardless of its alignment. > > s: Generate a DMARC aggregate report if the message failed SPF evaluation, > > regardless of its alignment. > > > > This would allow domain owners to save on tons of reports to be handled and > > processing that are useless in most scenarios. For instance, when I’ve > > deployed my SPF/DKIM/DMARC policy and I’m pleased with my policie’s > > results, I would still want to use the reporting to detect and fix changes > > in my email environment. If a million mails
Re: [dmarc-ietf] Aggregate reporting options tag name 'ao'
Hello Freddie, if a message has 5 DKIM-Signatures, some of them fail DKIM validation and some of them do not align, irrespective of validation status, you want to receive a report for the failed DKIM signatures. The proposed option d is in the DKIM domain. DMARC without alignment is DKIM or SPF. To get a report for failed DKIM signature you put in the DKIM-Signature header r=y. After the mail passes over a mailing list, the signature is invalidated and you get a useless report. Your intension is to limit the amount of useless reports, but this particular option goes in the opposite direction. If you remove the SPF records and ensure that each leaving message is signed, you do not need the ao=1 option, as each report on failure will be about DKIM. With ao=s whenever a mail is sent to an alias and redirected to another server, you will get a useless report. I am not exactly sure, but I think SPF contained some reporting mechanisms, so this option might duplicate them. Perhaps you want to propose a mechanism, that hides the successful deliveries (useless report) and only reports problematic cases? Regards Дилян On July 31, 2019 5:58:18 PM GMT+03:00, Freddie Leeman wrote: >Would it be useful to add an 'ao' tag name for aggregate reporting >options? >Something like: > > > >ao: Aggregate reporting options (plain-text; OPTIONAL; default >is >"0"). > >Provides requested options for generation of aggregate reports. This >tag's >content MUST be ignored if a "rua" tag is not specified. The value of >this >tag is a colon-separated list of characters that indicate aggregate >reporting options as follows: > > > >0: Generate a DMARC aggregate report for every message, regardless of >its >alignment. > >1: Generate a DMARC aggregate report if any underlying authentication >mechanism produced something other than an aligned "pass" result. > >d: Generate a DMARC aggregate report if the message had a signature >that >failed evaluation, regardless of its alignment. > >s: Generate a DMARC aggregate report if the message failed SPF >evaluation, >regardless of its alignment. > > > >This would allow domain owners to save on tons of reports to be handled >and >processing that are useless in most scenarios. For instance, when I've >deployed my SPF/DKIM/DMARC policy and I'm pleased with my policie's >results, >I would still want to use the reporting to detect and fix changes in my >email environment. If a million mails a day are nicely processed with >DKIM >and SPF aligned, I do not need those entries in my aggregate reports. >I'm >only interested in the reports where either DKIM or SPF fails. In most >scenario's this will cut data transfer and report processing with more >than >99 percent. Whenever there is a bump in the number of reports received, >I >can detect that something is wrong and I might need to add a host to my >SPF >policy or need to fix my DKIM signing. > > > >I was amazed that these options weren't in the current RFC, as these do >exist for failure reports. Am I missing something? Is there a reason >why >this would be a bad idea? > > > >Kind regards, > >Freddie ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] if policy quarantine will be kept
Hello, if policy quarantine will be kept, I propose including this text in the specification: Messages, subject to the quarantine policy, directed to a single recipient that does not support the concept of quarantining, can be either accepted and delivered, accepted and discarded, or rejected. Messages, subject to the quarantine policy, directed to many recipients, some of which support the concept of quarantining, and the others not supporting this concept, can be either: * accepted, quarantined for the first group of recipients and discarded for the other recipients, * accepted, quarantined for the first group of recipients and delivered to the other recipients, * segmented or * rejected as whole Discarding is to be avoided. Accepting and delivering the message ignores completely the DMARC policy. Segmentation imposes delivery delays. This specification recommends in both cases overriding the policy and rejecting the message. Regards Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields
Hello Scott, do you want to include in the A-R header the published policy, as obtained from DNS (my first interpretation of your proposal), or the disposition of the message after applying DKIM/SPF/DMARC validation, pct sampling, and the ominous reject→quarantine sampling conversions? With disposition I mean what is called at https://tools.ietf.org/html/rfc6591#section-3.2.2 Delivery-Result. For the disposition on p=reject only the MTA can make the decision based on pct to reject, so it makes sense if the result of disposition is included in the A-R header by the MTA and consumed by the MDA. In turn, including pct and published DMARC policy in the A-R header, so that the MDA can do the sampling, does not make sense. If you want to call the new parameter “policy”, then it shall be articulated that it means disposition, and not published policy. I am in favour of the proposal. It allows for forwarded emails/aliases to indicate in the A-R header, that sampling was already performed by the aliasing server, and the final server that accepts the email can skip performing the sampling again. Performing the sampling again has the disadvantage, that the pct= parameter is misinterpreted, as the parameter is supposed to be applied only once. On the other side, skipping of the second sampling by whatever server is pure theory, and has no practical impact. Greetings Дилян On Tue, 2019-07-30 at 00:54 -0400, Scott Kitterman wrote: > On Monday, July 29, 2019 3:37:55 PM EDT Scott Kitterman wrote: > > I'd like to add the option to record DMARC results in an A-R header field > > for consumption by a downstream processor. I think it would be something > > like this: > > > > Authentication-Results: mail-router.example.net; dmarc=pass > > header.from=example.com policy.dmarc=none > > > > That would take adding an entry in the Email Authentication Methods registry > > for: > > > > method: dmarc > > ptype: policy > > value: dmarc > > > > Does that make sense as a way to do it? Does anyone have alternative > > suggestions? > > I think comments should be free-form. If we want data that can be machine > parsed, we should specify it. > > I think the above works in ABNF terms. It's: > > Authentication-Results:" authserv-id; method=result ptype.property=value > ptype.property=value > > According to the ABNF, there can be more than one propspec > (ptype.property=value) per methodspec in resinfo, so I think it's legal. It > would just need the new registry values for dmarc. > > Scott K > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Reporting DMARC policy in A-R header fields
Hello Scott, You want to add the option to record the DMARC policy in the A-R header. I add it as comment: Authentication-Results: mail.example.org/x551xr2q019874; dmarc=pass (p=quarantine dis=none) header.from=example.com; spf=pass smtp.mailfrom=u...@example.com with dis being the disposition. What will a downstream processor do with the information? Regards Dilyan On Mon, 2019-07-29 at 15:37 -0400, Scott Kitterman wrote: > I'd like to add the option to record DMARC results in an A-R header field for > consumption by a downstream processor. I think it would be something like > this: > > Authentication-Results: mail-router.example.net; dmarc=pass > header.from=example.com policy.dmarc=none > > That would take adding an entry in the Email Authentication Methods registry > for: > > method: dmarc > ptype: policy > value: dmarc > > Does that make sense as a way to do it? Does anyone have alternative > suggestions? > > Scott K > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Abolishing DMARC policy quarantine
Hello Alessandro, abolishing policy quarantine means with p=reject that for failed messages there should be some penalty and the receiving site decides on the form of the penalty, e.g. quarantine or reject. In fact I see the DMARC specification updated to use consistently some neutral word, like penalty or punishment attached to p=reject, once p=quarantine is abolished. This word is then dissected into “quarantine or reject” at the place where it elaborates on the possible penalties, or how to do reject right. The penalty could be implemented with reply 550 Message failed DMARC validation and was delivered in the Junk folder of the recipient This form has the advantage over either quarantine or reject, that for lost messages, the sender can call the recipient and the recipient can dig for the message. So the message does not have to be resent and no surprizes happen. I do not see how could this reply mess anything, except in the cases where the sender does not speak English. > OTOH, quarantine lets one forget about delivery, perhaps with a backhanded > thought of recipients rummaging through their spam folders in search of a > missing message. That style seems to me to better suit ESPs, whose duty is > rather to have a lot of mails sent than to make sure that each message is > acknowledged, albeit they try and maximize the ratio. > > IMHO, by abolishing quarantine, we make the protocol less flexible than it is. If an ESP wants to forget about delivery, the ESP likely does not care whether it has implemented DMARC correctly and then it does not need quarantine mode. The penalty is applied to messages that are either sent by spammers or by the domain owner. If messages are from spammers, for the domain owner it is irrelevant, what kind of penalty is applied, but for users doing reject means having to scan less messages in the Junk mailbox. If messages are from the domain owner and fail DKIM/DMARC validation, the only way to fix DKIM/DMARC is to use policy reject. There is no other way to find out which messages fail DKIM/DMARC, as single message faiulure reports are rarely sent, and without knowing which messages fail DMARC fixing the problem is unnecessary complicated. So here, p=quarantine is in fact an option for providers, who do not care, whether they have implemented DMARC correctly. All that said: • Is there a consensus on abolishing policy quarantine? • If policy quarantine will be kept, will the none>quarantine>reject order be abolished, meaning “quarantine” will not be handled as softer variant of “reject”? Meaning with p=reject; pct=30 messages are either delivered or rejected, but the specification does state anything about quaratining 70% of the failed messages. The first argument in favour of keeping policy quarantine was exactly this order (quarantine is a softer variant of reject and before deploying reject one has to exercise with quarantine). Regards Дилян On Fri, 2019-07-26 at 16:30 +0200, Alessandro Vesely wrote: > On Thu 25/Jul/2019 14:53:55 +0200 Steve Atkins wrote: > > > On Jul 25, 2019, at 12:06 AM, Murray S. Kucherawy > > > wrote: > > > > > > On Wed, Jul 24, 2019 at 4:45 PM Steve Atkins > > > wrote: > > > > It's interesting that the industry has decided to interpret "p=reject; > > > > pct=0" the way we intended "p=quarantine; pct=100". > > > > > > It's semi-explicitly defined that way in the RFC, isn't it? > > > > > > If so, we should fix it because (a) I don't think that's how we intended > > > it, and (b) in any case, nothing in there should be only semi-explicit. > > > > rfc 7489 6.6.4 > > > > "If email is subject to the DMARC policy of "reject", the Mail > >Receiver SHOULD reject the message (see Section 10.3). If the email > >is not subject to the "reject" policy (due to the "pct" tag), the > >Mail Receiver SHOULD treat the email as though the "quarantine" > >policy applies. This behavior allows Domain Owners to experiment > >with progressively stronger policies without relaxing existing > >policy." > > > > It's pretty clear and well-defined; the case we're talking about, > > "p=reject; pct=0", is > > just a special case of this general rule. > > > > All emails will not be subject to the "reject" policy due to the pct=0 tag, > > so the mail > > receiver should treat all emails as though the policy "quarantine" applies > > (which > > is the same as "p=quarantine; pct=100"). > > I, for one, had missed that point. Thanks for clarifying it. > > It seems to mean that the resulting steps are, for example: > > > "p=quarantine; pct=0" (check From: rewriting) > "p=quarantine; pct=10" (some messages go to the spam folder) > "p=quarantine; pct=20" > > "p=quarantine; pct=100" > "p=reject; pct=0" (same as the previous step) > "p=reject; pct=10" (some messages bounce back) > "p=reject; pct=20" > > > > Is that what we want to suggest? In that case, we should be clearer. Perhaps >
Re: [dmarc-ietf] Abolishing DMARC policy quarantine
Hello, (I repeat what was said here, just in case) As it was pointed out, p=quarantine; pct=0; is the same as p=none; and p=reject; ptc=0; is the same as p=quarantine; pct=100, therefore p=quarantine; pct=0 is not the same as p=reject; pct=0 currently, per https://tools.ietf.org/html/rfc7489#section-6.6.4 (RFC DMARC, Section Message Sampling) And then, for p=none or any equivalent form of it, there is no need or established practice for mungling, while for p=reject; pct=0, or any equivalent form of it, there is mungling. This is the current specification. I proposed on this regard in fact two things: - specifying that p=quarantine; pct=0 (email from 10th May to dmarc@ietf) the MLM does mungling - abolishing policy quarantine That is: p=reject; pct=0 gets almost the same as p=none, except that there is recommendatiton for MLM to mungle From:. Regards Дилян On Wed, 2019-07-24 at 19:36 +0300, Vladimir Dubrovin wrote: > > Hello Murray, > > Yes, rewriting depends on policy. Look at From: headers for this mailing list > (dmarc@ietf.org), you can see it only munges From address for domain with > strict DMARC policy (if RFC5322.From domain publishes "quarantine" or > "reject" policy). This is very common behavior, it can also be seen in Google > Groups. > > But, as it was correctly pointed by Dilyan Palauzov, there should be no > difference between "p=quarantine;pct=0" and "p=reject;pct=0" for valid DMARC > Mail Receiver implementation, so "p=reject;pct=0" can probably be used > instead. > > 24.07.2019 18:27, Murray S. Kucherawy пишет: > > On Fri, Jun 14, 2019 at 12:25 PM Vladimir Dubrovin > > wrote: > > > Nope, I mean 2 different things. > > > > > > 1. Why quarantine is useful (with pct=0). > > > > > > For example this mailing list (dmarc@ietf.org) performs >From rewrite > > > (aka From munging), e.g. dubro...@corp.mail.ru is replaced with > > > dubrovin=40corp.mail...@dmarc.ietf.org. It's because > > > corp.mail.ru has a strict DMARC policy (reject). dotz...@gmail.com is not > > > overwritten, because gmail.com has p=none and ietf.org only overwrites > > > From only for domains with "quarantine" and "reject" policies. It's quite > > > common behavior. > > > > > > If you are implementing DMARC for a new domain (let's say example.org), > > > you usually start with "p=none". With p=none you receive reports for > > > failed DMARC for different lists, like ietf.org. Before switching to > > > stronger policy (p=reject), you may want to know which mailing list will > > > still fail DMARC, and which lists perform From munging and, as a result, > > > do not fail DMARC. For this purpose, before switching to "p=reject" it's > > > useful to switch to "p=quarantine;pct=0". After this, you will only see > > > mailing lists without From munging in DMARC reports. > > > > > > > I'm confused; is this claiming that those rewrites happen by virtue of the > > fact that "p=quarantine" is the published policy? Seems to me that > > rewriting will happen irrespective of what the published policy is for the > > From domain. > > > > Or is it the case that this changes the content of the aggregate reports in > > a way you find meaningful? > > > > -MSK > > > > > > ___ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > > > -- > Vladimir Dubrovin > @ mail.ru ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] spec nit - subdomains reporting clarity
Hello Tomki, The schema for reports is: first element is , it includes . contains . Do you propose to include in the the base domain, that declared implicitly or explicitly the sp= tag, and then cummulate all data for that domain and subdomains in the same xml.gz report, or do you propose to include several xml.gz files for each domain in a single email? Alternative approaches to reduce the amount of emails are: - include one or more xml reports in a single email, e.g. based on derived policy via the sp= mechanism - group reports for a single domain owner into one email with many xml files, provided that the recipient address of the reports is the same. Here sp= is irrelevant. This is tricky, when the recitient addresses for two domains overlap, but are not identical. - group xml.gz reports for many domain owners (or many distinct second level domains) into a single email, provided that the recipients of the different reports would be the same. Regards Дилян On Fri, 2019-06-21 at 18:04 -0700, Tomki wrote: > The spec appears to be unclear on how subdomains are to be reported - ie > most but not all implementations have performed this as intended, in the > same XML as the top level domain (when the subdomain does not have its > own DMARC TXT record) > > Cisco interpreted the current definition to mean that every subdomain > seen should get its own XML file. (not just the ones with their own > DMARC record) This results in every individual IronPort system [which > has DMARC reporting enabled] generating hundreds to thousands of extra > reports every day. > This can result in corporate reporters like Paypal or Rolls Royce > (IronPort users) sending as many reports in a given day as Google. > > The section which should be referred to in implementing a reporting > engine is 7.2 https://tools.ietf.org/html/rfc7489#section-7.2 > The only relevant bullet that I find here is > " The report SHOULD include the following data:" > >"Data for each Domain Owner's subdomain separately from mail from >the sender's Organizational Domain, even if there is no explicit >subdomain policy" > > In trying to find out why Cisco implemented their reporting in the way > that they did, I've actually had a hard time understanding how others > understood that bullet point well enough - I can only imagine that > everybody just implemented by following examples of existing > implementations. > > A suggested rewording for that bullet point: > " Data for each Domain Owner's subdomains as separate records in a > report titled for the Organizational Domain, unless there is an explicit > subdomain policy - in which case a standalone report is generated for > that subdomain" > > --Tomki > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] spec nit - which DKIM to report
Hello, what is the purpose of the aggregate reports (rua)? Regards Дилян On Fri, 2019-06-21 at 12:06 -0700, Elizabeth Zwicky wrote: > I believe they MUST contain any aligned DKIM signature regardless of validity > and SHOULD contain an entry for each domain, selector, result triple. > > Elizabeth > > > On Jun 21, 2019, at 11:46 AM, John Levine wrote: > > > > In article <7cd366d2-ab8d-cce8-67ff-59b79183c...@tomki.com> you write: > > > As mentioned by Elizabeth recently: (Elizabeth please chime in if this > > > doesn't capture your meaning) > > > > > > the spec does not define *which* DKIM signature should be reported in > > > the DMARC RUA created by a receiver. The proposed resolution to this is > > > that if the receiver does not provide the complete set of DKIM > > > signatures found, they should provide (in order of preference) > > > 1. a signature which passed DKIM in strict alignment with the From: > > > header domain > > > 2. a signature which passed DKIM in relaxed alignment with the From: > > > header domain > > > 3. some other signature that passed DKIM > > > 4. some other signature that didn't pass DKIM > > > > This seeems overcomplex. How about saying the reports SHOULD include > > all valid DKIM reports. If they can't, they can't, and I don't see > > any benefit in offering advice on how not to comply. > > > > > > > > ___ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Abolishing DMARC policy quarantine
Hello, p=reject; pct=0 is equivalent to p=quarantine; pct=0. The rest of this email is about (against) handling p=reject and p=quarantine differently. Namely, where a server rejects on p=reject and “quarantines” on p=quarantine. There are more examples, all under the category p=quarantine, where the spam filter does not think a message is spam and DMARC fails (e.g. missing DKIM-Signature): — an autoresponder. The incoming email will be delivered as non-spam, as the spam filter does not classify the email as spam. Would you suppress the autorespond (out-of-office/vacation) message, or will you take the risk to send bad backscatters, risking lowering your IP reputation. Is it up to the domain owner of the original message decide on you sending backscatters, by publishing slightly different dmarc policies? If you handle quarantine as reject there is no such risk of getting bad IP reputation (under these concrete conditions). If no auto-responder is sent and the mail is not classified as spam, the user will rely on the fact, that an autoresponder was sent… big fuzz. — an 1:1 alias to a different server. If your server thinks the email is not spam, but the server to which the alias is redirected thinks the message is spam, or if the user marks it as spam, your IP reputation gets worse. If you handle quarantine as reject there is no such risk. — a MLM (1:many alias), where anybody can send messages - same problem as above, just bigger damage. p=reject and p=quarantine both communicate, that all messages from a domain must have aligned, valid dkim signature or aligned, valid spf result and that for messages from the domain failing DMARC, there must be some penalty. How many distinct penalty levels does a sending domain owner need? One, or more than one? Are two penalty levels enough? Is there justification for two penalty levels? Can the same justification be used to introduce a third penalty level? What does the domain owner/sending domain want do communicate, by using the first, second, or third penalty level? Currently the decisions on handling quarantine/reject in different ways are taken by: * domain owners, who own a domain * spammers, who use the domain of the domain owner, and let's say are distinct from the domain owners * mailbox operators Not taken into account are the users. Why shall a user want to have more messages in its spam folder (assuming that the quarantined message was at the end classified as spam and the email operator handles Reject and Quarantine differently) versus handling p=quarantine as p=reject and having less Spam to pay attention for? About the costs, Quarantine meaning neither deliver, not reject, but something different, can be implemented in this way: the operator does not deliver the emails failing DMARC for a domain with p=querantine to the users, but arranges staff, to decide what to do. The costs for that staff, are the extra costs for having distinct handling of Reject/Quarantine. If there is no such staff, and the decisions are taken by the users, then the costs are the same, these just are shifted to the users. Finally, while DMARC can be used to communicate that all emails from a domain must PASS DMARC rules, why there is a need to communicate what to do with emails that fail DMARC from: the domain? The DMARC specification can be simplified, by leaving the hanlding of such emails ultimately up to the receiving host and then there is no need to iterate the options at protocol level for the sending domain. (The option, that all emails from a domain must have aligned DKIM signatures, but it is up to the recipient what to do with messages without valid dkim-signature or spf result is anyway missing)j Regards Дилян On Sat, 2019-06-15 at 13:11 -0400, Hector Santos wrote: > On 6/14/2019 5:58 PM, Дилян Палаузов wrote: > > Hello Ken, > > > > effectively I proposed handling p=reject and p=quarantine the same way. > > > > .. > > > > Lets have an example for p=quaranite: > > majordomo@domain is an address where commands are sent and the software > > receiving the > > command always sends an answer, even if the command is unclear. An email > > is sent > > to majordomo@domain. The sending domain has published policy Quarantine. > > This address > > has no spam/junk folder attached to it. The options for an email are: > > * reject the email during the SMTP dialog > > * accept the email and let majordomo send an answer to it > > * arrange a human to decide which emails to discard (handle an imaginary > > Spam folder for the account). > > Oh I see your concern/point/proposal now. > > Yes, I highlighted this basic issue in years past in regards to the > handling semantics debates. Even with SPF, how -ALL (FAIL) was > interpreted and handled was questione
Re: [dmarc-ietf] Abolishing DMARC policy quarantine
Hello Ken, effectively I proposed handling p=reject and p=quarantine the same way. Shall I read in your answer, that failed DMARC validation is weighted differently in the overall spam evaluation, for p=reject and for p=quarantine? > A use case for p=quarantine is that when deploying DMARC for any reasonably > complex site, it forms part of a graduated approach (perhaps in conjunction > with pct=x) utilising aggregated reports to moving towards p=reject. There is no ordering between the policies. p=quarantine is not a softer variant of p=reject, it is just different. Switching from Quarantine to Reject is not a graduate approach. But if some subscribers here see it as such, perhaps more discussions are necessary. In the counter example for extra work, having support queries for rejected emails (p=reject) or for emails arriving misteriosly as spam (p=quarantine) is the same amount of support, extra work. Lets have an example for p=quaranite: majordomo@domain is an address where commands are sent and the software receiving the command always sends an answer, even if the command is unclear. An email is sent to majordomo@domain. The sending domain has published policy Quarantine. This address has no spam/junk folder attached to it. The options for an email are: * reject the email during the SMTP dialog * accept the email and let majordomo send an answer to it * arrange a human to decide which emails to discard (handle an imaginary Spam folder for the account). The third option is expensive and causes delays. The second option could send backscatters, so a caution has to be payed when accepting an email. After the total, complex spam evaluation, the spam filter is uncertain if the mail is spam or not. DMARC evaluation on its own fails. Shall the email be rejected during the smpt dialog (handle Quarantine as Reject), shall the email be accepted, or what do you suggest to do? As for pct=0 on there was a discussion on ietf-s...@ietf.org whether From: shall be rewritten by the MLM on 25-26 Jan 2019 and the outcome is, that the behaviour is unclear (one cannot act wrong by rewriting or not RFC5822.From:). So on pct=0; further ellaboration is necessary. On Wed, 2019-06-12 at 12:05 +0100, Ken O'Driscoll wrote: > On Tue, 2019-06-11 at 21:00 +0000, Дилян Палаузов wrote: > > Dear all, > > > > when DMARC passes, there is no difference between p=reject and > > p=quarantine. > [...snip...] > > However, it is ultimately up to the receiving site to decide, whether it > > wants to accept this extra work. If it does not accept the extra work, > > it just handles quarantine as reject. This does not violate the DMARC > > specitification. > > Even in a moderately complex spam filtering engine, DMARC is just one > indicator / signal amongst many. > > Who does the "extra work" is subjective. For example, a large mailbox > provider may consider support queries about missing or rejected emails as > unwanted "extra work" etc. > > DMARC does not live in isolation - it's part to a greater ecosystem. > > > Do you have a story, why one wants to publish p=quaratnine? What is the > > use case for it? It just makes emails less reliable, as they end as Junk > > and this is very similar to discarding the emails. > > There is a world of difference between requesting that a recipient flag an > incoming message as spam as opposed to asking them to discard it outright. > And that is regardless of how individual mailbox provides treat > p=quarantine. > > A use case for p=quarantine is that when deploying DMARC for any reasonably > complex site, it forms part of a graduated approach (perhaps in conjunction > with pct=x) utilising aggregated reports to moving towards p=reject. > > The proactive nature of DMARC means that its deployment needs to be > properly planned with any risks mitigated as best as possible. The various > stages of p= can easily be articulated on a project plan / risk register. > > And such sites that require such planning are often starting from a > position of improperly documented mail flows and inconsistently implemented > SPF/DKIM. In addition they often operate in regulated sectors and are > commonly top-heavy with risk-adverse middle management. > > I accept that a small site with a simple mail flow which does not operate > in a regulated space and has thin governance could likely move straight > from p=none to p=reject without serious repercussions. Such sites are not > the majority of DMARC deployments. > > DMARC changes how recipient mailbox providers treat email and therefore it > needs to be deployed in a controlled manner, p=quarantine being one > component of that. > > > Imagine a mailing lists, where the recipient of an email addr
[dmarc-ietf] Abolishing DMARC policy quarantine
Dear all, when DMARC passes, there is no difference between p=reject and p=quarantine. When DMARC fails validation, this means extra work for humans. This work can be done by the sending or by the receiving organization. With p=quaratine, the sending organization (domain owner) indicates, that the extra work is supposed to be done by the receiving organization. So for the senders it is just cheaper (in terms of less work) to publish p=quarantine. With p=reject, the sending organization (domain owner) indicates, that the extra work has to be performed by the sending server, which might be the domain owner or some suspects. However, it is ultimately up to the receiving site to decide, whether it wants to accept this extra work. If it does not accept the extra work, it just handles quarantine as reject. This does not violate the DMARC specitification. Do you have a story, why one wants to publish p=quaratnine? What is the use case for it? It just makes emails less reliable, as they end as Junk and this is very similar to discarding the emails. Imagine a mailing lists, where the recipient of an email address expands to several mailboxes on different domains. An incoming email fails DMARC validation before being distributed over the ML. The domain owner for that mail origin has published p=quarantine, this email cannot be delivered in the Junk folder of the recipient, because the mailing list itself does not have a junk folder. How about, deleting policy Quarantine and instead rephrasing policy Reject: It is up to the receiving server if it rejects messages failing DMARC, or accepts and delivers them as Junk. (This does not change the protocol, just the wording) Regards Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication
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). So if the DMARC evaluation status for policies Quarantine or Reject is shown, it will be PASS. For policy None, I doubt that showing the authentication status has added value. So if the MUA shows the status for DMARC it will be PASS. When will showing the DMARC status to the user have added value for her? For SPF status... you know that redirects, if the MUA shows “failed SPF”, what shall the user conclude? For DKIM evalution, that was not covered by the DMARC policy above, you suggest that the MUA shows "DOMAIN: FAIL/PASS". If it passes, then it is good. But what shall be the conclusion made by the user, if the DKIM for a domain shows FAIL (or missing DKIM-Signature header)? Regards Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Endless Loops with DKIM reports
Hello Validimir, the point is that answers can be sent to the (DKIM) report and receiving the answers can trigger sending a new report to the address published in DNS. Empty return path prevents sending an answer to the report. What to do if a site sends a report that does not validate DMARC/DKIM, then a new (reverse) report by the other host is sent and this report again does not validate DMARC/DKIM, so it triggers a new report? This is a concern of improperly configured site pairs. The target for the recommendation to use MAIL FROM:<>/NOTIFY=NEVER are properly configured sites, that deal with improperly configured sites. Regards Дилян On June 4, 2019 2:48:32 PM GMT+03:00, Vladimir Dubrovin wrote: > >Reports are not sent to Return-Path address, empty return path does not >prevents report from being sent. Actually, report with empty >envelope-from has higher chances to generate a reverse report, because >in this case SPF is checked against HELO and, in practice, many seders >do not have SPF configured for HELO name and SPF failure can trigger a >report. > >04.06.2019 12:41, Dave Crocker пишет: >> On 6/4/2019 11:27 AM, Дилян Палаузов wrote: >>> A DKIM failure report is sent, on which a bounce is generated >> >> The rule for mail-handling notification messages has been that they >do >> not contain a return address, in order to avoid looping. Shouldn't >> that apply to DMARC reports, too? If not, why? >> >> d/ >> > >-- >Vladimir Dubrovin >@Mail.Ru ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Endless Loops with DKIM reports
Hello, the reporting per RFC 6651 can also cause endless email loops: A DKIM failure report is sent, on which a bounce is generated and the bounce contains DKIM-Signature: r=y with invalid signature. So a new DKIM failure report is generated. The signature does not have to be invalid, having broken validator also messes the situation. Regards Дилян___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion
Hello Douglas, 1) Check the Authentication-Results header. An implementation could put there additional information as comment. A downstream MTA will reevaluate the DKIM-Signature anyway, if it does nkt trust the previous hop. Common case: aliases to random servers. 2) Check ARC, https://tools.ietf.org/wg/dmarc/ . 3) To fix the origin of a bad dkim signature problem the sender has to be notified about the inconsistencies so that the sender can take actions and correct the signing process, asuming the problem is not on verifier’s side. Propagating and logging the mismatched signature does not help correcting the source of the problem. Part of the DKIM magic is the volume of papers one has to read in order to understand it, and fix whenever something goes wrong. Here come other email protocols: submit, mta-sts, dane for smtp, dmarc, https://starttls-everywhere.org/, wrong certificate purpose … and you end having very few people being able to understand and correct a problem, even when all the necessary informarion can be extracted from logs or error reports. If you cannot run different dkim verifiers towards a single dkim-signature with corresponding message, and if the sender repeatedly does not answer on emails, no further normative text helps you. By the way, why writing you directly earlier today I got as reply '“reason: 550 Sender IP reverse lookup rejected”? Regards Дилян On May 26, 2019 3:22:25 PM GMT+03:00, "Douglas E. Foster" wrote: > > Problem > >DKIM verification failures are difficult to debug because the recipient > >cannot detect where the problem occurred or why. > > Proposed Solutions > > 1) Identify the point of failure > >It would seem helpful to support a DKIM trace record that a device can >use >to indicate that it detected a DKIM failure. I am suggesting a header >of >the form "DKIM-InputFail", followed by the contents of the signature >header >that could not be verified. This puts an upper bound on the location >of >the problem. (Once the failure is documented, it should not be >repeated by >downstream servers.) > >A downstream MTA is still free to evaluate the original signature. >For >example, an intermediate MTA may have reported the failure incorrectly >because of a software bug. > > 2) Recover from Subject header changes that break signatures. > > One expected cause of DKIM verification errors is Subject header >modification, either by spam filters or by list servers. These types >of >changes can also be mitigated by trace headers. If a device makes a >change to the subject, it should add headers for "Subject-AsReceived" >and >"Subject-AsSent". Any downstream system can then reconstruct which >header >text was in place when any signature was applied, regardless of how >many >Subject header changes occur during transmission. > >Downstream servers would also have the option of restoring the Subject >header to its original value. This would be appropriate when the >Subject >was tagged by the spam filter upon arrival to an administrative domain, >and >then is auto-forwarded to a different administrative domain. If the >outbound MTA restores the original subject, it increases the likelihood > >that the message will be accepted downstream. > >The concept could be applied to other headers. For example, I have >seen >messages with DKIM failures because an auto-forward server replaced the > >internal Message-ID with one of its own. I don't know if there are >legitimate reasons for intermediate MTAs to tamper with other headers. > > > > ___ 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 Grant, it is a misconfiguration, but it still creates a mail loop for the site, that is not misconfigured. To what I can say the emails are accepted at SMTP time and then bounced. I not asking to modify DMARC, but to recommend sending message-specific, individual failure reports FROM: <>, in order to be protected from “misconfiguration attacks”. Regards Дилян On May 26, 2019 8:20:50 AM GMT+03:00, Grant Taylor wrote: >On 5/25/19 11:09 PM, Dilyan Palauzov wrote: >> 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. > >Are the reports that you are sending being accepted at SMTP time and >then bounced after the fact? > >That sounds like (what I think is) a misconfiguration on their end. > >As such, I'm less inclined to think that modifying DMARC is the proper >thing. Especially if this is a rare occurrence (as in a very select >candidate). > > > >-- >Grant. . . . >unix || die ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Collecting DMARC issues and nits for DMARC WG phase III - DMARC standardization
Hello Seth, > - Definition of "pct" parameter: https://trac.ietf.org/trac/dmarc/ticket/5 The original email is https://mailarchive.ietf.org/arch/msg/dmarc/fRogXZnH2H9IEQyf_UXPx1_KLvE, which references section 5.3 of https://tools.ietf.org/html/draft-kucherawy-dmarc-base-09#section-5.3, which today https://tools.ietf.org/html/rfc7489#section-6.3 (Section 6.3 of RFC 7487). This might be also related to https://trac.ietf.org/trac/dmarc/ticket/22 , but it does not contain the word “testing” as purpose. My concerns: For the purpose of running a test system, one wants to receive all reports, individual or aggregate, whenever a problem appears. "p=quarantine; pct=1" would send a report whenever a problem appears, but has as side effect, that some bad emails (1%) will be quaratined. This test system is supposed to do MLM rewritings, just as normal NON-test system will do, in order to test the whole delivery chain. The combination to have a system, that just sends (individual or aggregate) reports on failures, which does not impact anyhow mail delivery, is “p=quarantine; pct=0;”. Currently it is not defined, what that last policy shall mean and there is not policy that just sends reports, but otherwise 100% delivers the emails properly. So "p=reject; pct=0;" just fits. Now, I do not recall if "p=none;", with or without pct does sends reports… - RFC 6651 defines r=y to send a report whenever a DKIM-Signature fails. When a MLM rewrites a mail, and changes From:, DMARC for the new email does validate, however the untouched DKIM-Signature fails. The current recommendation is to generate a report for the failed signature. This report is useless and distracts from useful reports. The report is useless, because the MLM intentionally broko the DKIM signature and there is nothing the sender of the email can do and also there is no way how this report can be tackled. So for DMARC to function fluently, there shall be no distracting DKIM reports. Whether this is DKIM or DMARC domain does not matter. The topic was discussed at ietf-d...@ietf.org (https://mailarchive.ietf.org/arch/browse/ietf-dkim/) in Augist - October 2018. Regards Дилян On Thu, 2019-05-09 at 14:23 -0700, Seth Blank wrote: > With the group officially in Phase III of the DMARC WG charter, our work is > now to explicitly review and refine the DMARC specification, with the goal of > generating a standards track document. > > The draft-ietf-dmarc-psd experiment is part of this process, as is the > conversation about defining proper ARC reporting XML for DMARC reports. > > This email is an explicit CALL FOR ISSUES AND NITS about the DMARC spec which > you believe should be officially discussed as part of the DMARCbis process. > Please start a separate thread for each item you have. I'll make sure all are > properly in the issue tracker and get addressed. > > Please send in your items no later than *Friday, May 24th*. After this point, > we'll be focusing on progressing the DMARCbis process, not gathering new > issues. > > Below are a list of nits already in the datatracker. I'll be kicking off > threads for several other issues I'm aware of shortly. > > Thanks everyone! > > Seth, as Secretary > > Active issues for DMARCbis in the data tracker: > - SPF 4408 vs 7208: https://trac.ietf.org/trac/dmarc/ticket/1 > - Flow of operations text: https://trac.ietf.org/trac/dmarc/ticket/2 > - Two tiny nits in 6.6.2 and 6.6.3: https://trac.ietf.org/trac/dmarc/ticket/2 > - Definition of "fo" parameter: https://trac.ietf.org/trac/dmarc/ticket/4 > - Definition of "pct" parameter: https://trac.ietf.org/trac/dmarc/ticket/5 > - Fuzzy normative language around filenames: > https://trac.ietf.org/trac/dmarc/ticket/6 > - ABNF for dmarc-record is slightly wrong: > https://trac.ietf.org/trac/dmarc/ticket/7 > - Perverse incentives to use p!=none & pct=0: > https://trac.ietf.org/trac/dmarc/ticket/22 > - objection to maintaining registry for all participating public suffixes: > https://trac.ietf.org/trac/dmarc/ticket/24 > - Link to "URI" reference broken in several sections: > https://trac.ietf.org/trac/dmarc/ticket/25 > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DKIM
Hello Hector, you can check https://github.com/Exim/exim/commit/286b9d5fa4344de72fe6575fa089237 (Exim+GnuTLS) or https://github.com/trusteddomainproject/OpenDKIM/commit/35bf6c901a2 (OpenDKIM+OpenSSL) and the last discussion at https://mailarchive.ietf.org/arch/browse/dcrup/ (dc...@ietf.org) . Regards Дилян On Tue, 2019-04-23 at 22:02 -0400, Hector Santos wrote: > Can anyone provide me some C/C++ or pseudo-code to do DKIM ecdhc > encryption?... Using OpenSSL API in v1.1 format? > > Thanks > > PS: Not sure where to post this, but it equally applies to OpenSSL at > GitHub. > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] SPF / Re: Email security beyond DMARC?
Hello Doug, my understanding is, that SPF complements DKIM only in the cases, where the MTA is not capable to sign an email, e.g. a bounce. So, if your MTA can DKIM-sign everything, you do not need SPF. > Do you handle SPF any differently between senders with DMARC enforcement and > those without? No, SPF does not work with aliases (where no SRS is applied). My experience sending email over a mailing list to some domains directly and to the same domains indirectly (over other hosts, which in fact do aliasing) for a DKIM signature that failed is, that due SPF the direct emails were delivered, whereas the indirect emails were not. This also created indirect feedback, that is not in my logs very precise. So I concluded to remove SPF TXT records and next time such things happen, I can check in the logs which message in particular was rejected and maybe avoid such situations in the future. Regards Дилян On Thu, 2019-03-21 at 14:36 -0400, Doug Foster wrote: > I am all for anything that cuts unwanted email. Not sure of the need to > distinguish between spam and phishing. > > I am assuming that I am the only one in this group not using DMARC. You > heard my problems with SPF. > > What do you do for SPF Exceptions? > · We have never seen a legitimate sender who needed an exception? > · We whitelist the source IP address and trust that it will only be > used for appropriate domains? > · We whitelist the sender domain and hope it will never be spoofed? > · Something else? > > Also, how do you handle SPF non-pass: Neutral, Softfail, Syntax errors, or > Excessive nesting > > Do you handle SPF any differently between senders with DMARC enforcement and > those without? > > Doug Foster > > > From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Ken Simpson > Sent: Thursday, March 21, 2019 1:01 PM > To: John R Levine > Cc: IETF DMARC WG; Dotzero > Subject: Re: [dmarc-ietf] Email security beyond DMARC? > > > > I'm going to have to disagree with you John. DMARC is about preventing > > > direct domain abuse. It does not specifically address phishing as the bad > > > guys can simply use cousin domains, homoglyphs, etc. > > > > Well, it's abount a subset of phishing. It's surely more about phishing > > than about spam. > > > IMHO, by cutting out direct domain spoofing, DMARC makes it easier for > receivers to craft algorithms that spot impersonation attacks. Once you have > configured DMARC, receivers can build - for example - a machine learning > system that learns what your legitimate email looks like. They can use that > same system to identify messages that look like your legitimate email but > which do not actually originate from your domain. > > If you want to detect domain impersonation or "brand" impersonation, you > first have to have a verifiable ground truth corpus. That is what DMARC > offers. > > Regards, > Ken > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy
Hello John, DMARC reports for p=none are not supposed to be useful, as they do not depend on the policy. If the question is about how to get reports on failing DKIM validation only on unexpectedly smashed messages, then I recall the last discussion on ietf-d...@ietf.org: - this is not DMARC, but DKIM domain - when the DKIM-Signature does not validate, contains r=y and the remainign provisions from RFC6651 do apply, a (usefull) report shall be sent - when a message is intentionally modified, in way that the DKIM-Signature gets invalidated, the modified message shall adapt somehow the fact that it was intentionally modified for particular DKIM-Signatures, so that no useless report is sent - Nobody wants to modify DKIM-Signature, so it is unclear where to add the information that the message was intentionally smashed in regards the first and second DKIM-Signature, but not for the third one. I proposed at the time to add a r=a tag, sending only report, when DKIM aligns to From:, so that after passing a MLM rewriting From: no reports shall be sent (contrary to r=y). Now I realize, that for p=none there is no added usefulness, since - DKIM-Signature gets usually intentionally broken, while passing over the MLM, and - From: is not rewritten, therefore From: alignes to the signature, so a useless report will be sent for the message. Regards Дилян On Tue, 2019-02-05 at 20:01 -0500, John Levine wrote: > In article <974c2d00017358cdf3b78037e4276234db2cfdee.ca...@aegee.org> you > write: > > Hello John, > > > > On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote: > > > … The failure reports are almost > > > entirely useless. Of the ones I get, the majority are random Chinese > > > spam that happened to forge one of my domains on the From line, the > > > rest are from mailing lists where I wouldn't expect DMARC to pass. > > How do you define a useful report and for which purpose do you want to > > receive reports? > > A useful report would be one that was a message that one of my users > had actually sent and was smashed in a way I didn't expect. > > > I mean, when does sending reports to p=none make sense. > > The feedback reporting doesn't depend on the policy. Please review > section 7 of RFC 7489. > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy
Hello John, On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote: > … The failure reports are almost > entirely useless. Of the ones I get, the majority are random Chinese > spam that happened to forge one of my domains on the From line, the > rest are from mailing lists where I wouldn't expect DMARC to pass. You have published DNS TXT _dmarc.taugh.com “v=DMARC1; p=none; rf=afrf; rua= mailto:dmar...@abuse.net; ruf=mailto:dmar...@abuse.net”. How do you define a useful report and for which purpose do you want to receive reports? I mean, when does sending reports to p=none make sense. Regards Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy
Hello, sending a notification, when DMARC does not match is comparable to sending a notification/feedback loop, when a user clicks a message as spam. In practice, when a company owns two labels, that were distinct companies in the past, for the one label the new company sends in the feedback loop the user, who clicked the the mail as unwanted, and the other label does not include the recipient’s mailbox. Both labels include the Message-Id in the report. So when the messege was sent to one user, with the Message-Id it is possible to determine which user clicked the mail as unwanted (provided no transparent MLMs were involved). When the message was sent over a mailing list, from the Message-Id it is not possible to determine which user marked the mail as unwanted. It is technically possible to provide to every single recipient-copy spread over a mailing list a distinct Message-Id, in order to be able to conclude from the feedback-loop message, which user marked the mail as unwanted, and be able to unsubscribe the user from the mailing list. Is this the way to go, or is the rationalle that the one who implemented the feedback loop including Message-Id intentionally skipping the recipient mailbox do not understand the big picture? Will be there any rational concerns, if for a failed DKIM validation a report is sent to the signing server, containing just the Message-Id, when From: alignes and DMARC p!=none? Regards Дилян On Mon, 2019-01-28 at 10:15 +0100, Alessandro Vesely wrote: > On Sat 26/Jan/2019 18:21:28 +0100 Дилян Палаузов wrote: > > > Imagine there is a failure report stating that after a direct communication > > between your server and another server, the receiving server sends you an > > aggregate report, stating that 1% of the messages you sent yesterday do not > > validate DKIM. How do you suggest to proceed to reduce this to 0%? > > No way. There are lots of little traps, for one example plain text messages > where a line start with "From ", like so: > > > From here on, this message likely fails DKIM. > > As small as this cases appear, if you program your MTA to fix them before DKIM > signing, you are going to break any OpenPGP/SMIME signatures that users had > affixed before. > > You can educate users to use format=flowed, good luck. > > You can push for global maildir usage, even harder. > > The bottom line is that, in practice, understanding where that 1% failures > come > from won't help eliminate them. > > > Best > Ale ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy
Hello, reiterating over the arguments against sending reports to the ruf= …dmarc address, the first provided reason was, that such report will not match the expectations of the users. Which users? On the site that sent the initial mail or on the site that generated the report. It can be assumed, that sending reports to the ruf= address at a certain domain matches the expectations of the users of that domain and any non-matching expectation is a problem of the one who published the ruf= entry, not the one generating a report. I do not say that once the report is generated and sent the sender has to store the report, so that the expectation of the user, that received the initial mail, are also met, when the report generating server does not store a copy of the sent report. The second argument was, that staff managing DNS and staff managing emails (and able to read user’s email) are completely different persons. I do read here, that the DNS staff can use its posititon to insert arbitrary email addresses in the ruf= tag and by this way come in a position to read emails, that otherwise the DNS staff would not be entitled to read. Seriously, if the ruf= tag is not trusted, why shall the p= tag be honoured, and why shall also be the DKIM public signature and MX record be trusted? Either the ruf= email address is trusted to receive reports, or the whole DNS of the sending domain is not trusted. The third argument is, that in case 1% ouf of 10 000 000 messages between two hosts are reported in the aggregate message not to match DKIM, then it is worth investigating the cause. Alright, that is exactly my point. I want the reports, provide ruf=, and don’t receive the reports. Where will you start investigating? How can you find out if the problem is on the sender or receiver side? If you validate once again your implementation and find nothing wrong with it, does it prove, that the implementation of other side has bugs? Perhaps the other side has also proven in the very same way, that it is error-free. You see only that 1% of the messages do not match DKIM validation, now and then. What is the next step to make signer and verifier compatible? Guessing? If making signers and verifier compatible can be achieved only by guessing, then DMARC cannot be trusted/is not mature. I have no problems if due changes somewhere DKIM for a while fails, as in this case there is nothing I can do. But I want to be sure, that the cause is not on my side, and currently this is not evident. It is just not clear, if there is a problem report, if the problem is temporary, when the cause was resolved, if the cause is on my side… This properties make DMARC not reliable. Regards Дилян On Sat, 2019-01-26 at 12:56 -0500, Dotzero wrote: > Please, RUF is a ""Failure Report", not a "Forensic Report". Please read RFC > 7489 - https://datatracker.ietf.org/doc/rfc7489/ > > On Sat, Jan 26, 2019 at 12:21 PM Дилян Палаузов > wrote: > > Hello John, > > > > On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote: > > > In article <6a56a3831dd4651e0d7610ee0c90f50749a7203b.ca...@aegee.org> you > > > write: > > > > How can a domain owner communicate, that its users agree to have > > > > investigations on forensic reports, where DKIM > > > > signatures failed (fot the purpose of avoiding repeating errors in DKIM > > > > signing/validation)? In particular, that there > > > > is no expectation of the users that a deleted message is erased and > > > > that the domain owner, DNS staff and email staff > > > > function good as whole? > > > > > This is way outside the scope of DMARC., however, the very fact that the > domain has provided an email address for receiving RUF reports is a pretty > reliable indicator. Presumably DNS and mailops staff work for/on behalf of > the domain owner. > > > > I suppose they could try to put it in the terms of service, but I > > > wouldn't begin to guess whether that would be enforcable or even legal > > > in places with the GDPR and other privacy laws. > > > > > > More to the point, I wouldn't bother. The failure reports are almost > > > entirely useless. Of the ones I get, the majority are random Chinese > > > spam that happened to forge one of my domains on the From line, the > > > rest are from mailing lists where I wouldn't expect DMARC to pass. > > Clearing out the chaff originating from servers other than your own helps, > but I'm not going to try to teach John anything. > > A domain owner can certainly clarify anything in the terms of service, but > > even if the domain owner does these > > clarifications, s/he will not receive DKIM/DMARC fore
Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy
Hello John, On Sat, 2019-01-26 at 11:31 -0500, John Levine wrote: > In article <6a56a3831dd4651e0d7610ee0c90f50749a7203b.ca...@aegee.org> you > write: > > How can a domain owner communicate, that its users agree to have > > investigations on forensic reports, where DKIM > > signatures failed (fot the purpose of avoiding repeating errors in DKIM > > signing/validation)? In particular, that there > > is no expectation of the users that a deleted message is erased and that > > the domain owner, DNS staff and email staff > > function good as whole? > > I suppose they could try to put it in the terms of service, but I > wouldn't begin to guess whether that would be enforcable or even legal > in places with the GDPR and other privacy laws. > > More to the point, I wouldn't bother. The failure reports are almost > entirely useless. Of the ones I get, the majority are random Chinese > spam that happened to forge one of my domains on the From line, the > rest are from mailing lists where I wouldn't expect DMARC to pass. A domain owner can certainly clarify anything in the terms of service, but even if the domain owner does these clarifications, s/he will not receive DKIM/DMARC forensic reports, because there is no mean to communicate to the generators of those reports, that sending forensic reports violates users expectations. The reasons mentioned here against sending forensic reports were, that this might not match user expectations (on deleted information) and because email staff and DNS staff may differ. I approached both concerns, by stating that user expections can be put in Terms of Use and that a domain owner can decide, that for a domain it is acceptable to receive forensic reports and insert this infomation in the Terms of Use. So… what else exactly needs to happen, to resolve the concerns against sending forensic reports (which was my original question)? If GDPR is the only concern, this can also be clarified. But clarifying that GDPR is not a problem, will be losing time, if independent of it there are other concerns. Imagine there is a failure report stating that after a direct communication between your server and another server, the receiving server sends you an aggregate report, stating that 1% of the messages you sent yesterday do not validate DKIM. How do you suggest to proceed to reduce this to 0%? Regards Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Thin forensic DMARC reports
Hello, will be there any concerns for sending slim forensic DMARC reports (ruf=) on failed DKIM validation, if * between sender and recipient there are no intermedates/aliases/redirecting providers, * the third MIME part of multipart/report is cut (contrary to https://tools.ietf.org/html/rfc5965#section-2 bullet d), and * in the message/feedback-report part - either the Original-Envelope-Id is included, - or Original-Message-Id is included (where Original-Message-Id will be defined to be the Message-Id of the message that is reported)? The Original-*-Id identifiers do not expose privacy information, but let the sending server identify for which message the DKIM signing/validation do not match. Whether the sending user has deleted the message in the meantime does not matter. Knowing which message is problematic is a huge improvement compared to the current situation. First, the sender can validate with different implementations whether they all produce the same signature for that message. Second, if the message in question is sent over a mailing list, the From: was changed by the MLM, the DKIM signature was added after the mail left the MLM but before leaving the MLM-mail-server, then this very message is likely to be distributed to several mail providers. If one provider does not validate the signature, and the other providers validate the signatures, (or all mail providers do not validate), then somebody can take some actions so that the cause for the failure is resolved and does not happen again in the future. A clear plus for all DMARC-users. Regards Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy
Hello, On Sat, 2019-01-26 at 10:36 -0500, John Levine wrote: > In article <40a9f309a70254b799f8bc3e42cbec2f5cf9dd7b.ca...@aegee.org> you > write: > > What are the privacy concerns in this simple scenario that speak against > > sending a DMARC/DKIM report to sending server, > > telling that the DKIM validation fails? > > The person reading the DMARC reports had enough authority to put a > record in the DNS, but that is not the same thing as being able to > read all of the users' mail. > > In large mail systems, different staff have different roles, and very > few of them can look at users' mail. Aha, we have staff dealing with DNS, staff dealing with email boxes and domain owners. How can a domain owner communicate, that its users agree to have investigations on forensic reports, where DKIM signatures failed (fot the purpose of avoiding repeating errors in DKIM signing/validation)? In particular, that there is no expectation of the users that a deleted message is erased and that the domain owner, DNS staff and email staff function good as whole? Regards Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC forensic reports (ruf=) and privacy
Hello, how does the unrealistic expectation of message sender and recipient, that a “deleted” message is immediately irreversibly removed from all backups, differ from the expectation that an “erased” message does not exist in a forensic subsystem? Do Terms of Use, that clarify the sending of forensic reports (and backup policies) close the expectation/reality gap? Regards Дилян On Sat, 2019-01-26 at 16:26 +0300, Vladimir Dubrovin wrote: > Message sender can expect message content is only stored in sender's and > recipient's mailboxes after delivery. If deleted by both sender and > recipient, this message is not longer exists and it's content can not be > recovered. > > In this scenario, (partial) message content can be stored in DMARC > forensic subsystem unknowingly to user, it may violate user's privacy > expectations and/or rights, depending on local legislation. > > > > 26.01.2019 14:37, Дилян Палаузов пишет: > > Hello, > > > > for a smooth working DMARC DKIM signers and verifiers must be > > interoperatable. When a server DKIM-signs a message and > > sends it to another server without intermediates, the latter shall be able > > verify the signature. Imagine, the DKIM > > validation fails and the ruf= dmarc report email address points to the > > sending server. > > > > What are the privacy concerns in this simple scenario that speak against > > sending a DMARC/DKIM report to sending server, > > telling that the DKIM validation fails? > > > > https://tools.ietf.org/html/rfc7489#section-9 mentions some privacy > > thoughts, but these are not applicable when the > > sending server obviously has already the reported message and no > > intermediates are involved, that could expose > > additional information. > > > > Regards > > Дилян > > > > ___ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARC forensic reports (ruf=) and privacy
Hello, for a smooth working DMARC DKIM signers and verifiers must be interoperatable. When a server DKIM-signs a message and sends it to another server without intermediates, the latter shall be able verify the signature. Imagine, the DKIM validation fails and the ruf= dmarc report email address points to the sending server. What are the privacy concerns in this simple scenario that speak against sending a DMARC/DKIM report to sending server, telling that the DKIM validation fails? https://tools.ietf.org/html/rfc7489#section-9 mentions some privacy thoughts, but these are not applicable when the sending server obviously has already the reported message and no intermediates are involved, that could expose additional information. Regards Дилян ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
