[dmarc-ietf] so long again
I came here wondering what ARC was which I got answered and for which I wrote a blog post saying that we should just give up on the mailing list problem. https://rip-van-webble.blogspot.com/2020/12/are-mailing-lists-toast.html The same crap that drove me away the last time is still raging on and I'm tired of getting singled out. I did however write a history of DKIM and SSP that some here might enjoy since DMARC is pretty much SSP. Mark and Murray have been giving me some insight to their back story which I'd encourage them to write up too. https://rip-van-webble.blogspot.com/2021/01/storing-asymmetric-keys-in-client.html Mike ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #1 - SPF alignment
In article you write: >On Tue 02/Feb/2021 20:13:42 +0100 John R Levine wrote: >> >> There is some commented out code to not pass a HELO result to DMARC, don't >> remember why I turned it off. > >Couldn't find the code you uncommented in. I'm not surprised. It's only in my MTA. >Apparently, OpenDMARC reads Authentication-Results: (or Received-SPF:) and >calls opendmarc_policy_store_spf() to save >the result it parsed. That way, the last value found is the one that will be >used. > >It seems that relies on upstream SPF filters writing a single SPF result. If >mfrom is given write its result, >otherwise write helo's. That behavior is presumably coded after DMARC's >idiosyncrasy. It would choke if applied to an >unskewed SPF filter's results. Is that what its milter does? Not surprised. >> It's existing practice and I see no reason to change it. > >Software changes all the time. If we change, ... Urrgh. There are still MTAs that haven't been updated from RFC 821. If you want a real standard, the closer you can make it to what the running code does, the most likely it will work. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #1 - SPF alignment
On Tue 02/Feb/2021 20:13:42 +0100 John R Levine wrote: There is some commented out code to not pass a HELO result to DMARC, don't remember why I turned it off. Couldn't find the code you uncommented in. Apparently, OpenDMARC reads Authentication-Results: (or Received-SPF:) and calls opendmarc_policy_store_spf() to save the result it parsed. That way, the last value found is the one that will be used. It seems that relies on upstream SPF filters writing a single SPF result. If mfrom is given write its result, otherwise write helo's. That behavior is presumably coded after DMARC's idiosyncrasy. It would choke if applied to an unskewed SPF filter's results. Again, I believe this is typical of what DMARC validators do. Yes. Here's an example by Google. You may note that the helo name reported in Received: must have resulted in an spf=pass, which is not reported: ARC-Authentication-Results: i=1; mx.google.com; spf=neutral (google.com: 62.94.243.226 is neither permitted nor denied by best guess record for domain of u...@fragolina.it) smtp.mailfrom=u...@fragolina.it; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=tana.it Return-Path: Received: from wmail.tana.it (wmail.tana.it. [62.94.243.226]) by mx.google.com with ESMTP id d18si1599313edu.101.2021.02.03.08.37.32 for ; Wed, 03 Feb 2021 08:38:57 -0800 (PST) It's existing practice and I see no reason to change it. Software changes all the time. If we change, this particular fix would probably be less noticeable than many other software bugs lurking amid the code. Indeed, you have to craft a message on purpose in order to have mfrom fail while helo pass (as the example above). We can even explicitly allow the existing behavior for historical reasons, if nobody recalls why the spec came out that way. However, please, let's not write a quirky spec. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Report bombing is a prolem, Forensic report loops are not
On Tue, 2 Feb 2021, Alessandro Vesely wrote: Whatever mechanisms are used, servers MUST contain provisions for detecting and stopping trivial loops. I can tell you from bitter experience that rate limiting is the *ONLY* reliable way to stop trivial loops. Whatever else you try, something will eventually change or delete the thing you try to use to recognize loops. As a concrete example, I get a lot of failure reports from antispamcloud.com which are not multipart/report and which software would not recognize as a failure report. Nonetheless, if they got into a reporting loop, it would be annoying, and rate limiting would stop them. Mailbombing in general is not a loop. Two report generators reporting each other's failure to authenticate a failure report /is/ a loop. Sometimes mailbombing is a loop, sometimes it isn't. If the loop is so slow that it doesn't trigger rate limits, it's not likely to be a practical problem. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #1 - SPF alignment
I believe that most code is validating the MailFrom parameter if it is supplied, and validating the HELO name only if MAILFROM is null. This is based mostly on the way SPF has been discussed over the last 15 years, coupled with the observed behavior of a limited number of product implementations.. If we are to argue that HELO and MAILFROM tests are interchangeable, we have to deal with the situation where the domains are different and the results are different.SPF has 7 possible results, so there are 49 possible combinations of these two tests, 42 of which are divergent. (If we factor in NXDOMAIN as a separate result, which even RFC 7208 says is probably appropriate for HELO, the number of divergent results is even greater.) To merge the tests, we would need to define a winning result for all of the divergent result pairs, and then demonstrate that our winning result can be considered appropriate for all installations. Such an undertaking has not been attempted, and I cannot imagine it achieving consensus. The result needed for DMARC is the result I believe is actually being produced by most installations: The result is evaluated based on MAILFROM when it is not null, and evaluated using HELO domain when MAILFROM is null. Of course, using HELO as a proxy for MAILFROM only works for bounce messages being returned from installations hosting a single mail domain on a matching host domain. For everyone else, DMARC will only verify automatic messages that are signed with the From address domain. The DMARC specification should make this clear to the reader. - - - To correct an earlier comment of mine: fcDNS on HELO and SPF HELO tests can be used together quite effectively. fcDNS validates that the server is reporting a valid host name, limits the allowed results to a single DNS domain, and demonstrates that the domain being used for SPF HELO is the correct one. However, fcDNS does not demonstrate that the server is authorized to send mail. SPF defines the servers which are allowed to send mail for the domain, but may include IP addresses from other domains, either directly or through Include clauses. When the host name is verified with both fcDNS and SPF HELO, the evaluator knows that the server is in the reported domain and authorized by that domain to send mail. Note that this is also different from fcDNS on the Reverse DNS name, as reported with the "iprev" test result. We really do not have a way to report test results for the HELO name. It would seem desireable to add test result indicators for both fcDNS HELO and fcDNS SPF. Doug Foster . On Tue, Feb 2, 2021 at 2:54 PM John R Levine wrote: > >> There is some commented out code to not pass a HELO result to DMARC, > don't > >> remember why I turned it off. > > > > I’m lost in a double negative here: did you turn off passing a HELO > result to > > DMARC, or did you turn off not passing a HELO result? > > The live code uses whichever result it has. The commented out code only > used a MAIL FROM result. > > >> Again, I believe this is typical of what DMARC validators do. It's > >> existing practice and I see no reason to change it. Can we stop now? > > > > If you found that you needed to turn off something that’s part of the > DMARC > > spec, it would be good to understand why. > > I believe that what I am doing matches the spec. > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > ___ > 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
