Post by Brian E CarpenterI don't. Accept the posting but also send a friendly warning seems to do less damage.
The DMARC policy is not to forward, and we should respect it.
Why does DMARC, which is a broken solution, deserve that much respect?
When ARC gets standardized, we should implement it.
Assuming it solves the problem, sure. But if it doesn't, the problem will
get much worse.
Folks,
I am probably more frustrated about the expanded use of DMARC than most
folk, since I participated in creating the DMARC spec. For the
constrained scenario that motivated its design -- let's call it b2c --
it works pretty well. The expanded use -- let's call that c2c -- was
initially the ad hoc choice of one service provider, but it turns that
quite a few others also like it: there is a broad-based belief in that
community that aggressive requirements for author authentication will
alleviate many abuse problems. On the average, the downsides of that
view do not resonate in that community.
At any rate, the expanded use is what's causing the problems.
There are some realities that folk should note, when forming their
opinions about this problem:
1. There is nothing 'broken' about DMARC. There is a problem with a
particular use of it, but the mechanism, itself, works as designed.
2. Mailing lists have always been an odd architectural wrinkle. (I
commend RFC 5598 to anyone interested in the formalities.) An author
sends a message to the list address. The message gets /fully/
delivered; that is, it goes into the mailbox specified by the mailing
list address. The mailing list posts a new message. Whether the mailing
list retains all, or only almost all, of the original message, and even
all of the original envelope (except a new envelope addressee list) it
is a new message: And this is worth repeating: if the message undergoes
any changes beyond classic, minimal MTA addition of tracing information,
the message being sent is a new message. But the user-level experience
is of an author sending to a collection of end recipients. The users
don't really experience this as a re-posting. But the reason it's
important to understand that it is, indeed, a different message than
what the author posted is that mailing lists can and do do all sorts of
damage to the original. The essential challenge in trying to
accommodate a mechanism, like DMARC, that is designed to work within one
posting/delivery sequence, when there is more than one, is that we don't
currently know how to make it fully seamless.
3. The folk using DMARC are not violating any rules. Some are
causing problems for some of their users and some of the folk that their
users interact with, but that's different than saying they are violating
a protocol, or the like.
4. The folk using DMARC for c2c are not seeing a significant problem
from that use and they do report significant benefit. Sitting here in
the IETF, we might not like their assessment, but it's their business,
not yours or mine.
5. The IETF has no meaningful leverage over those service providers.
Any thoughts about what to do should keep that in mind.
6. Any thoughts about what to do should pay very close attention to
who has to take action, how considerable that action is, how long it is
likely to take for that action to happen, and what their incentives are
for taking that action. And remember that all of this has to satisfy
business concerns, not good-neighbor appeals.
7. The providers' affected users have no leverage on their
providers. None.
8. It is easy to tell those providers' users that they should go to
a different provider, but take a look around for choices of consumer
email providers: there are precious few choices on the Internet today.
And for the affected consumers, they need a free, well-run provider who
operates at scale.
9. ARC is expected to help this situation, but I suspect it won't be
as much help as anyone would like. At the least, it requires adoption
by both the mailing lists and the receiving MTAs, and that's a lot of
adoption to require.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net