[dmarc-ietf] Re: Aggregate Reports sent by a third party
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <3446f0a8-5a90-0d50-b315-f25140fd6...@vendo.no>, Daniel K. writes >Imagine OK, boring afternoon so far ... >This way we do not know about what bad actor is doing, unless we >manually look into every duplicate report. a) do you get so many duplicate reports every day that you don't wonder about them anyway ? b) DMARC reports are really useful in tracking down why genuine email has been sent from your organisation that has not properly authenticated (though it continues to amaze me in $DAYJOB$ how many people don't do that at all and are surprised to learn it is happening). Beyond that, knowing that there are bad actors out there is seldom actionable. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZ1X3j92nQQHFxEViEQJd5ACfe+H17cs6r3Glmg3XgvfCBZDzsd0An1BM Rf165buQ8WPtwjsF2AwYFcKc =c9uA -END PGP SIGNATURE- ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: [secdir] Re: Re: Secdir last call review of draft-ietf-dmarc-dmarcbis-36
In message <26450.1765.564017.770...@fireball.acr.fi>, Tero Kivinen writes >If you are not participating in DMARC, do not implement or read this >specification. I think that has been addressed >If you do want to implement DMARC, you do all the MUSTs >listed in this specification and there is no need to say that "if you >implement this RFC, you MUST do x". You may wish to publish a DMARC record and do nothing else. You may or may not wish to provide SPF records documenting your use of IPs -- when publishing a DMARC record. You may or may not wish to provide DKIM keys indicating how you sign email -- when you are publishing a DMARC record. You may wish to consider DMARC when assessing incoming email and do nothing else DMARC related. If you assess incoming email you may or may not wish to send reports about what you have learnt. Having published a DMARC record you may or may not wish to request that others put effort into sending you reports. >And I think those "participating in DMARC" words needs to be removed. >They are not needed. Everybody implementing things based on this >specification are "participating in DMARC", so we do not need to add >that to every single statement. In each case I set out, there will be a MUSTs to consider when configuring your system, but in the alternative you will ignore the MUST as inapplicable given your level of engagement. Hence the necessity for conditional statements throughout -- to keep the protocol police at bay. -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Threat analysis and response
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >Example.com sends 10,000 messages per day, of which 100 (1%) produce DMARC >Fail, so they publish a policy with p=none. and presumably they get on with fixing the flows which fail (tracking down the rogue marketing staff etc) >Attackers send 1,000,000 messages that impersonate Example.com. On a >global basis, messages claiming to be from Example.com are 99% Fail, and >the Fail are 99.99% true spam and 0.01% false positives. only if example.com is still in the process of fixing things >In response, Example.Com changes its policy to p=reject. The spammers >mostly switch to impersonating Example.Edu,leaving only 100 attacks per day >on Example.Com. The Fail rate is now down to 2%, of which 50% are true >spam and 50% are false positives. > >But nobody but God sees the global threat situation. An evaluator who >sees 50 messages per day may see 50 PASS, 50 False Positives, 50 True Spam, >or any mix of the three. Additionally the mix may change over time. indeed so, but example.com has said "I think that on balance you would do well to reject messages that appear to be from me but fail DMARC. You could be a bit clever about this if you really want to be, but I am trying really hard to send only validatable email so why don't you follow my carefully considered advice" >Responses: >Some evaluators will see 50 true spam with p=none, conclude that DMARC is >useless, and unconditionally block Example.com. that's odd ... you said above that example.com changed their policy to p=reject. The evaluator should fix their DNS cache. > When the mix changes, >legitimate messages will be blocked. it is always the case that people who unconditionally block domains where there is legitimate traffic will be sad. No protocol that I can conceive of will ever fix this for them I've skipped the rest because of the DNS cache problem. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZ1G2J92nQQHFxEViEQJilACeIY+mdPIFZdTW73E3u7tzi6aFfgwAnRV+ vUenukhZIjk+zTmP09mNVVQt =VKnA -END PGP SIGNATURE- ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: [secdir] Re: Re: Secdir last call review of draft-ietf-dmarc-dmarcbis-36
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <26448.59725.287538.334...@fireball.acr.fi>, Tero Kivinen writes >Richard Clayton writes: >> In message <26447.29429.714935.943...@fireball.acr.fi>, Tero Kivinen >> writes >> >> > Requirements for DMARC validators: >> > >> > - MUST implement mailto url for reports (4.7) >> >> I do not believe that 4.7 says that > >It says: > > ... A Mail Receiver MUST implement > support for a "mailto:"; URI, i.e., the ability to send a DMARC > report via electronic mail. > >both for rua and ruf tags, so I think that is supposed to mean that >mailto urls are mandatory to implement for sending reports. so it does ... that's clearly not nuanced enough. It needs to say something like a "Mail Receiver participating in DMARC MUST ..." can the editors please fix that. >It does not seem to say that sending reports is mandatory, and clearly it ought not to. There's "participating in DMARC" wording elsewhere in the document to cover this sort of thing [...] >> > - MUST store authentication results for eventual presentation back >> >to the domain owner. (5.3.7) >> >> you have missed out a conditionality.. there is no requirement in the >> document to create aggregate feedback results. > >Ok, so the 5.3.7 MUST is wrong, it is SHOULD, not MUST, if there is >condition where it does not apply. the condition is at the start of 5.3.7 ... the very first few words >So changing 5.3.7 from: > >-- >5.3.7. Store Results of DMARC Processing > > If the Mail Receiver intends to fully participate in DMARC, then > results obtained from the application of the DMARC mechanism by the > Mail Receiver MUST be stored for eventual presentation back to the > Domain Owner in the form of aggregate feedback reports. Section 4.7 > and [I-D.ietf-dmarc-aggregate-reporting] discuss aggregate feedback. >-- which you have helpfully quoted... so there's no need to change that IMO >If you have MUST with condition that is SHOULD. And having condition >of "intends to fully participate" is not very good condition... > >> > - MUST NOT reject incoming messges solely on the basis of a >> >p=reject. (7.4) >> >> there is a SHOULD NOT in this section > >There is SHOULD in 2nd block marked with '|', but the 3rd block >includes MUST NOT. sigh ... I really ought to read what people actually put in documents rather than what the mailing list discussion concludes... > The text I am referencing is: > >-- >7.4. Interoperability Considerations >... > | It is therefore critical that Mail Receivers MUST NOT reject > | incoming messages solely on the basis of a "p=reject" policy by > | the sending domain. Mail Receivers must use the DMARC policy as > | part of their disposition decision, along with other knowledge and > | analysis. I always understood that "MUST NOT except when you have thought about it" was spelled "SHOULD NOT". Why does this draft not follow that approach ? [] > In the absence of > | other knowledge and analysis, Mail Receivers MUST treat such > | failing mail as if the policy were "p=quarantine" rather than > | "p=reject". and again "MUST except when you have thunk" is spelled "SHOULD" I went back and read RFC2119 and my memory appears to be correct. >This is the exact reason I think we DO NEED conformance requirements >section... We can't have this kind of ambiguity about mandatory to >implement features. I think we just need some words spelled correctly. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZ1D43N2nQQHFxEViEQKRhACgw0alBKpG3JZNeCfrQPvtS2MHcyQAoIo+ DgOeW/LkWykAHYlIb2Gn+zNS =LwCQ -END PGP SIGNATURE- ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: [secdir] Re: Re: Secdir last call review of draft-ietf-dmarc-dmarcbis-36
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <26447.29429.714935.943...@fireball.acr.fi>, Tero Kivinen writes > Requirements for DMARC validators: > > - MUST implement mailto url for reports (4.7) I do not believe that 4.7 says that > - MUST check SPF and store preserved result (5.3.3) it does not say that, it says it has to be preserved for future use, there is no requirement to store it > - MUST check DKIM and store preserved result (5.3.3) ditto > - MUST store authentication results for eventual presentation back >to the domain owner. (5.3.7) you have missed out a conditionality.. there is no requirement in the document to create aggregate feedback results. > - MUST NOT reject incoming messges solely on the basis of a >p=reject. (7.4) there is a SHOULD NOT in this section > Requirements for Domain owners: these are NOT requirements for Domain owners ... we're not going to say that they MUST send mail ! > - MUST send mail so it produces an SPF-Authenticated identifier (to >configure SPF for DMARC) (5.1.1) You have that backwards (or at least you have failed to express the conditionality), it's IF you want to have validators consider whether there is a valid SPF pass for DMARC THEN you MUST ... 5.1.1 does not say that you need to publish any SPF at all > - MUST send mail that has DKIM signatures that produce a >DKIM-Authenticated identifier (to configure DKIM for DMARC) >(5.1.2) and that is backwards as well >The section 5.3.3 is not very clear that it requiers both SPF and >DKIM, I don't think that it has any such requirement -- and that is a good thing. Requiring SPF, rather than tolerating it, would not make this a useful document. >It seems to bit useless to say that to use xxx you MUST do >xxx :-) that I do agree with - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZ1ADRN2nQQHFxEViEQIkdQCfdAh9Fw0P92a4GhZBp5EbA1X8AtwAoOct A2nvQ+3wBRDSfgg0ODkfTO+Z =vpwe -END PGP SIGNATURE- ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Secdir last call review of draft-ietf-dmarc-dmarcbis-36
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <10f5d0b0-f1f1-49e7-a0c9-db745618f...@cs.tcd.ie>, Stephen Farrell writes >I'm not asking that SPF be banished, (none of us are good at going >back and deleting RRs we wish we'd forgotten:-), but more that some >domain owner/sender could indicate via DMARC to receivers that they >think SPF is no longer good enough by itself, in their opinion, for >email claiming to be from them (the sender). If you use "?" as a modifier to ranges within your SPF record then it will match (and prevent further processing) but it will not count as a pass towards DMARC. Some people see this as being preferable to eschewing having any SPF record at all because (a) Google (unwisely in my view) say you should have one if you want to deliver to them and (b) some small mailbox providers believe in the value of SPF to do early stage filtering of mailflows and may penalise your domain for not having any SPF at all. ((I roughly summarise what was discussed in the WG)) - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZ0hFRt2nQQHFxEViEQJ03ACg9RJJIHqlav/JcK9JBItjPTRhuzEAoMSd kTjXLu8C8XnmpItO148lFWx+ =Beqy -END PGP SIGNATURE- ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Proposed text for Indirect Mail Flows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >My core observation is that: >"SPF and DKIM can only indicate the original authentication state of >the message when the test is based on the state of the message at >origination." >Are you taking issue with this problem statement, or simply taking issue >because the solution to the problem is difficult? no, I was only drawing attention to various issues in your working thereafter ... but since you ask, and since SPF says nothing about the content of a message then it hardly attests to its original "state", it merely hints at its provenance >From my reading of the DKIM2 plan, they accept my problem statement and are >intending to solve the missing information problem by requiring >documentation of message state at each hop, and mitigate the trust problems >by adding stronger signatures at each hop. the last part of that paragraph is correct ... but there's a bit more to it than just blindly adding signatures >Assigning a DKIM signature to a server can be done if one assumes that DKIM >signatures will be added as trace fields. that is what RFC6376 says SHOULD happen >This is commonly the case, >especially when added by an outbound gateway service. So it is pretty >easy to tell whether a signature was added by a gateway service or the >originator. assuming no re-ordering and the correct addition of Received: trace fields then yes, otherwise no >My implementation of a solution may not be robust enough to meet standards >track criteria, but the problem that creates the solution needs to be >clearly documented, and the general nature of a solution should be >sketched. Do you have a problem with that? I think you should pay more attention to DKIM2 and less to trying to leverage manual methods (and/or those that require Received headers to be parsed) into DMARCbis. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZzJiq92nQQHFxEViEQJDdwCePvbnpHyuGhT39J70lesDESfrPnsAn1YI 5aWj+lT5rNBQPjmWCt46NZPd =JfRX -END PGP SIGNATURE- ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Proposed text for Indirect Mail Flows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >Outbound gateways typically increase the perceived message authentication >state. This can occur: > >· Because the outbound gateway organization is included in the Mail >>From domain’s SPF records, or I don't see how you can tell that is the case except in special circumstances. >Authentication using login credentials should be >documented using the protocol data in the Received header field and using >an ARC Set with an AUTH=PASS term in the ARC-Authentication-Results header >field. assuming that is a SHOULD, is it appropriate for this document to mandate the use of an experimental protocol ? > Authentication using trusted IP should be verifiable by SPF, >when applied to the IP address in the Received field which documents >handoff from client organization to Outbound Gateway organization. That sentence implies that the use of many SPF macros is no longer to be endorsed (which is fine by me, but doubtless not what you intend) > For >similar reasons, DKIM signatures should be applied by the originating >organization and placed in the Trace fields. earlier you said that it was OK for an outgoing gateway to do that. I think you SHOULD make up your mind. > A DKIM signature added by >the Outbound Gateway organization has a lower trust value because it does >not prove that the handoff between client and gateway organizations was >authenticated. ... and you revisit it with a different point of view. I expect what you want to say is that if a gateway applies a DKIM signature on behalf of a client then it MUST assure itself that the mail is genuine. BTW I am not sure how you can tell who applied a DKIM signature or when. >Forwarding always causes loss of SPF authentication for purposes of >DMARC. nope ... some people (unwisely perhaps) have very widely cast SPF >Forwarding falls into two main groups: > >· Simple forwarders transmit a general mail stream to a single >alternate recipient. DKIM signatures are usually preserved, but not all >messages will have DKIM signatures. As a result, a significant portion of >the received mail stream will appear to be unauthenticated. > >· Mailing lists transmit accepted message to a list of >subscribers. The list typically adds content to the message subject, >message body, or both.Since it is a forwarder, SPF authentication is >lost. Because it changes the signed content, DKIM authentication is also >lost. Consequently, content-altering mailing list messages appear to lack >any authentication. "Alumni" forwarders send to single recipients, but many alter the message... also some mailing lists go out of their way not to break DKIM signatures. So there's four groups. >To promote favorable consideration, forwarders should apply >an ARC set to forwarded messages. again you have a SHOULD for an experimental protocol - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZzHuot2nQQHFxEViEQKEugCeJBFXm5DXHjC6ZKEk9ZBtR72fStIAn2xu D5Tx/iYz1zWD9T1nlvrJ7MGd =WPF5 -END PGP SIGNATURE- ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Sender Authentication for Indirect Mail Flows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >SPF is designed for clarity I am not addressing your comments on DKIM in this response >for the situation where a message is submitted directly from the >originating organization to the final recipient organization, and the SPF >record confirms that the source IP address is an authorized message >origination server for that specific domain. I agree with that [snip] >The goal of this process is to walk backward through the Received chain to >find the first organization to handle the message, after excluding client >connections. [snip the details of the examination of the Received chain] >Upon completion of this data collection, the originating Mail From domain >may be uncertain, but should be constrained to no more than two values. all very well .. but what this does not do is to demonstrate in any way that the body of the message as received after it has been handled by intermediaries bears any relationship whatsoever to what was initially sent. Additionally, competent forgery of Received header fields (which I would agree is beyond some people) means that you cannot even be certain that the message took the alleged first hop That's why doing the sort of analysis you set out is not attempted by mail receivers (present company perhaps excepted) apart from occasional one-off efforts to attempt to determine "what on earth is going on" - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZx+MCd2nQQHFxEViEQLKYQCfSRc7Y7bp5l5v9yZQtSRwxEmqPagAoMQf 968arKFgGdxfUtU/Zg/u0cOK =UY9B -END PGP SIGNATURE- ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: What do do with ARC, Re: Discussion Thread
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <26397.38204.564597.374...@fireball.acr.fi>, Tero Kivinen writes >Richard Clayton writes: > >> One of the aims of DKIM2 is to make ARC unnecessary, and in particular >> to ensure that cases where an intermediate system must be trusted relate >> only to improving your heuristics which detect DKIM-replay or where you >> have a contractual relationship with that intermediary. > >I have not checked out DKIM2, but I am wondering how it plans to solve those two statements are clearly connected ... the published draft is a fairly straightforward read since it concentrates on the issues and outlines the solutions <https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motivation> >the ARC trust problem, i.e., how DKIM2 will solve the situation that >someone in the middle changes the email and I assume in DKIM2 it will >sign that modification, but how does the final recipient know it >should trust that party in the middle to do those changes? by undoing the changes and checking the original signature ... it's not actually necessary to check the signature on the undo instructions (we're trying to reduce the amount of crypto you do) since all that matters is whether or not they work. >I.e., even if DKIM2 allows me to recover the orignal email and know >what changes are done, it does not help me to solve the issue that I >do not know if those changes were malious or not. you're correct ... that is not (and IMNSHO cannot) be addressed. We did discuss whether it was possible to limit changes in such a way that you could not add some HTML (say) which hid the original post and replaced it with something else. It did not seem possible to be that restrictive and support what legitimate mailing lists do today. >We can solve that issue in the same way we solve that in ARC, i.e., >recipient will know whether such changes should be allowed by the >intermediary because it has set up or approved that intermediary. I >think this will work, but some other people seemed to say it can't >work as it requires final recipient to understand the issue... The problem with ARC is that you have to trust the intermediary is documenting what they received and not inventing a message and lying about its provenance. Trusting MAGY (Microsoft, Apple, Google, Yahoo) the IETF and the Harvard alumni forwarder is probably OK. After that (and possibly even before) opinions start to vary. Yes in DKIM2 you may discover that an alteration was malicious, but at least it will be crystal clear (once, for forensic purposes you check every signature to hand) which entity should be blocked henceforth. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZx49wt2nQQHFxEViEQJXRQCgg2WNG87DO8C8Lx8RiEX73rVxCcgAoMQ2 iX1Ht6z0MkLrLzX5uhsdwDGm =sc/F -END PGP SIGNATURE- ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: What do do with ARC, Re: Discussion Thread
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , John R Levine writes >On Fri, 25 Oct 2024, Murray S. Kucherawy wrote: >> If we agree that ARC is stable and valuable enough to move to the standards >> track, as Tero suggested, then that can be the WG's next order of business, >> but please don't let that debate slow down the main document's progress. > >I don't think it is. The same people who invented ARC are now working on >DKIM2, using what we learned about ARC, and I expect that once DKIM2 is >implemented we'll all forget about ARC. > >Since ARC is an IETF experiment, once DKIM2 is further along and it's >clearer what it does differently from ARC, it's worth a short followup to >8617 to say what we learned. One of the aims of DKIM2 is to make ARC unnecessary, and in particular to ensure that cases where an intermediate system must be trusted relate only to improving your heuristics which detect DKIM-replay or where you have a contractual relationship with that intermediary. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZx0oUd2nQQHFxEViEQLptgCffkZavOw/B/RrAy+8bru3wU046V8An1XU jpWBtSusp28C/es7P88f6IP4 =BpSK -END PGP SIGNATURE- ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: DKIM upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >A DKIM signature acts like a notary public, "This person, who is >well known to me, can be reliably associated with this document." no it doesn't -- it says ... I (as identified by this key) had sight of this email and was able to alter it >Signing works for DMARC only when the DKIM signer has actually >validated the entity before adding the signature. signing works for DMARC because of alignment ... nothing else >I know of no discussion >about how a gateway authenticates its clients and how an evaluator >knows that the signature was applied to an authenticated message. that's outwith the DKIM/DMARC model >This is relevant for at least Outlook.com. It does not enforce SPF >on incoming messages, but does assume that the incoming identity is >valid. It then adds a signature for the purported client, using >either ".onmicrosoft.com" or the actual client domain, >depending on the client's DNS configuration. This can produce >false DMARC Pass, sometimes with Dual Authentication. This attack >strategy has been observed in the wild. there is a great deal of mail coming from large systems which has a DMARC pass and does not actually come from where it purports to... [snip] >More generally, a message should only be considered DMARC-validated >if it can be validated at every organization change. There are >many obstacles to making that determination. ARC is clearly part >of the solution. I would agree that ARC is required (along with trust in the entity that added the ARC headers) when messages have been altered since they were originally created... I don't think it is a general solution to dealing with the failings of SPF - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZuLdLt2nQQHFxEViEQJwzwCdGM3lF3Br3mQuBjm5gLD4PiFlpfQAoIW9 FZBlgu8Q/9ihbpf+UOACE1gQ =IJQu -END PGP SIGNATURE- ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: The null sender inconsistency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >I would be happy to have you or anyone else explain to me >(a) What data indicates that a non-trivial number of servers have >SPF policies on their host name, and > (b) How the answer to that lookup provides information useful to >an evaluation decision. I looked at the data from $DAYJOB$ for last Wednesday UTC (a typical day I believe) For email with a null "MAIL FROM" (which includes a certain amount of spam as well as delivery status reports ...) I see dkim fail, spf fail: 11% dkim fail, spf pass:6% dkim pass, spf fail: 14% dkim pass, spf pass: 69% $DAYJOB$ is coy about absolute numbers but the smallest category there is more than 10 million and less than 100 million messages. When I look at the spf=pass results I see more than 650,000 unique EHLO strings. I think that qualifies as non-trivial. Evaluation decisions at $DAYJOB$ are very complex indeed; but that 11% will not be an issue RSN (because of "no auth no entry" policies) YMMV ... but I would be interested in learning what sort of volume you are drawing conclusions from. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZmXmrd2nQQHFxEViEQJi/QCgqBl0/6ll/WSu+KKt7qNzE8LPJBAAoM6W 4xmGfD6kE8ikBoD87vv1dvgq =wD4z -END PGP SIGNATURE- ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: The null sender inconsistency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >Here is an example of the real problem: > >Example.com is hosted on Outlook.com > >The user's mailbox is full, so so hopefully you get a 4xx or 5xx to that effect and your own server tells you of the issue, but playing along ... >I get a bounce message with these >characteristics: >From: jane.sm...@example.com >MailFrom: >Helo: servername.protection.outlook.com are you sure that you don't get a bounce message from mailer-dae...@outlook.com ? which would of course be authenticated just fine >How does it help my evaluation to do an SPF test on the HELO name? because you want to follow the spec ? - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZmLCst2nQQHFxEViEQKpbgCfTqSzAW9+1FewlGNIXmEP8pDSm5wAoMK+ lC5tvnUIqXFgq6Q8DzRPmQUC =ApAS -END PGP SIGNATURE- ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: Proxy signatures to combat SPF upgrade?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >Google applies annotation signatures from .. >gappsstmpt.com, with periods replaced in the domain name. >Microsoft applies proxy signatures from .onmicrosoft.com pretty much every ESP adds a DKIM signature of their own ... it will not in general be aligned, but the DMARC reports will provide useful info >If, as I am hoping, the signature indicates that the message has been >authenticated to the indicated domain, then it provides a defense against >SPF upgrade attacks. Evaluators can require that messages from the >hosting service have a domain or proxy signature. since the "proxy signature" has an ESP specific (and perhaps hard to discern) linkage to the RFC5322 From I don't think this gains you very much. In practice ALL messages from the hosting service servers will have a DKIM signature applied, it's just hard to be sure how it is related to the actual mail flow ARC at least makes the provenance of the email that has been relayed to you rather more clear. > Messages which are from >the hosting service, but have neither a domain signature nor a proxy >signature, are not authenticated, even if they pass SPF. that's a way of saying "ignore SPF if no DKIM at all". >Is this worth standardizing as a best practice (in a future document)? Since the WG declined to provide an indicator for "ignore SPF when there is a valid aligned DKIM signature" I doubt this has much chance of widespread approval, let alone acceptance as a Best Practice. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZmLBFd2nQQHFxEViEQJpagCgpgHc8nzolRYGvb4a/6jECP9ToFgAoKcm 5DXi3hQL99414v1KjchG/iNQ =r7CH -END PGP SIGNATURE- ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: The null sender inconsistency
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message <20240603104545.8DB7A8C84B2F@ary.local>, John Levine
writes
>It appears that Richard Clayton said:
>>You will need to say EHLO with a domain name that aligns with the From:
>>if you cannot manage that then DKIM is your only way to get your bounce
>>message to have a DMARC pass
>
>Now that I look at it, RFC 7489 says ambiguously in section 3.1.2 that
>the HELO can be used to "fake" (quotes in the original) a domain for
>alignment, while the current draft says in sec 4.4.2 "DMARC relies
>solely on SPF validation of the MAIL FROM identity."
the current text is better and far more precise (though it does rely on
the way in which RFC7208 is written)
>I don't remember the origin of this change. I don't feel strongly
>either way whether to use the HELO but I would like to be sure
>it's deliberate.
It is NOT "using the HELO identity" it is using the "MAIL FROM identity"
which is specially defined to be something other than what is in the
5321 MAIL command for the special case when it would otherwise be null
>What do existing DMARC libraries do?
for OpenDMARC, so far as I can see, the right thing
ret = opendmarc_spf2_find_mailfrom_domain(ctx, mail_from_domain,
mfrom, sizeof mfrom, used_mfrom);
if (ret != 0 || *used_mfrom == FALSE)
{
(void) strlcpy(helo, helo_domain, sizeof helo);
SPF_request_set_helo_dom(ctx->spf_request, helo);
}
Now one might observe that a bad person might proceed as follows
HELO financialcompany.com
MAIL FROM: <>
RCPT TO:
DATA
From: honestly-its...@financialcompany.com
Subject: click me
http://verybad.example2.com
.
QUIT
but that would just serves the financial company right for providing an
SPF record in the first place (or not adding the syntax to say "heres an
SPF record but ignore it")
- --
richard Richard Clayton
Those who would give up essential Liberty, to purchase aBenjamin
little temporary Safety, deserve neither Liberty nor Safety.Franklin
-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1
iQA/AwUBZl216t2nQQHFxEViEQKUFQCdHGijKmoW3iijwBkFw0ppNviR508AnjMF
LtCG8MdUak+fP3NvPeVQRniQ
=3LC6
-END PGP SIGNATURE-
___
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: The null sender inconsistency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >Richard, you miss my point. I know what RFC 7208 says to do with null >sender, but we rightly ignore it for DMARC purposes. I think you should go back to RFC7208, specifically #2.4 where it specifically says that when the RFC5321 MAIL FROM string is null (as in bounce messages) then the "MAIL FROM" identity is defined to be postmaster@ the domain in the RFC55321 EHLO/HELO command The current DMARCbis document is clear that the HELO identity is to be ignored... it might be useful to paraphrase #2.4 but I can see the argument for avoiding confusion if the paraphrase was subtly different >SPF Helo is one of at least 5 ways to validate the HELO name. This is not a question of validation, DMARC is all about alignment You will need to say EHLO with a domain name that aligns with the From: if you cannot manage that then DKIM is your only way to get your bounce message to have a DMARC pass - -- richard Richard Clayton Those who would give up essential Liberty, to purchase aBenjamin little temporary Safety, deserve neither Liberty nor Safety.Franklin -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZl1PWd2nQQHFxEViEQIRNgCfTNdEdmxZOyA3e3kvaYTZBmFCDAgAniso XF+0hJOncqW29BNONctiULYI =gFl4 -END PGP SIGNATURE- ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
[dmarc-ietf] Re: The null sender inconsistency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >Consider the case of an environment with a single server, properly >configured with SPF but without DKIM: >* Original messages from this server are considered authenticated > based on SPF Pass with alignment, but >* Bounce messages from this server are considered unauthenticated > because messages with a null sender require DKIM. If MAIL FROM is null, SPF uses the domain in the EHLO You should ensure you have an SPF result for that (noting that it may be a subdomain and SPF does not have any concept of authoritative domains) - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZlcfVN2nQQHFxEViEQJPLACgtedq9ao4h9sQPDY8aUCL81AvF1MAn1Yb GamGjDijukTOmA71+iw6mhNw =iznx -END PGP SIGNATURE- ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Seth Blank
writes
>Some Mail Receiver architectures implement SPF in advance of any
>DMARC operations. This means that an SPF hard fail ("-") prefix on
>a sender's SPF mechanism, such as "-all", could cause that
>rejection to go into effect early in handling, causing message
>rejection before any DMARC processing takes place, and DKIM has a
>chance to validate the message instead of SPF. Operators choosing
>to use "-all" to terminate SPF records should be aware of this.
I understood what this said thus far ... but I wonder what it is doing
in a document about DMARC. Some architectures may reject email from
IPs listed in the PBL ... again nothing to do with DMARC. This isn't a
document on how to improve deliverability is it ?
>Since DMARC only relies on an SPF pass, all failures are treated
>equally.
This makes less sense ... I think you mean something like, when
considering whether or not SPF has passed, the type of failure is
irrelevant to DMARC (since clearly DMARC does not even require SPF be
specified at all...)
>Therefore, it is considered best practice when using SPF
>in a DMARC context for domains that send email to end records with
>a soft fail ("~" / "~all").
I don't see why it is Best Practice ... it rather depends what you wish
to achieve doesn't it ?
>Could this work with simply the removal of the last sentence
>covering best practice?
the more that was removed the better
- --
richard Richard Clayton
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1
iQA/AwUBZgnjd92nQQHFxEViEQIkVgCeIQIwiTYO3rZbipFmFTNUn8BpmFEAn2lc
a+iTWfEDnYmwReECYdekhMkO
=IR3+
-END PGP SIGNATURE-
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Fwd: The sad state of SPF: research just presented at NDSS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Scott Kitterman writes >Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send >mail for anything other than their own domains. ESP customers, don't use ESPs >that do this. leaving aside how practical this advice may be and how it would be possible for anyone to accurately, a priori, determine the ESPs abilities to control their sending arrangements ... ... there's also "clouds" -- where senders are documenting the entirety of the cloud's IP space as being a potential sending location. Although it might be possible to have DNS records track actual usage as resources are spun up and down there's obvious issues around caching. of course we might say not to use clouds that do that ... but the "that do that" part of the sentence would be superfluous - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZfCS692nQQHFxEViEQJ3qwCfTxLBZW+aOgmaGtTBdMsaspMinakAniaz 2BW+OEMvrpnjG1aBhwEDSzgu =xi5C -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] A possible point for SPF advice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Todd Herr writes >In a world in which two of the largest mailbox providers (Google >and Yahoo) are requiring SPF authentication Yahoo is not, AIUI, requiring SPF authentication ... the requirement is written to be rather more subtle than that (precisely to allow "?") Google should speak for themselves - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZedMcN2nQQHFxEViEQLYwQCfXTyMewmkeliIDuQBSwl1sQNPapAAniYX sEpKtevCS21leUAdIgyH8gAL =d2SU -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Break SPF response: DKIM Only
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >I am surprised at the lack of feedback about Barry's research link. > It is a devastating attack on our ability to trust SPF when >shared infrastructure is involved. those of us who look at email logs (at scale) have long been aware that major brands with shared infrastructure SPF settings can be trivially spoofed (and what's more they ARE trivially spoofed pretty much all the time) Since there's lots of other ways of constructing convincing phish (you only really need a good Subject header field and the right logo) it is just one approach for the bad guys among many. > As a result of that document, I >have switched camps and believe that we MUST provide a DKIM-only >option for DMARC. when this last came up the people who like SPF argued that the fix was for people to set their SPF records so that they did not actually count towards a DMARC pass (using the ? mechanism) -- and they seemed to carry the day (or we all just got too tired to argue for something simpler) >The proposed workaround, of using a "?" modifier to force SPF >Neutral instead of Pass, seems to lack both awareness and >implementation, since it was not even mentioned in the research >document as a mitigation. I'm assuming that when I have time to read the latest version of the document then that will have been written down so as to guide people. If not then that should be fixed ASAP. But I'm not surprised that the researchers had not come across it, or if they did they did not understand exactly what it did -- you may recall that I did not either first time around. - -- richard Richard Clayton They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. Benjamin Franklin -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZeELXd2nQQHFxEViEQJvegCgvhjdXl2lp6II7F81aZQl5LzkVpIAoNrr If2g48lRUyad+MqVbgXasMcp =A46e -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Non-technician's idea for DMARC improvement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Ted Wham writes >any other source of email that fails authentication is definitionally >unauthorized. So why not alert the senders of these bad messages that they >might >have an open relay that has been hijacked for spam purposes by sending a >message >to the Abuse alias at the originating domain for failed messages? because most bad email that fails DMARC is sent from machines where the user is a bad person who intended their bad action rather than from an "open relay". Sending email to the bad person (or to the complicit company that sold them the resources) is an exercise in futility Open relays are rare these days (I'd not call the inability of Microsoft to check that their users are entitled to use From address strings an open relay). >In >fact, since not every sending domain has implemented an Abuse alias that's news to me ... did you mean that you imagine that the benefical user of the IP address has implemented a working abuse alias ?? (which is again not really the case, leave alone that action is taken) >, those >exception messages that bounce could actually be used in the receiving >domain's >proprietary email reputation calculations. In general the bad guys are way better at configuring systems to appear legit than the long tail of good guys are. Real world reputation systems try hard to take that into account - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZbWijN2nQQHFxEViEQIZWQCgm0G34L/DzgQIUnt1HcXFzX+cwlwAoJsX hcOLbG6pBSIsfROS1v6qcPDl =YnRm -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Server Controls
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >Our document needs a section on server controls. what is a "server" ? did you mean an MTA ?? >Impersonation prevention begins with enrollment controls that prevent >service accounts from being created using false identities. Many countries have controls on Internet access that require Government issued identification ... and many take the view that this is inappropriate. > I do not >perceive this as a significant problem, but the NIST documents on digital >identity are a very good resource and could be referenced. I think you may have the wrong mailing list. I don't believe DMARC has any relevance to (or interest in) identifying individual email senders rather than detecting unauthorised use of domains. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZVNipd2nQQHFxEViEQKdUACgr9/X23quPDNpMPDc+ewuAvHg0coAn1Qp ZwwQWcSZajg40q4MOi8ajZuH =3GOC -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <564e68e5-c121-45f1-afef-3770b7377...@tana.it>, Alessandro Vesely writes >On Sun 12/Nov/2023 09:26:32 +0100 Richard Clayton wrote: >> In message <55dc7b67-e48a-4eb3-9cdc-4e4319cc7...@marmot-tech.com>, Neil >> AIUI, Yahoo only sends failure reports when there is a formal agreement >> in place (which addresses data protection and privacy issues). > > >That would depend on I think you might reasonably assume that Yahoo's lawyers have paid attention to the complexity inherent in providing the data I am less certain that some of the other senders of failure reports (mainly Chinese in my recent experience) are in jurisdictions that have to concentrate so much The substantive point for the WG is that continuing to standardise the format of these reports remains useful, even if many people will never see an example. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZVDs7N2nQQHFxEViEQKK0gCfXFDcrH8VQ1NJm47seMClIUzM0rAAoKe8 ahpl1WdS1Zayhrd3Nv8ussKJ =7n4z -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <55dc7b67-e48a-4eb3-9cdc-4e4319cc7...@marmot-tech.com>, Neil Anuskiewicz writes >I have a feeling the die is cast for failure reports from MBPs. I’m >curious to learn if they sent legit failures, which has scared off >the major MBPs except for Yahoo. AIUI, Yahoo only sends failure reports when there is a formal agreement in place (which addresses data protection and privacy issues). Yahoo also operates an FBL (for which you need to apply)... DKIM passes are required for this data to be sent. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZVCMON2nQQHFxEViEQJm5gCg/NAKLeMpPvVwuf/duV3eI7ngjkUAoLoV gEI41kPWQq67WD7a0FczLAkj =m0r1 -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >By contrast, the new tag cannot be effective until DMARCbis is published >and filtering software updated. This involves years. Hard to say ... there is some self-interest here in having shiny new features (such as they are) and it is argued that pretty much everyone uses one of a small number of libraries so only a small number of programmers need to stay up late to make updating possible Although people did not update software very often 20 years back, fear of compromises (and the widespread existence of such compromises) means that updating cycles are far faster than they used to be. >Even then, domain >owners will never have confidence that the new token support has been >implemented by all recipient evaluators. That of course was one of the reasons for having a version bump ... but there was no consensus for that. However, careful reading of reports will tell you whether those evaluators who send reports have updated, and you can take a view from those - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZT8VyN2nQQHFxEViEQI4KwCgoq/AfjOOaln5Gz+lGTdC1w2jHG8AoNvY ojMIxIPArJ94MmA8MhS1tJ0Z =bOmC -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >* auth=DKIMOnly requires that the domain owner have high confidence > that every message source is applying DKIM signatures. which of course the reporting mechanism allows them to acquire - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZT6d+N2nQQHFxEViEQJCDQCgi6nTZzBMtD3IsCneeBhfi9yncr4An1Rw XWnnTNQEzFoispkq3McuQGgw =PlmH -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Wei Chuang writes >I don't think the SPF '?' qualifier approach works because as Richard >Clayton said earlier of RFC7208 "Sender Policy Framework (SPF) for >Authorizing Use of Domains in Email, Version 1" section 8.2 which says: > >A "neutral" result MUST be treated exactly like the "none" result; >the distinction exists only for informational purposes. Scott pointed out that I had not understood it correctly ... when you run a matching sending IP against a "?" mechanism then you get "neutral" which you are obliged to treat as "none". But you stop there. When you run a non-matching sending IP against that same "?" mechanism then you get a "fail" so you keep on going to look at all the other mechanisms (which also all fail) and eventually (in practice) reach "-all" or "~all" at the end of the record. hence you can still use SPF to filter out the non-starters, but you don't get any warm and fuzzy feeling from the pass... So the SPF publisher they can either publish "?" information or nothing at all -- and the _only_ reason for doing the former is to help with an initial filtering mechanism at sites that use SPF for that purpose. >If it happens to work, it's likely an implementation detail not >standardized across the ecosystem and may change. You're right that there's no way of knowing whether the people who are currently paying a lot of attention to SPF (and less so to DKIM) are going to make poorer decisions when what used to be an SPF pass now becomes a "none" result. Allowing DKIM-only to be specified in DMARC allows people to still publish SPF records that yield a pass (thus generating a (possibly mistaken) warm and fuzzy feeling in some quarters ...) >Moreover it will be >highly confusing to those outside of those with connection to the >knowledgeable few. That broader community depends on the literal >interpretation of the RFC. That's what still confuses me about the objections to the proposal to explicitly allow people to say "DKIM only". Yes I get that it adds a little bit to the text of the document and requires a bit more code to parse the new parameter and hence you can object on the basis of "complexity" -- but it does seem simpler to understand the stricture "ignore SPF" than grok the necessity to alter SPF records to use a complex-to-understand mechanism which may degrade some deliverability. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZT5hO92nQQHFxEViEQIM0gCfU3ZV3bEfi9kAfEFThr+30GJWqFsAoI2z xh0KGaaD5mELlRimHgVMwRDu =HmrF -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <3316620.Pp0j0xxFaF@localhost>, Scott Kitterman writes >What's your plan for when easily getting a DMARC pass due to bad SPF records >doesn't work anymore, so the bad guys focus more on DKIM replay? At $DAYJOB$, DKIM replay is simply not an issue any more ... caching DKIM values and blocking more than N emails with the same value (whilst of course exempting mailing lists) has proved extremely effective for several years now. Paying attention to the (sometimes inferred) age of a signature is also important for reducing the opportunity for replay, viz: it would be a Good Thing for senders to set appropriately short expire times. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZT0oMN2nQQHFxEViEQLj2wCg9sCc40wN2UuXY4/Ms7TuMtt/QlAAn1/V kAUjrpkVAoDkoMlPbVsn1I4X =tMcf -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <6bb2871c-da84-42ad-bae1-7b4828b0f...@tana.it>, Alessandro Vesely writes >On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote: >> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely wrote: >>>If we add the feature, we should in any case exemplify how to fix SPF, >>>saying >that doing so is safer, at least until all DMARC software has acquired the new >feature. As the addition would be understood as a response to the known >vulnerability, it will likely be spread. >>> >> What do we know now that we didn't know the last time we decided not to go >DKIM only? I'd argue there's nothing and endless relitigation of issues like >this is making it impossible to actually accomplish what we're chartered to >accomplish. > >You're the only one strongly opposing the idea, AFAICS, and I still don't know >why. The only reason that I think that SPF results are of any value at all (and hence we should go with a "DKIM pass only" marker for those who need it, rather than just wiping SPF from the document) is because some people have argued that a SPF only approach is of value to them -- they can do a sanity check on the sending IP, and they then use other methods to decide whether they like the email. Their server their choice... ... Scott has been arguing (AIUI) that people who want a DKIM only situation should add the "?" qualifier to relevant SPF mechanisms. This will produce a "neutral" result and hence there will not be a SPF pass for DMARC to consider. This is all very well, but I have been reading RFC7208 "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1" (which we should note is authored by S Kitterman) and in particular looking at #8.2 which says: A "neutral" result MUST be treated exactly like the "none" result; the distinction exists only for informational purposes. that is (and Scott can correct me if I misunderstand), that people using SPF in an RFC compliant manner (which the libraries they use will undoubtedly do) are effectively obliged to ignore any mechanism with a "?" qualifier. BTW the same text appears in RFC4408 #2.5.2. so this has always been the case. That is -- using "?" means that the SPF information will not only be disregarded for DMARC purposes but also for SPF purposes as well. In my view that makes promoting the use of "?" a non-starter. So if we want to allow the people who value SPF to continue to have records they can use whilst addressing the reality that such records are often, necessarily, far too wide to provide real authentication, we must have a way in DMARC of saying "only consider DKIM". - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZT0fit2nQQHFxEViEQJiVgCg/QCfb5OmzSnGjXMiiTM7sPiepQcAniMF q/BTNqNrSy8NfpE0xUvnktYF =AHm6 -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Dmarcbis way forward
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Murray S. Kucherawy writes >Do you really want to be pushing that information and decision >burden onto users? How many of them will understand versus >ignoring it and just blundering ahead? I think that depends how clearly the information is presented >The operator is making the decision to publish or enforce, not the >user. Looking at $DAYJOB$ logs for this week I see a shade under 300 people who are participating in IETF working groups using p=reject addresses. I believe they have made an informed decision as to what email address they will use and have not "blundered" at all (in fact a couple look as if they have set up the email address specially in order to participate. (that was easy to count and it seemed relevant to do so, counting other mailing lists is complex) There are 5 or so in this group... Surely you are not going to ask them to leave. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase aBenjamin little temporary Safety, deserve neither Liberty nor Safety.Franklin -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZTlDEd2nQQHFxEViEQLOowCg0paP4kt9wbajuJ4tKO+uY/G6BoYAoJry +RxYXsHtHSMV+KgNQP87805W =zUUT -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Dmarcbis way forward
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Brotman, Alex writes >+1 SHOULD NOT If there is not going to be a consensus for just a discussion of the issue (which I would prefer) then my view, obviously is that SHOULD NOT is to be preferred to MUST NOT The relevant bit of Barry's text is I believe: It is therefore critical that domains that host users who might post messages to mailing lists SHOULD NOT publish p=reject. Domains that choose to publish p=reject SHOULD implement policies that their users not post to Internet mailing lists. but I am concerned about the second sentence. It would be perfectly possible at $DAYJOB$ (where I help look after a number of domains with p=reject and a large number of users) to meet that SHOULD by blocking those users from sending to mailing lists. This would (a) be somewhat unpopular and (b) for many mailing lists which have implemented workarounds of various kinds completely unnecessary. So might I suggest a wording that captures what will actually happen in the real world Domains that choose to publish p=reject SHOULD inform the people using those domains of the issues that may arise if theu post to Internet mailing lists. I'd even live with a MUST for that second sentence :-) - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZTkxF92nQQHFxEViEQK63QCgyXe3+giXO9UlDA9jAC2T4E6kGeQAn3NC WoNnAF7y6HrECK9Y1kcdE1nd =iSip -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Scott Kitterman writes >>> My reading of the discussion is: >>> >>> 1. We did not have rough consensus to eliminate the use of SPF in DMARC. sadly so, it would have been the right thing to do >>> 2. We did not have rough consensus to complicate DMARC by having the >publishing domain specify authentication methods. hmm... it does seem to be the best way of addressing #1 >The purported use case is "my SPF is so awful you can't trust it and at the >same >time, so critical I still have to publish the record". I don't think that's a >real thing. there appear to be receivers who use SPF as a filtering mechanism to reject patently obvious forgeries -- and if SPF passes they then apply other mechanisms because they don't want to bother with DKIM (I've seen posts to this effect -- their customers, their funeral) not having an SPF record at all would mean that these receivers would not be able to do that filtering (and the lack of SPF might adversely affect various heuristics for determining how email should be treated) viz: there is an edge case for senders to continue to publish SPF even when it almost useless (it stops people forging mail from a different cloud, but not from the one that they use) if that is so, then senders need to be able to tell all the receivers who do believe in the value of DKIM (and there are a lot of those) "take no notice of my SPF record" ... so DMARCbis should support that Note that if BIMI is involved the SPF will be ignored anyway (and the documentation might even say that RSN) >If your SPF is unreliable, fix it or delete it. Not a DMARC problem. senders using clouds to spin up and spin down resources depending on demand will struggle to "fix it" ... that's why it was so widely drawn in the first place. Senders using shared IPs at ESPs are also not in a position to "fix it" -- they can only hope that the ESP correctly polices what is being sent by each particular customer. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZTktx92nQQHFxEViEQLZfwCgrWwC2PLCvHV8I9aHLE5XVZLZGTQAnjar ThGQVjdL/8CrteVWGe3KaNTO =BqvR -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree Walk impact
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >So initially, I am asking for a compsrison between my results and >the data used to justify the asserted consensus. if you published the data (just the right hand side of relevant addresses is needed) we could check your working ... >Was 2% previuosly observed and judged acceptable? Were the >previous error rates judged acceptable because they were computed >using a different denominator definition? clearly if you get 10 messages from odd-domain and 10 messages from Google then you will see a different percentage than someone who gets 3 (or some days 0) messages from odd-domain and 100 from Google ... but provided odd-domain isn't just sending to you then any large mailbox provider should have seen enough mail to provide a sensible measure of the impact by counting domains not %age of overall mail. >With our present design, the necessary response to these errors is >for the domain owner to remove intermediate DMARC policies. that's strange ... isn't the intent of the new scheme to encourage subdomain owners to add them ! I do wonder if this is the PSL raising its ugly head again. A remarkable number of the people who have added entries have not understood how they now need to publish rather more DNS records than previously ... - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZSGUTN2nQQHFxEViEQKHpQCeP4SAEJFQbCG74hSpmKPugIWLWs0An2e5 DMtrmcDBziCPFM9PVB0Vx6dI =aCqk -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >The coverage problem is aggravated if we assume rational attackers. > With a plethora of domains available for impersonation, attackers >are least likely to use domains that are protected with p=reject. you have grasped it ... the rational attackers do not impersonate the protected domains, and the irrational attackers are blocked when they do; hence the domain is protected and users are not misled >Therefore the reference model implementation protects an evaluator >where attacks are least likely, and fails to protect an evaluator >where attacks are most likely. however DMARC protects end users who might act on emails that were spoofed to be from the domain that has been protected Ian Levy (then of NCSC here in the UK) in "Active Cyber Defence - One Year On" reported We have seen the number of messages spoofed from an @gov.uk address (for example, taxref...@gov.uk) fall consistently over 2017, suggesting that criminals are moving away from using them as fewer and fewer of them are delivered to end users. Across the 555 public sector email domains reporting to Mail Check, we are seeing an average of 44.1 million messages a month which fail verification, with a peak of 78.8 million in June. Of those, an average of 4.5 million are not delivered to the end users. The peak in June saw 30.3 million spoofed messages not delivered to end users. from which you will see that there are were a number of irrational attackers, but that the rational ones now found their task harder - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZQJiO92nQQHFxEViEQIQ/wCg3bMOOkwzlALOCiqSeyYat37sLPsAoMmY PQmhq6x7U/NYsa9/qa0geqQO =cwUs -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] pct flag, Some Gmail comments on DMARCbis version 28
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <20230910031142.48ebb5b5...@ary.qy>, John Levine writes >It's a lot better to set the TTL on your record to a few seconds, then >change it to p=reject, and see what you get back. If you're seeing a >flood of unexpexted rejections, quick flip it back to p=none until you >figure out how to fix the problem. A significant cost for DMARC (both in sending reports and indeed implementing DMARC more generally) is that DMARC records often have very short TTLs and hence they have to be continually re-fetched in order to determine their content -- both for deciding what policy has been requested and then where to send reports of disposition. At the billions scale it would be very helpful for TTLs (both for successfully fetched records and for NXDOMAIN) to be of the order of a week rather than a few minutes or hours (leave alone seconds) -- but people seem to get twitchy (for no really good reasons in my view given the general stability of these records) when I suggest ignoring the DNS server's TTL altogether and using 7.5 days instead. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZP228d2nQQHFxEViEQLQbgCcCtnm9ya/2crwUH19JXHky/MdHAYAn2Xr dGHsjdCl8mlU3EYBdxaYbsns =CxSq -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Interoperability sections
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >Does "Trusted Attestation" have any envisioned implementation other >than an ARC Set? yes ... you may have a relationship with another company which means that you trust them to do DMARC related checks on your behalf before they forward the email on to you. I am aware of very substantial email flows that operate in exactly this manner. not everything in email is open or based on IETF standards also not all forwarding is mailing lists - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZMede92nQQHFxEViEQIPGwCcDuLpBRPm0NyhHt60siQr+377R+IAoMv5 81177Ox2Fw3S/LM3xKxy1SJs =unKY -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Interoperability sections
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <55584702-38bb-31a3-e4b7-99efab189...@tana.it>, Alessandro Vesely writes >Section 8.6, *Interoperability Considerations* > >OLD > | It is therefore critical that receiving domains MUST NOT reject > | incoming messages solely on the basis of a p=reject policy by the > | sending domain. Receiving domains must use the DMARC policy as > | part of their disposition decision, along with other knowledge and > | analysis. > > >NEW > | It is therefore REQUIRED that receiving domains exempt from DMARC > | disposition messages forwarded by trusted third parties, either > | aliases or mailing lists, provided that forwarders are authenticated > | by a secure method. Receiving domains must seek methods to > | acknowledge forwarders' quality and grant trust where deserved. I think that wording is a better approach ... but the issue is not whether the forwarder is trusted per se, but whether it reports the origin of the email in a trusted manner and that origin leads one to believe that the DMARC failure is to be overlooked. A forwarder may have accumulated all the trust in the world, but if an authorised user is compromised and sends email From: exam...@paypal.com then PayPal's p=reject should be honoured. The second part of the paragraph is aspirational and can be omitted so: Receiving domains SHOULD exempt from DMARC disposition messages forwarded from third parties where there is a trusted attestation by the third party that the email met the requirements for a DMARC pass when it was received by them. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZMU5Rt2nQQHFxEViEQKXxwCcDLxrP46oAluJh5yRvkR3QkY36KUAn02X fnGnu8q4Mi6uPJI+Aox+CqU8 =hJTb -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Murray S. Kucherawy writes >Some of my IETF mentors (ahem) taught me some stuff about the use >of SHOULD [NOT] that have stuck with me, and I'm going to pressure >test this against that advice. Let's see how this goes. :-) > >"SHOULD" leaves the implementer with a choice. You really ought to >do what it says in the general case, but there might be >circumstances where you could deviate from that advice, with some >possible effect on interoperability. I noted that one of the earlier messages which endorsed MUST NOT said that of course some people might know better -- which is what I always understood SHOULD NOT was for ! > If you do that, it is >expected that you fully understand the possible impact you're about >to have on the Internet before proceeding. To that end, we like >the use of SHOULD [NOT] to be accompanied by some prose explaining >when one might deviate in this manner, such as an example of when >it might be okay to do so. not so much "OK" as "necessary". Yahoo's original statement (I'm prepared to name names rather than pussyfoot around this) on the deployment of p=reject is discussed here: https://wordtothewise.com/2014/04/yahoo-statement-dmarc-policy/ and I believe it is widely understood that it was particularly deployed to counter the "address book spammers" of the time. These bad guys originally persuaded people to open their email by forging it to appear to come from their friends (having compromised relevant address books). They then moved on to just using random identities from the same domain as the recipient. This led a great many Yahoo users to believe that a great many other Yahoo users had been compromised, leading to a significant loss of faith in the integrity of the platform. >Does anyone have such an example in mind that could be included >here? Specifically: Can we describe a scenario where (a) a sender >publishes p=reject (b) with users that post to lists (c) that the >community at large would be willing to accept/tolerate? So the example you seek might be phrased along the lines of when failing to set p=reject means that significant quantities of forged email will be delivered and this will cause damage. Personally (not a $DAYJOB$ opinion) I think SHOULD NOT is still too strong, mailing lists (and other forwarders that mangle email) have been coping with p=reject for nearly a decade -- so that trying (ineffectually in practice) to make their lives easier at this point is a snare and a delusion. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZKmTft2nQQHFxEViEQJ4zACfUiVCRzGjK68phKi73kl0kg0CKnAAnjAB ft3PPkV73wIPjvYs7tCjrCsm =EUgy -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >* The 5% with inconsistent results need further investigation. > Perhaps a server farm has one server that is generating wrong > signatures. more likely the email has been "fixed up" by a transport layer after the signature was calculated. Start by looking for patterns such as accented characters in the Subject header field or the RFC5322 From header field (where Unicode stand-alone accents have been amalgamated with the character they affect as a single glyph) or for unusual sets of spaces (where "invisible" Unicode values have been substituted) better yet of course get hold of the original email before it was signed and sent to you -- but spammers tend not to help you with that ! - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZIo7EN2nQQHFxEViEQLmKwCZAW3bqT5sWhDx6qr+WZ38maKfOl4AoMLT aM2bjkAMnzUEliPUKB1NW/ho =w9W/ -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <7f854d28-d3b5-fd00-4613-b8baa1217...@tana.it>, Alessandro Vesely writes >What I find nonsensical is to eliminate SPF in order to save DNS queries, at $DAYJOB$ (a large mailbox provider) SPF queries are limited to 15 ... since the prescribed limit of 10 was determined to cause too many SPF passes not to be found... > given >that we replaced local PSL lookups with a series of queries. We cannot do >that >and pretend that SPF is too expensive. the change here is not, I believe, 15 ... or even 10 (I think, counting quickly on my fingers, it's +3 -- and for the vast majority of cases +0) - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZIUeV92nQQHFxEViEQLzKgCfRotct0/P4e2sKJm0bGi/biVBF5gAnioH e8rlOpyGxUI3Y6+a4nQfCspM =nexz -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] PSD flag vs Version bump
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message <20230610210457.b4c22e924...@ary.qy>, John Levine writes >We have two of the largest mail operators in the world saying that if >they can't tell which org domain scheme domain expects, they won't >implement the tree walk. We have to do something or we are wasting our >time. Clarity is everything ... reducing system complexity matters as well. Removing the need to consult a (reasonably) current version of the PSL matters a great deal, because even when operating at the scale that you can have engineers (and further systems) monitoring for when this does not happen is complexity that one would wish to dispose of. ie the new tree walk is an improvement and not just because of the new features it provides. Domain owners can learn when the new treewalk is being used by consulting aggregate reports... domains that wish to use the features the new treewalk provides may, in the fullness of time, start reaching out to the recalcitrant. For example, if you are gov.uk and running a special DNS system to make the old approach provide some safety, you may want to turn that system off, but you can only do that once mailbox provides have changed over. Meantime the mailbox providers want to know if they are behind the curve in using the new tree walk... tracking the DMARC records they fetch (or looking at surveys by people who fetch and count them) will tell them if domain owners know that things have changed. Personally (and I am not writing on behalf of $DAYJOB$) I think that signal "I know things have changed and am setting things up accordingly" is most clearly sent by bumping the version number, rather than relying on other more subtle syntax changes. viz: the version number bump is a clear signal that domain owners know what is going on (and is really easy to explain to them). That signal tells mailbox providers which tree walk (and any other changes) to use and when it is clear that we're into the long tail of domain owners who have not heard the messaging then is the time to say "well the new tree walk makes no difference" and delete the old code, stop fetching the PSL and decommission the monitoring... the final step is to ignore version 1 records completely (and signal that in aggregate reports)... I foresee almost no enthusiasm for running two systems in parallel in perpetuity. Running the simpler __system__ is clearly better all round but I do think that the fact that there are changes should be signalled very clearly rather than deduced ... it will make the messaging to the masses rather than the cognoscenti so much simpler. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZIT54d2nQQHFxEViEQJweACg4lDlD2TSRG8FoV/cmRtGRnKwVvYAnRpi S+YOpSRfkBjQATjp3bmb0WXM =1EKf -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
