Re: Will mailing lists survive DMARC?

[Hector Santos <[e-mail]>]

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