On 4/26/20 11:47 PM, Peter wrote: > On 27/04/20 2:02 am, Richard Damon wrote: >> On 4/26/20 8:15 AM, Peter wrote: >>> On 27/04/20 12:00 am, Richard Damon wrote: >>>> Except that if the sender is sending from a domain with an email >>>> policy >>>> that effectively says, "This domain is intended to send sensitive >>>> information, please do not accept messages that do not come directly >>>> from us", then it is reasonable to tell the sender that they are >>>> sending >>>> messages outside their domains (implied) terms of service, and either >>>> they need to use a different service that is compatible with a mailing >>>> list, or have the domain fix its implied declaration of usage. >>> >>> But that's not what DMARC does. >> >> It is EXACTLY what DMARC does. > > You claim that DMARC is supposed to control sensitive information. It > does nothing of the sort and cannot do anything of the sort. DNS > records cannot stop someone unauthorized from accessing sensitive > information in an email message. It is for something like an alert that there is a suspecious use of your credit card, so please check with your bank. The sort of thing many of us get a phish attacks. > >>> Ummm, no it's not. DMARC is intended to stop mail From: header >>> spoofing. >> >> And re-mailing the original message is classified as From: header >> spoofing. > > Since when? If you leave the From: header intact how is that > spoofing? Exactly what are you misrepresenting? That's like saying > that if I make a copy of a document then I am misrepresenting the > original. In fact changing the From: header which we must do to work > around the issues that DMARC poses is much closer to spoofing (but > still is not, imo) than simply forwarding the message with the headers > intact. If I take a measage that has been protected by just DMARC/SPF, and forward it, it will fail DMARC and be considered a spoof. Yes, in our personal understanding, taking an email message in on a mailing list and resending it out, maybe with some minor administrative changes isn't a spoof, but to DMARC is it. THAT is part of the issue with DMARC. > >> A properly setup DMARC/DKIM (but not just DMARC/SPF) does >> allow remailing if the message is kept identical in the signed respects, >> so DMARC with a broken (or not setup) DKIM can't use re-mailiers at all, >> and one with DMARC/DKIM can only use remailers that don't modify the >> message, including the common adding of a subject 'wart' to identify >> messages from the list or a message footer (or sometimes header) with >> instructions about the list, included out of policy or sometimes even to >> be compliant with local legal requirements. > > DKIM is not required for DMARC. Yes, and DMARC without DKIM will break EVERY email list (without careful updates by the domain manager), as the list will not be one of the approved IP that mail from that domain is allowed to come from. > >>>> Configuring a domain >>>> with DMARC says that it is intended that message only be accepted if >>>> they come directly from the sender. >>> >>> I call BS on that, and in fact ARC was created specifically to allow >>> third parties to forward DMARC policy messages on without having them >>> flagged as Spam. >> >> ARC is a late to the party attempt to fix the misuse of DMARC. To my >> knowledge it isn't even an accepted standard yet, and it asks for the >> impacted 3rd party to add to its processing to allow it to become an >> 'approved' re-resender. It also starts with the list with being a >> violator until the system 'learns' that it is ok. > > Google recognizes it, and in the case of the above mentioned messages > it is likely that ARC would have fixed it so that the message would > not have ended up in my Spam folder. That said, I already did point > out that there will be servers that enforce DMARC which do not > recognize ARC and as such I would prefer to see other mitigations done > that do not require ARC. But I simply pointed it out as an official > attempt to fix a shortcoming with DMARC.
ARC is a sign that DMARC is broken, that it wasn't intended for the uses that it is now being used on. It was NOT a part of the initial DMARC proposal, there is no sign at all of it in the design. It is a patch fix to handle a problem that came up when DMARC was misused. we are now 6 years after DMARC was misused, it took 3 years from that to have initial proposals, 5 years to get an 'experimental' RFC, which is our current state. It basically says, hey, all you mailing list out there, here is an idea we have, why don't you all implement this to see if it works, we likely will need to tweak the details in the future, but thats ok, you can just make the changes when we do. That is a bit like some Doctors coming out with a medicine that looks like it will help against COVID-19, we haven't had a chance to run a full set of trials, but early tests show it won't kill you, at least not quickly, so we want everyone to take the shot. Oh, and we have persuaded a number of grocery chains that they will insist that you show proof of taking it before you can come in to shop. Based on this trial, we hope to improve the medicine. > >> DMARC's purpose is to stop phishing, people pretending to be you when >> they aren't. Mailing list send messages out on Behalf of you, but the >> DMARC protocal wasn't built to handle this case (ARC is trying to fix >> it, but is late to the game). > > Which is exactly what I have been saying as well. The problem is it calls most mailing list phish. > >> Now, if DMARC had a level below >> quarantine, that said to accept the messages even if they don't pass the >> DMARC validation, and to not treat this violation as likely spam, but >> maybe and a remailer warning, but it doesn't, as it wasn't intended in >> its design to handle this case. > > Then bad admins would still misconfigure it and cause problems for > mailing lists. > >> Domains using DMARC and allowing users >> to use mailing list are working outside the original design parameters >> of DMARC. > > Correct, DMARC was not designed with the needs of mailing lists in > mind, therefore mailing lists must take measures to work around the > issues that DMARC has now caused. NO! That isn't how standards are supposed to work. > >> If a mailing list gets a message from a DMARC enabled host it has just a >> few possible mitigations: >> >> 1) If the sending domain has a proper DMARC/DKIM setup, the list can >> just forward the message without making any modifications that would >> break DKIM, provided that this falls within the policy and laws the list >> run, IF DMARC/DKIM isn't setup properly, this option can't be used. > > Normally, yes, however keep in mind that Google is a bolack box and > they recommend that all three of SPF, DKIM and DMARC are configured > for the sender. I would not put it past them to at least on some > degree affect the SPAM score if, for example, if the DKIM passes > against the From: domain but SPF does not. With that in mind, it is > likely best if the list server makes sure that all elements of DMARC > pass and not just DKIM or SPF. > >> 2) The list can violate the EMail RFCs, change the From header to be the >> list (thus claiming authorship of the message) and distribute the >> message this way. This makes if hard to identify the real author of the >> message, as it no longer is in the from header, so doesn't show in many >> MUA. This is the common DMARC mitigation. > > Right, and this is the standard recommended mitigation, but it is > generally only performed when it has to (ie when there is a DMARC > policy set to reject the message otherwise). Also it is arguable if > it truely violates the RFCs if you're claiming ownership. If it does > then it could be said that it violates the RFCs just as much when > someone hits the "Forward" button in their MUA, although this > capability and action is quite common and has been for decades. > DMARC, when used on a domain that allows use of re-mailers is fundamentally flawed. Note, DMARC isn't even 'Standard Track', it is just an informational standard. That means there is currently NO attempt to make it part of the official EMail Standards, it is merely a piece of information designed to allow two domains that want to transfer some information to do so, it isn't supposed to have impact on third parties (that would need to be Standards Track). >> 3) The list can just not allow people from DMARC enable domains to post >> (which is ultimately respecting the implied wishes of the domain >> publishing a DMARC record). When YAHOO and AOL first abused DMARC in >> this way around 2014, this was one option that was put forth in the >> Mailing List community. > > This is certainly an option, although I would say quite a draconian > one and it is arguable that the DMARC policy actually reflects the > wishes of the domain owner in this way. Usually a strict DMARC policy > is in place simply to prevent spoofing, and not to prevent someone > from sending mail to a mailing list. But, by the way the DMARC standard is set up, a domain that publishes a DMARC policy is effectively saying that they don't wish for their users to use mailing list, (or if they DMARC/DKIM sign mailing lists that administratively modify messages, which is historically common). When Yahoo and AOL did this in 2014 they effectively BROKE the Email standards. They were able to get away with it because they were the big gorillas of the industry. The primary reason the mailing list community didn't just decide to ban Yahoo users was compassion. It was realized that banning Yahoo users from using mailing list to keep them from being broken would just hurt the little guy, the users of those systems who chose it because they didn't require the user to be very computer savvy. That those users were likely largely 'captive' not wanting to change to other providers that they would need to learn a totally new interface. That if those users complained, Yahoo wouldn't really care, real mailing list users don't make a large enough proportion of their user base to impact them, especially considering the lock-in factor. > >> 4) Send the message normally and take all the DMARC violations (and >> possible non-reception or spam classification), this also can cause the >> receiving domains that respect DMARC to send bounce messages to the >> mailing list which may cause those recipients to get unsubscribed from >> the list. These violations may also impact the reputation of the list >> when relaying other messages that don't have the DMARC issue. > > This seems to be the approach that this mailing list is currently > taking. I don't believe that very many ESPs actually send bounce > messages in response to DMARC violations, the general response is to > deliver the message to the recipient's SPAM folder. It can, however, > also affect the list server's IP reputation. > > You forgot option 5 - ARC mitigation. While this option is not yet > widely supported major ESPs such as google and I believe Microsoft do > appear to support it now and adoption should only grow with time. The > obvious drawback is that there will still be servers that enforce > DMARC policies but do not recognize ARC yet and to those servers it > will look like a DMARC violation and you end up with situation 4 above. > > My personal preference at this time is option 2. At some future time > after ARC is more widely adopted I think we should change to adopt ARC > instead. > > > Peter -- Richard Damon
