Stephen! Welcome! No one said making sausage was pretty. :-(
On May 29, 2014, at 6:21 AM, Stephen J. Turnbull <step...@xemacs.org> wrote:
> Tim Draegen writes:
>
>> John, you are very difficult to communicate with, maybe because
>> you're easily insulted, even when there is no insult. I too have
>> been in correspondence with mailing list developers,
>
> Which ones?
I don't think it would be appropriate to name people, but to a larger point, I
have to apologize if I come across like a jerk. There are a lot of people
trying to deal with DMARC across many forums, and my attempt to imbue a sense
of breadth and depth was ham fisted. I live and learn.
>
>> and also developers behind businesses that rely on email,
>
> That's insufficiently precise. To my mind, there are two kinds (at
> least) of businesses that rely on provision of mailboxes (other use
> cases follow).
I was thinking of businesses that rely on the perfectly acceptable (but now at
loggerheads with DMARC-based controls) practice of sending on behalf of
customers. For example, "stationary" businesses (described towards the end of
this mail:
http://www.ietf.org/mail-archive/web/dmarc/current/msg00923.html).
There are also businesses that perform "SMTP Cleaning" ala anti-spam filtering,
plus "SMTP backup" services that people find enough value in to pay for.
My ham-fisted point was that mailing lists are interesting for sure, but the
scope of email (potentially) impacted by DMARC is bigger, and maybe we should
think about the space a bit more generically.
> Does DMARC actually impose significant burdens on the "corporate use
> case", contrary to my belief?
I don't personally carve up the email space along corporate vs non-corporate
lines. People at corporations communicate via mailing lists.
Before Yahoo and AOL went to p=reject policies, the advice was to keep
DMARC-reject policies to "transactional" domains. "Transactional" in this
context mapped to "email that isn't likely to be impacted by things that break
DMARC like mailing lists".... stuff like account notifications, receipts, not
people-to-people.
But it turns out that quite a few people create mini mailing lists to map a
single recipient of a transactional piece of email to multiple recipients...
like receipts going to bi...@family.org, where the parents and an archive are
the final recipients. So, dang.
> Of course there are other use cases of "businesses that rely on
> email". I understand the "mailing list as user forum" case, and I
> believe Mailman has already implemented a sufficiently broad set of
> measures for business use in this use case. The tradeoffs aren't
> pleasant, but that's a cost of doing business with Yahoo! and AOL
> users. A business has the usual set of options (pay the costs, find
> less costly customers, use alternative forum technology, etc). I
> don't see a real problem here.
>From your mouth to the Internet.God's ear!
> There's also the "on behalf of" content provision use case. Others
> describe a good remedy in this thread, but I would like to point out
> that such providers may publish "p=reject" to good effect, as an
> instance of the "corporate use case".
>
> But my knowledge of "business use" is quite limited. Are there other
> "business activities relying on email" such that DMARC imposes
> burdens? Are those burdens specific to "p=reject", or more general?
>
> (If this is all well-known, please point me to a reference where I can
> book up without disturbing the Councils of the Wise.)
One giant problem that ISPs face is that they have large numbers of customers
that send email through their infrastructure but for domains that are not
related to the ISP. Imagine a residential network providers with lots of
customers that configured their email clients 20 years ago. It's largely
worked up until now. Is the ISP supposed to contact each customer and get them
to use the correct outbound SMTP servers? What is the right thing to
communicate?
Council of the Wise?! I always thought the IETF was a bunch of people hanging
off the edge of the world, getting together every once in a while to maybe
allow an accidental shared piece of understanding to be written down.
>
>> and also a slew of decision makers... and they're all trying to
>> understand how they can fix things without going backwards.
>
> IMO, they're wasting their time.
>
> Email service *must* deteriorate in the presence of users who send
> messages from "p=reject" domains, unless those domains are draconian
> in enforcing direct transmission to final destinations that observe
> "p=reject" (see Franck Martin's post later in the thread, and the
> following subthread on "legitmate use of 'p=reject'" that follows).
> Unfortunately, these domains are proposing that third parties adjust
> to their (unilaterally imposed) policy, rather than modifying those
> policies or restricting their users to safe email usage. But the "let
> third parties adjust" solution is a pretty dismal option. There are
> just too many MXes and MTAs and services that are DMARC-incompatible.
> It's going to take years, maybe a decade, to modify both the software
> and the installations.
I think you're largely correct, but I don't agree with the "wasting their time"
part.
Bringing domain-level identifiers to email took over a decade of largely
haphazard work. It probably *will* take another decade of work to modify both
software and the installations.
Given that much time, it should be possible to structure email service so that
service/features do not necessarily have to deteriorate. Well, today the
damage is being done, but is the response from the Council of the Wise to be
"email is deteriorating, this is the new normal", or can we put together
documents that describe how to interoperate -- not just for dealing with
p=reject domains within the context of mailing lists, but interoperability
between MLs and MUAs?
>
> The help we need is in explaining to our users that they cannot
> maintain past configurations and allow posting from "p=reject" domains
> at the same time. For many of our users, they get a MLM as a part of
> a hosting package and the only solution they can implement themselves
> is to refuse posts from those domains.
This is the stuff, right here. Asking Yahoo and AOL for help in educating
users is spot on.
> Where's the money to
> compensate those list operators for lost subscribers or the costs of
> switching hosting services? Where's the money to encourage hosting
> providers to upgrade their MLM installations? Where's the money to
> compensate operators for the emotional and social damage done by
> Yahoo! users who throw fits privately and publicly over lost posts?
> Yahoo!'s offer of support for developers is a pure FUD PR stunt, as
> far as GNU Mailman concerned.
A few hours ago I replied to John and expressed my view that Yahoo and AOL
aren't in a position to fix the internet... as much I can, I tried not to be
ham-fisted:
http://www.ietf.org/mail-archive/web/dmarc/current/msg00923.html
There's wreckage, yes. My aim, because I'm eternally an optimist, is that the
wreckage doesn't end with yahoo and aol being given the middle finger. Sure,
do that, but there's more work to be done that doesn't belong to yahoo or aol.
>
> The question is, to paraphrase John, how best to defend our users
> (subscribers as well as list operators) from the unilateral behavior
> of corporations desperate to mitigate their own problems. The rest of
> us *will* go backwards. The question is how do we minimize the
> retreat, and in which backward direction to go. Mailman, at least,
> offers list operators (precisely, those who can install the most
> recent versions) several options, so they can choose the one they
> dislike least.
I get it, but painting the scenario as this being only Yahoo and AOL's problem
is a distraction. There are plenty of small organizations and individuals that
are using DMARC to curtail abuse. I'd argue that the problem of email's
trivial ability to be used for abuse is everyone's problem. It's only Yahoo
and AOL's size that brought this work to the forefront.
>
>
>> Figuring out how to make email slightly less capable of harming
>> people is a big deal.
>
> Yahoo!'s use of "p=reject" reminds us that there is little we can do
> to make email as such less harmful.
Email is the #1 online attack vector. The "attack surface" that email presents
is incredibly huge. Attempting to change email so that defrauding millions of
people using email becomes only incrementally more difficult is what is going
on here.
The flip side is that the introduction of stable domain-level identifiers
should make filtering a lot simpler. How does the Internet take advantage of
these identifiers in the context of mailing lists, forward-to-friend,
send-on-behalf, and other contexts?
[my quarters are running out, so snip snip]
>
> I accept that this may not be a "big" problem from the point of view
> of this group, that's just Mailman's point of view.
I don't think "big" is required to be important. I for one am trying to
understand as much as I can about DMARC's impact from all angles.
>
>> Tell the people you're communicating with to post their finding to
>> either this list or the dmarc-discuss list. There is no reason why
>> their findings should be frustrating -- others are meeting the
>> challenge,
>
> Nice pep talk, but please, save it for the board room. If you want to
> present specific solutions, I'd love to hear about them (even if they
> don't apply directly to mailing list management).
I am not a mailing list developer, but I do try to get people involved in the
same areas of work to at least get a chance to collaborate. What you've
communicated is far better than any filtered version.
These folks take a nice and deliberate approach:
http://onlinegroups.net/blog/2014/05/01/dmarc-taking-responsibility-sending-group-email/#more-934
..different problem space, because of Mailman's huge installed & distributed
base, but at least ideas are there.
-= Tim
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
