On Thu 30/Mar/2023 01:55:38 +0200 Barry Leiba wrote:
1. IETF has installed a very ugly workaround to the problem, rewriting the
"from" header field. It's absolutely a workaround, and not a proper
solution.
I agree the workaround is ugly. However, I drafted three ways to avoid it and
gathered the neat feeling that people, after all, does not dislike From:
munging so much.
In addition, it is possible to post to this list using a false From: copied
from another subscriber. I did it, and it was received:
https://mailarchive.ietf.org/arch/msg/dmarc/K7L23b0F5MHY-KieqR_5i5cNyAc/
Such spoofing has also been possible for decades. Will it have to be that way
for ever or can lists be secured? IOW, what can I do to avoid being impersonated?
2. Without the workaround, the real pain is not that a message from Comcast
posted to the list doesn't get to you (though that's true): the real pain
is that if Valimail rejects (bounces) those messages, the Mailman software
will eventually unsubscribe you -- YOU, not the Comcast user -- from the
list for exceeding the bounce threshold.
Been there, done that.
3. Even with the workaround, I see, as a list owner, several unsubscribe
notifications a week due to excessive bounces.
Changed addresses?
The damage to mail list operations is real, and expecting every mailing
list manager to install an ugly workaround is not the right answer.
Yet, is is what most lists are doing, sometimes at the cost of changing host.
Telling those deploying DMARC what interoperability problems an
inappropriate choice of p=reject causes, and telling them not to do that...
is the right answer.
Perhaps it would have been the right answer nine years ago. If we do it now no
list is going to roll back.
And, as I said, when they decide that their needs are more important than
those interoperability problems, they have that right, and at least they
will now be making an informed decision. The standard needs to say this.
A standard that says that interoperability is more important than security is
not going to gain high consideration, given the general atmosphere nowadays.
Best
Ale
On Thu, Mar 30, 2023 at 6:41 AM Todd Herr wrote:
Colleagues,
Can someone please point me to a mailing list server or other indirect
mail flow that I might somehow engage with so that I can experience the
pain of not having a message reach its destination when sent with a policy
of p=reject?
I post to various IETF mailing lists from my work address, and my
employer, like Mr. Brotman's, publishes a DMARC record with p=reject.
Thanks to the work of the folks who manage the IETF mailing list software,
my participation in these discussions is not hindered in any way; I can
post to lists, people can reply directly to me if they choose, and I can
reply to the list and/or to the author of any post without any extra work
on my part.
This leaves me in a position where I do not appreciate how a DMARC policy
of p=reject can harm interoperability, or perhaps better stated, I do not
appreciate that it does harm interoperability. I understand that it can,
because SPF can fail when mail transits intermediaries and DKIM can fail if
the intermediary alters the content of the message. That said, I cannot
recall seeing a bounce attributable to a DMARC failure in the three years
that I've worked here (nor for the year or two prior when my previous
employer deployed p=reject) and so I want to be able to send a message that
would result in such a bounce.
Can anyone help me?
Thanks.
--
*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* todd.h...@valimail.com
*m:* 703.220.4153
This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
