Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists

mrex@sap.com (Martin Rex) Fri, 25 April 2014 00:26 UTC

Return-Path: <mrex@sap.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D051A043A for <ietf@ietfa.amsl.com>; Thu, 24 Apr 2014 17:26:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.952
X-Spam-Level:
X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPhcySoLWQry for <ietf@ietfa.amsl.com>; Thu, 24 Apr 2014 17:26:30 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFE51A02B8 for <ietf@ietf.org>; Thu, 24 Apr 2014 17:26:30 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s3P0QNkX013788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Apr 2014 02:26:23 +0200 (MEST)
Subject: Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists
In-Reply-To: <53599E14.7070901@meetinghouse.net>
To: Miles Fidelman <mfidelman@meetinghouse.net>
Date: Fri, 25 Apr 2014 02:26:22 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <20140425002622.E6DFA1ACE0@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/eGhpZ6_5t2SNWP7YjGo85M7g9Dk
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Apr 2014 00:26:32 -0000

Miles Fidelman wrote:
> 
> Martin Rex wrote:
>> In case you didn't know or realize, what DMARC specifies for p=reject
>> is actually a real felony crime in Germany (no kidding!), and this may
>> apply to all over Europe (since the basic idea was spread out all over
>> europe with a EU directive), unless each individual receipient(!!) has
>> explicitly opted-in for this to happen.  It should be fairly easy
>> to get a cease-and-desist order against European ISPs for blocking
>> EMail on DMARC p=reject.
>
> Can you provide a legal citation?  That would be really cool!

1. Blocking EMail based on DMARC policy is illegal per §206 Abs. 2 Nr. 2 StGB.

2. Actually, even looking at rfc5322.From (rather than MAIL FROM:) for
   the purpose of looking up DMARC policy records 
   is illegal per §206 Abs. 2 Nr. 1 StGB.

3. Any DMARC-triggered reporting about forwarded emails is also illegal
   per §206 Abs. 1 StGB and §88 TKG.

And while I'm currently not sure whether the first two are similar
all over europe, the last one DEFINITELY is under the current EU data
protection directive.

Technically, EMail is an issue between a sender of a telecommunication,
a receiver of a telecommunication and a telecommunication service provider.

If an MTA is relaying (or delivering to a mailbox), then the sender is
whoever talks at the other end of the TCP connection that is used to
transfer the EMail to the MTA on port 25.  The receiver is what is
named by the sender in the RCPT TO: command (the mail contents is off limits),
and the MTA is an agent of the telecommunications provider.

What appears in the rfc5322.from of the message is legally, none of the
MTAs business.  And even if is be an attribution of authorship
of some third party in rfc5322.from, this party has absolutely no say
in what contents sender transfers to receiver.  It is also illegal
for the telecommunications service provider to reveal the fact of
this communication to other parties. This even applies to failed
communication attempts.  The only party to which the telecommunications
provider would be allowed to report a failed delivery is the address
(if any) supplied by the sender (i.e. the MAIL FROM: envelope address).


> 
>  From where I sit, it also looks like a violation of the US Computer 
> Fraud and Abuse Act (effectively, knowingly causing damage to other 
> systems - which has been applied to DDoS attacks).  But I haven't heard 
> any lawyers or prosecutors stand up and confirm that.


The DMARC policy scheme is actually censoring of a telecommunication 
between a messge sender and a message receiver through a telecommunications
provider by some _outside_ third party.  So in the US a p=reject DMARC policy
might potentially be freedom of speech (1st Amendment) violation.


-Martin