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. DMARC/SPF says that if you get a message with my domain in the From line, then it should come from only the servers that I list in my SPF record. DMARC/DKIM says that if you get a message with my domain in the From line, that it must be properly signed by the source domain and unchanged thereafter. A domain with both needs to pass one or the other. > >> This is exactly what DMARC is intended to indicate. > > 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. 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. > >> 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. > >> It was designed for things like >> Banks to be able to send out messages that the recipients can trust came >> from them and not a scammer. (A scammer could fake this out with a >> 'look-alike' domain, but that leaves a strong back trail to the scammer, >> who tend to want to hid in the darkness of the web. > > Exactly, it's designed to prevent spoofing. > > And here's my rant: > > This is a *public mailing list* for Christ's sake! If you are going > to post to it then you should expect your message to be seen by the > public! DMARC will not stop or prevent this, all that DMARC does is > send the message to Spam. It will still be seen in the mailing list > archives and it will still land in some folder on nearly every member > of this list's mailbox. If you have sensitive info DMARC will not > stop that and you should not be posting sensitive info to a public > mailing list! > > > Peter 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). 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. Domains using DMARC and allowing users to use mailing list are working outside the original design parameters of DMARC. 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. 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. 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. 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. -- Richard Damon
