On Apr 11, 2014, at 6:38 PM, Scott Kitterman <[email protected]> wrote:
> On April 11, 2014 9:25:58 PM EDT, Franck Martin <[email protected]> wrote: >> >> On Apr 11, 2014, at 5:59 PM, Scott Kitterman <[email protected]> >> wrote: >> >>> On Saturday, April 12, 2014 00:46:44 Franck Martin wrote: >>>> On Apr 11, 2014, at 5:34 PM, Scott Kitterman <[email protected]> >> wrote: >>>>> On Saturday, April 12, 2014 00:25:33 Franck Martin wrote: >>>>>> On Apr 11, 2014, at 2:22 PM, Miles Fidelman >> <[email protected]> >>>>> >>>>> wrote: >>>>>>> Has anybody here implemented Original-Authentication-Results and >>>>>>> verified >>>>>>> that it actually works with mail flowing from an author >> @yahoo.com, >>>>>>> through a (patched) mailing list manager, and on to: - the >> original >>>>>>> author @yahoo.com >>>>>>> - someone else @yahoo.com >>>>>>> - any of the other systems that respect Yahoo's p=reject policy? >>>>>> >>>>>> There have been experiments and an Internet-Draft but nothing >> meaningful >>>>>> deployed in production anywhere. >>>>>> >>>>>> The DMARC faq has been updated to provide a bit more guidance. >>>>> >>>>> Why is it better to add a new type of header field than to simply >> add a >>>>> new >>>>> DKIM signature when forwarding that also signs the A-R fields >> you've >>>>> added. If a receiver trusts the sender not to lie about O-A-R >> fields, >>>>> then I don't see not trusting the A-R fields they add. >>>> >>>> 'Cause the AR RFC says to delete this header on reception… So it is >> not a >>>> header meant to survive forwarding… >>> >>> No. It doesn't. >>> >>> https://tools.ietf.org/html/rfc7001 >>> >>>> 5. Removing Existing Header Fields >>>> >>>> For simplicity and maximum security, a border MTA could remove all >>>> instances of this header field on mail crossing into its trust >>>> boundary. >>> >>> The only ones you MUST delete are ones the pretend to be from within >> your >>> ADMD and are not. It says you could remove all of them, but that >> might cause >>> problems. >>> >>> My reading of RFC 7001 is that exactly the use case being suggested >> for O-A-R >>> is already addressed by A-R and so there's no need to re-invent the >> wheel. >>> >> Some known email appliances apply the "Simplicity and Maximum Security" >> principle. > > Okay. So now that it's not "because RFC" it's "because existing > implementations". Since no one implements O-AR now they'll have to change > something. Inventing a new header field only complicates things without > helping. But it separates problem spaces > > Why would a receiver that removes all external AR fields because they are > considered risky not also remove O-AR too? Cause it is a new header they don’t know about… > > Personally I doubt either one helps much since they could only be useful from > known good senders and I suspect that once you have a list of such senders it > makes much more sense to skip DMARC entirely than to complicate things by > groveling through the header fields to figure out which ones they added. > > That said, I don't see a valid reason to make up something new to do what AR > already does. > indeed.. I don’t have much thought either way, just wondering about many A-R headers and DKIM signing (which ones were signed), and transitive trust….
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
