ietf
[Top] [All Lists]

Re: Will mailing lists survive DMARC?

2014-04-30 08:14:11
On 4/30/2014 7:24 AM, Alessandro Vesely wrote:

So, as a purely hypothetical set of questions (I am not
recommending anything), I wonder what would happen if some of
the people who have been claiming they or the general public are
harmed by this would, instead of asking what the IETF can do
about something that is not an IETF Standard, went to their
local "competitiveness" or "antitrust" authorities, explained
the situation and started complaining?

I'm neither a lawyer nor an ML admin, so I'm not going to claim
damage.  Yet, like most of us, I'll be harmed if MLs stop working well.


This was only a surprise to the people we were resistance to adding policy support. Author Domain Policies had the same "know your network" migration issues SPF did. Domains had to adjust by switching to more relaxed domains to participate in a public networking arena. I did the same. I remove all public usage of company's exclusive domains santronics.com and winserver.com and switched them to isdg.net where its a more relaxed author domain policy and one I can use to explore with. Everyone serious about this stuff were aware of this stuff for nearly 9 years.

Besides, it was written in the DKIM abstract with its questionable "responsibility" semantics which I kept saying it really needs to get removed or get rephrased.

   DomainKeys Identified Mail (DKIM) permits a person, role, or
   organization that owns the signing domain to claim some
   responsibility for a message by associating the domain with the
   message.

If you are going to ask domains to begin signing, put investment in it, then why would anyone thing they would not want to invest in protecting the signature, and thus the message?

The only way to do this was with the original proof of concept -- AUTHOR DOMAIN SIGNING POLICIES! Hate yelling it but is seems to be a central key point in all this forgotten.

Of course, the other argument could be that we don't want such strong and food for legal eagles semantics in our docs. We continue to face this passé mail design attitude for relaxation, incremental changes, yet, the problems do not get resolved this way. Without the strong semantics, you can't deal with the legacy abuse mail operations. You lack a payoff. DMARC has forced that "relaxed" mail design mentality to change for the IETF.

I also wonder whether the IETF and ISOC have, or should seek, legal
advice about how to keep adequate distance between themselves and
this situation should some relevant jurisdiction initiate an
investigation or enforcement action.

Rather than rebuffing responsibility, I'd expect the IETF to invent
something new, which works much like ML used to, but is compatible
with DMARC.  Yes, we may continue to call them "mailing lists".  The
alternative, to blame domains which follow the leading trend, doesn't
seem to be very promising...

They keep saying they don't think think the MLS needs to change, too historic. Its ok to add DKIM, but not Policy? I don't buy it. I'm a long time MLS developer we have hundreds of operators with list operations. It didn't make sense to me why you would add something that was half-ass complete. Probably explains I'm one of the few implementators, if not the only one, of DKIM+POLICY (ADSP, ATPS) n a mailing list server product.

Adding DMARC is not going to be a problem. It remains the same, it will be just like before with ADSP with the end of the day setup semantics:

p=reject is only for EXCLUSIVE domains for SYSTEM-WIDE application. p=quarantine is only for EXCLUSIVE domains for PER USER (junk bins) application.
    p=none       is for all, but with unknown handling.

If that is how it needs to be doc for my sysops, so be it.

The only issue would be to add a deployment option for p=reject

  [X] Enable DMARC

   (o) p=none
   (_) p=quarantine
   (_) p=reject
       (o) SMTP Reject with response ____________________
       (_) Accept and discard
       (_) Accept and keep


Or something like that.

--
HLS


<Prev in Thread] Current Thread [Next in Thread>