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