On Thu, Aug 17, 2017 at 2:46 PM, Bron Gondwana <br...@fastmailteam.com> wrote:
> On Fri, 18 Aug 2017, at 05:11, Brandon Long wrote: > > dammit, posted from the wrong address again... > > > You'll be dealing with this until the bulk of mailing lists AND receivers > have become ARC aware, so you've got a while to get used to changing which > address you post from :p > The bulk of mailing lists I deal with are rewriting From headers, IETF is a special case. > On Wed, Aug 16, 2017 at 5:47 PM, Bron Gondwana <br...@fastmailteam.com> > wrote: > > > > On Thu, 17 Aug 2017, at 10:34, Seth Blank wrote: > > On Wed, Aug 16, 2017 at 5:21 PM, Bron Gondwana <br...@fastmailteam.com> > wrote: > > 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. > > > I don't understand your point. > > > > If you are a mailing list and you receive a message from a domain with > DMARC p=reject, you can't send that message on to the members of your list > without rewriting the sender. > > > The only way DKIM works is if enough receivers validate it. > > The only way adding elliptic curve to DKIM works is if enough receivers > validate it. > > The only way a DMARC policy works is if enough receivers validate it. > > ARC is the explicit solution to mailing list breakage with DMARC. But, as > with all other IETF RFCs, only works if enough receivers validate it. > > Our job is to make sure ARC accomplishes its goals under the DMARC > charter, and demonstrate value to receivers that it's worthwhile to > implement. > > There will always be a ramp up and implementation phase, that is a > feature, not a bug, and not a reason to say "it won't work." > > > > While there exists A SINGLE SITE which is ARC-unaware and DMARC p=reject > aware, you can't use ARC on a DMARC p=reject domain without rewriting the > sender. Otherwise that site will bounce the email. > > You still have to rewrite the sender until there is either full adoption > or sufficient adoption that you just don't care about the stragglers. > > ARC doesn't solve that unless every receiver is either ARC-aware or > DMARC-unaware. Hence the suggestion that I think Hector is making - to > define a new policy p=rejectnonarc or something, which means that sites > which are ARC-unaware accept rather than reject. > > > Theoretically, if rewriting the from header had been the "approved" way to > work around DMARC issues for mailing ilsts, one could imagine that > something like ARC could have explicitly allowed for that concept and > making it so receivers could back-sub the original From or something. That > way, ARC implementers would get immediate benefits over from rewriting. > > > I've thought quite a lot about that as well. I would love if most mailing > lists included enough data to reconstruct the original DKIM-passing message > again, so the receiver could actually know the diff from the original > message and scan it separately. That way you could very easily know > whether the source of any objectionable content was the mailing list or the > original sender. > We went down the path of including a diff of the message in the headers, but you run up against more complicated changes that make that challenging. Ie, mailing lists which strip attachments. If all we cared about were subject munging and footers, there probably would have been a practical solution there. > OTOH, if you ignore from header rewriting as a solution (which many have), > then ARC implementation theoretically adds immediate benefit (or the > potential for immediate benefit, since it requires participation from both > the mailing list and receivers) > > > I kind of buy that. I'll be interested to see how it pans out in practice. > > ARC definitely solves more than from header rewriting does, but from > header rewriting is certainly a much simpler solution for mailing lists... > even as it makes them slightly worse to use. > > > As someone just about to launch a new mailing list product, we will be > from-header rewriting for DMARC p=reject domains for at least a little > while, and likely building something horrible which attempts not rewriting > for individual recipients and keeping a whilelist to see if they don't > reject. Though if someone is just dropping messages, we would never know - > it's a horrible uncertain situation as the site in the middle, because you > don't know how the message will be handled downstream - it depends on > whether the recipient supports ARC, and you can't know that for sure. > > That's the big that makes me uncomfortable - ARC is defined in such a way > that certain participants are unsure of whether they can safely keep > sending legitimate email and have it accepted, because the interaction with > DMARC is defined in such a way that ARC *changes the behaviour of DMARC* > in a non-backwards-compatible way, and we will be running, for at least a > while, in a world in which some recipients treat DMARC the old way > (non-ARC-aware) and some treat it the new way. > > So your only possible mitigation as the middleman, if you want full > deliverability, is to modify the message in such a way that DMARC no longer > applies to it. > Yes. Brandon
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
