On Fri 14/Apr/2023 21:36:54 +0200 Dotzero wrote:
On Fri, Apr 14, 2023 at 2:00 PM Laura Atkins <la...@wordtothewise.com> wrote:
On 14 Apr 2023, at 18:38, Alessandro Vesely <ves...@tana.it> wrote:
On Wed 12/Apr/2023 13:41:16 +0200 Laura Atkins wrote:
On 12 Apr 2023, at 12:21, Douglas Foster <dougfoster.emailstanda...@gmail.com>
wrote:
Any form of security creates inconvenience.
Yes. And we make tradeoffs between that. In this case, the security is
ensuring that users at specific domains can and should only send mail
through approved channels managed by those domains. Many users have
violated those security policies, by participating in mailing lists. This
caused problems for other folks on the mailing lists - as they were the
ones removed from the list due to the security policy. The lists responded
by rewriting. This causes yet more inconvenience to other subscribers and,
additionally, allows the users to bypass their domain security policy.
I am not seeing how this creates an arena of security.
Security is not From: munging. That's the workaround that security
requires.
No security (at least in the viewpoint of some people) is using a p=reject
for mail from their domain. In that context, From: munging is actively
subverting the security settings of domains.
I guess the subversion you mean is that From: munging gets people used to see
such kind of fake. I agree that incongruity between display-phrase and actual
address can be a security threat. However, there are innocent forms of it.
Based on the header rewriting done by IETF, I have a hard time seeing how
its rewrite of Comcast addresses can cause any of the problems that you
cite.
That’s how the IETF rewrites, it’s not how everyone rewrites.
Couldn't the IETF say how to rewrite?
There’s currently a deployed base where there are many different ways to
munge. "It is a _fact_.”
Yes. Yet, better munging can always be applied without altering
functionalities.
But does your domain require even headers to be rewritten? Why doesn't
IETF ask you, and omit rewrite if that is what your domain wants?
Because that doesn’t scale for the IETF.
Mailman options do scale. From: rewriting is going to fade off by first
allowing single subscribers to disable it, for the posts directed to them,
after their MX set up some kind of agreement with the MLM. >>>
The _fact_ still remains that From: rewriting is actively subverting the
security of domains that choose to publish p=reject.
I'd rather call it training readers on the significance of the display-phrase
part of a From: line. Phishermen will keep on exploiting it in any case.
It is hard for me to cry over mailing lists when they cannot ensure that a
post comes from the asserted poster and they cannot adapt their DMARC
defenses to the preferences of the recipient domains. Life is hard. It
only gets harder if I wait for someone else to solve problems that I can
solve myself.
I don’t understand how header rewriting ensures the authenticity of a
poster. Given the data is being modified by the MLM, it seems to me that
rewriting compounds the problem.
It doesn't. The authenticity should be checked on entry. THIS IS ABUSE
post had dkim=fail by ietfa.amsl.com, but they didn't bother rejecting
for that, which is what they should have done. We are suffering all the
damage caused by DMARC but don't enjoy any of the advantages it could bring.
I encourage you to think very hard about why, after more than a decade, we
still don’t see any of the advantages to DMARC.
Didn't get that. I'd guess that implementing DMARC wasn't a priority for IETF
mailing lists.
While the you part of "we" may not see any advantages, quite a few
financials, greeting card sites, retailers AND many receivers have seen the
advantages, including p=reject. One thing I've learned over the years is
that it is presumptuous to speak on behalf of "everyone" when you don't
actually have their authorization to speak on their behalf. It's kind of
like sending email claiming to be from someone else's domain without their
permission.
Michael obviously understood Laura's point better than me. The only part I
understood is that "we" are the ML subscribers. We see no advantage because
DMARC is not implemented on ietfa.amsl.com.
Oh, certainly until the only abusive messages we see are those straw men, there
is no actual worry. It's the principle...
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
