Re: DMARC from the perspective of the listadmin of a bunch of SMALL comm

Thanks for the citation!  Also see below...

Martin Rex wrote:
> 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.
Not 1st amendment - as others pointed out, it's not an action of Government.

To elaborate on the CFAA, however - I copied this from: 
http://www.technicallylegal.org/the-legality-of-denial-of-service-attacks/ 
-- it's from a discussion of what laws might apply against a DDoS 
attack, but it sure seems to sound like what those who set DMARC 
p=reject are doing:

In terms of criminal violations, there’s the Computer Fraud and Abuse 
Act <http://en.wikipedia.org/wiki/Computer_fraud_and_abuse_act> (the 
“CFAA”), which prohibits a person from “knowingly caus[ing] the 
transmission of a program, information code, or command, and as a result 
of such conduct, intentionally causes damages without authorization to a 
protected computer” (see 18 U.S.C. § 1030(a)(5)(A) 
<http://www.law.cornell.edu/uscode/html/uscode18/usc_sec_18_00001030----000-.html#a_5>). 
The requisite “damage” element under the CFAA is “any impairment to the 
integrity or availability of data, a program, a system, or information” 
(see 18 U.S.C. § 1030(e)(8) 
<http://www.law.cornell.edu/uscode/html/uscode18/usc_sec_18_00001030----000-.html#e_8>) 
and a “protected computer” is defined as a computer “which is used in or 
affecting interstate or foreign commerce, including a computer located 
outside the United States that is used in a manner that affects 
interstate or foreign commerce or communication” (see 18 U.S.C. § 
1030(e)(2)(B) 
<http://www.law.cornell.edu/uscode/html/uscode18/usc_sec_18_00001030----000-.html#e_2>). 

DoS attacks almost unquestionably fall under the broadly-worded 
prohibited activity in this portion of the CFAA (“transmitting … 
information, code, or command”) and would likely meet the low standard 
of damage (“any impairment to the integrity or availability of data, 
program, system, or information”). The CFAA may also apply to 
unsuccessful attempts (see 18 U.S.C. § 1030(b) 
<http://www.law.cornell.edu/uscode/html/uscode18/usc_sec_18_00001030----000-.html#b>).
The CFAA also has a civil component that permits “[a]ny person who 
suffers damage or loss by reason of a violation of this section may 
maintain a civil action against the violator to obtain compensatory 
damages and injunction relief.” In other words, the target of the DoS 
attack can sue the individual(s) who were responsible for the damages 
incurred as a result of the attack (e.g., server downtime, costs to 
repair, and in some lost revenue (see 18 U.S.C. § 1030(g) 
<http://www.law.cornell.edu/uscode/html/uscode18/usc_sec_18_00001030----000-.html#g>). 
There is a limitation that requires the damages exceed $5,000; however, 
some courts have liberally construed its calculation to include 
consultation services (e.g., IT/security persons) used to assess the 
extent of damage caused by the attack.  Also, this provision does not 
require that a person ever be convicted before being sued for damages.
--------
That last paragraph kinda makes me think about a civil lawsuit :-)




--
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra