On 2021-01-29 at 14:36 -0800, Dave Crocker via mailop wrote: > Although I showed some restraint in my earlier note, I will now point > to > two specifications I put together, seeking a less hacky way of > dealing > with this DMARC-generated issue: > > Author Header Field > https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/ > > https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/ > DMARC Use of the RFC5322.Sender Header Field
Nice. Was it intentional to publish it the day after it expired? I love having a way to keep the actual value that should have been in the From: header, even though it's a kludge having to add another header because dmarc considered to bend on broken MUA, thus requiring everything else to rewrite the From: header and end with the "thing" we have now. However, despite not liking From rewriting, I find the security section of the draft inadequate as well, Whereas dmarc authors erred by being overly cautious not accepting mail that came through a mediator host, adding a new header with no clear guidance would -if adopted by mail clients- only reintroduce the same problem dmarc attempted to tackle so zealously. People do fall for obvious email impersonations (and not-so- obvious when using *certain* MUA which "helpfully" hide the original email address *cough*). Attempting to add a new way to identify the sender without definign a the threat model, acknowledging the associated risks and providing a way to mitigate them would be wrong and lead to a mix where each vendor would have to attempt dealing with it on its own. Best regards _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
