As Chair- This thread is quickly becoming unproductive and veering to personal attacks, which will not be tolerated.
Please engage productively and on the merits, take the conversation elsewhere, or disengage. Seth On Tue, Nov 24, 2020 at 2:57 PM Michael Thomas <m...@mtcc.com> wrote: > You'd be wrong. The only ad hominem was yours from yesterday and it was > I think where *you* dismissed the very question I raised: > > "Two or more levels of forward are quite common, particularly in large > mail systems. Look at mail coming out of Google and Microsoft's hosted > mail and you'll see a lot of ARC headers. > > Considering that the ARC RFC was published over a year ago, and it is > implemented all over the place, could you explain what the point of this > discussion is? The people who designed ARC are not idiots. If we could > have fixed the mailing list problem with existing DKIM signatures, we > would have." > > And as I've said repeatedly, do not contact me in private. > > Mike > > On 11/24/20 2:53 PM, John R Levine wrote: > > This appears to me to be an ad-hominem attack on the people who > > designed ARC, so I think we're done. > > > > On Tue, 24 Nov 2020, Michael Thomas wrote: > > > >> > >> On 11/23/20 6:04 PM, John Levine wrote: > >>> In article <e8e1d300-fbe7-6d10-c15f-30c29ab74...@mtcc.com> you write: > >>>> What I'm struggling to understand is what having authenticated > >>>> auth-res > >>> >from a previous hop helps. this is what i found: > >>> > >>> See some of the previous messages. My usual example is a mailing list > >>> message that fails DMARC at the final recipient but passed DMARC (as > >>> recorded in AAR) when it arrived at the list. This lets the final > >>> recipient distinguish between real messages from subscribers and mail > >>> from spambots that happened to scrape both the list address and some > >>> subscribers' address and sends mail to one pretending to be from the > >>> other. (That definitely happens, I've seen it on lists I'm on.) > >>> > >>> I agree that the ARC document does not do a great job of explaining > >>> that. > >>> > >>>> It would be kind of nice to understand what gap ARC actually plugs and > >>>> why it's important if you ask me. Also: there seem to be a lot of ways > >>>> to achieve this, but this one is probably the most complicated one > >>>> that > >>>> I can envision. > >>> If you want to pass the A-R results through multiple rounds of > >>> forwarding, you can't do much less. > >> > >> > >> Sorry, changing the auth-res to old-auth-res and dkim signing the > >> message would be completely sufficient, and far easier to understand > >> with a lot less bloat. All of this hand wringing about dozens of > >> message manglers in the path before it get to the destination and not > >> be able to figure out which auth-res was which seems wildly out of > >> proportion for what the normal case is: 1 message mangler in the path > >> before it arrives at the receiver's domain. Just like this message > >> right here. That's why I asked how common that was, which was > >> dismissed, but not answered. > >> > >> Mike > >> > >> > > > > Regards, > > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > > Please consider the environment before reading this e-mail. > https://jl.ly > -- *Seth Blank* | VP, Standards and New Technologies *e:* s...@valimail.com *p:* 415.273.8818 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
