[dmarc-ietf] so long again

2021-02-03 Thread Michael Thomas
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

Re: [dmarc-ietf] Ticket #1 - SPF alignment

2021-02-03 Thread John Levine
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,

Re: [dmarc-ietf] Ticket #1 - SPF alignment

2021-02-03 Thread Alessandro Vesely
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

Re: [dmarc-ietf] Report bombing is a prolem, Forensic report loops are not

2021-02-03 Thread John R Levine
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

Re: [dmarc-ietf] Ticket #1 - SPF alignment

2021-02-03 Thread Douglas Foster
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