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.
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.
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.
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.
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.
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.
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.
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.
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
