On Sat, 19 Aug 2017, at 16:33, Hector Santos wrote: > On 8/16/2017 8:21 PM, Bron Gondwana wrote: >> On Thu, 17 Aug 2017, at 03:46, Hector Santos wrote: >>> On 8/13/2017 10:28 AM, Kurt Andersen (b) wrote: >>> >>> On Sat, Aug 12, 2017 at 4:51 PM, Hector Santos wrote: >>> >>> If we even have a DMARC ARC Policy concept, than that may be >>> enough to begin pursuing the high cost of experimentation and >>> development here. >>> >>> >>> Beyond the protocol and usage specs, what are you looking for? >>> >>> >>> A practical purpose for supporting (implementing) this work. It >>> appears ARC wants the network to stamp mail "blindly" as the mail >>> travels from point to point. I am trying to grasp how it helps >>> resolve the main issue with "unauthorized" indirect 3rd party >>> signatures, in particular when dealing with strong, exclusive DKIM >>> signature policy models such as DMARC p=reject. >> >> We spent a while thinking about this (Neil and myself from FastMail)>> at >> IETF99 after learning how ARC works, and came to the conclusion >> that ARC as specified can't help with DMARC p=reject. >> >> The only way you could even hope (as a mailing list) to avoid >> rewriting the sender is for every site that currently has DMARC >> p=reject to change that to a new policy which explicitly means "only>> >> reject if no ARC chain" - otherwise you can't stop rewriting sender >> until you know that every receiver on your list is ARC-aware. > > The MLS (Mail List Server) cam also reject submissions from > restrictive (p=reject) domains because that MAY be the intent of the > originating author domain. The MLS can so prohibit new subscriptions> by > verifying the user's domain is not restrictive. > > We need more protocol information from what extracted from DMARC. As> I see > it, these are some of the boundary conditions: > > DMARC p=reject; arc=none; ignore ARC, same as no arc= tag > DMARC p=reject; arc=all; reject if any arc seals is > invalid> DMARC p=reject; arc=first; don't reject if first arc > seal is> valid > DMARC p=reject; arc=last; don't reject if last arc seal is> valid > DMARC p=reject; arc=first,last; don't reject if first and last > arc seals are valid
For what it's worth, the ONLY one of these which my "fake Brandon" email would have failed to validate for is p=reject, arc=none. A chain of valid ARC seals is so easy to fraudulently create that it's not funny. Everything other than arc=all there is totally pointless - if you can intercept and modify email, you can easily add ARC headers that maintain a complete chain is seals. Now arc=site2.com,site3.com,site4.com - that's valuable. You could say "only allow ARC through the following intermediate domains" - and then you could add those to your allowed list for your domain as you got reports of validation failures and user requests. Over time a domain would build a list of mail flows that its users used. You could even use a different selector for each sending user, and publish a different policy for that selector, so each user got their own allowed mail flows! But anything that's based on count/position of seals in the chain, that has no value. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd br...@fastmailteam.com
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
