Re: [Tools-discuss] Why is inline CSS editing on IETF mailing lists?

"Martin Thomson" <mt@lowentropy.net> Mon, 04 November 2019 03:37 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: tools-discuss@ietfa.amsl.com
Delivered-To: tools-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE341200FD for <tools-discuss@ietfa.amsl.com>; Sun, 3 Nov 2019 19:37:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Gwfwi9Z6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Amact8DT
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 qYJdYdHIPStX for <tools-discuss@ietfa.amsl.com>; Sun, 3 Nov 2019 19:37:38 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBE7B120129 for <tools-discuss@ietf.org>; Sun, 3 Nov 2019 19:37:38 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 01E7C20D7C for <tools-discuss@ietf.org>; Sun, 3 Nov 2019 22:37:38 -0500 (EST)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sun, 03 Nov 2019 22:37:38 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=XXkC8 Y7KRVeLSPbbseBHuRY00HCalfRGCiGXzLWYfjc=; b=Gwfwi9Z6NuDOpR3U50D/M XnvitIo9tJSmoVd3AtHFvX/4ur51GXvzIr/EBHqnCG7cfox+XzQT7Of1Tz81uZWc QDROJp8lIlH5QfENfIntSQsFzN0qcxZmryKwkdcsOxG8b3/VLWJBURgn0e6IjVTy rTU8Dj/+e78Hll96M5//00EXZvLlwsD3AtyCeIvSyjNkQnxQzn0luFtftXxfOw/c BDyjbD1Tg7QTpljk5wzTQ5fqaTi4nt9RA1ipE2vzUNEuLyXdWA0UwHbhKAIWOM2O QwYaD2jrgdnAe5WreHXPyAsUvw7pQCBA4NntNreQ8/zsnhwQa6JLNgzBQYxvJNiU g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=XXkC8Y7KRVeLSPbbseBHuRY00HCalfRGCiGXzLWYf jc=; b=Amact8DTUAqCM4SMnAG/n3W3JHT2FMdU2Wz02tj6rXgYU9GOC7RE1YAEJ WmGdQE1wusuQip224bqbgT6R1oAYSMUEjex9uh6ZbsT7NQ47ro83Wjh2RBeccLAN 6AwMpapM9m7veNtmIusijAXwYgz14Rf6b8gQ822dzHXpvc1eUVZG2mZzQRJTkGFv S7wpFg7Be+99GwrpMCiJhkMG/vSaDp5Fs2J2pY42Na6t/ekXt8ygLUuFWnF6adk4 FdQVOrxCeMFT4EPPAGCi6tYroIKniIGh1pWsDy/gHW5Fg5FQ+B6Jzs57xKo4osaF 2w5/fKLRfMWrrY07yz93+0NAlDJ7g==
X-ME-Sender: <xms:AZ2_Xd2MRsxmqW_KCUFgEvecpgzXANB29aQsfZl92MMAdg01_ZVydw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudduvddgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpeiffedrohhrghdpghhithhhuh gsrdgtohhmpdhivghtfhdrohhrghdpmhhnohhtrdhnvghtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivg epud
X-ME-Proxy: <xmx:AZ2_XVUJLnptSAhIn6OJ2L-m7gKeiyCiuw-7z38oj792edjRhOPJlw> <xmx:AZ2_XTMS-P8TgbU_zrdlQT9UHuDoG0b-HlHmVIXXfh7yYGhbHwcoPw> <xmx:AZ2_XYwjNq2oNP9w8qM4ZS0d8IuCmGiU909R4QHRLWETYo8WghyOTg> <xmx:AZ2_XUFolRuIDbdZOGnxAepSpO4C2cXoY6X_eT-CRqHxbayFbTpCgA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id A6471E00A3; Sun, 3 Nov 2019 22:37:37 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1
Mime-Version: 1.0
Message-Id: <610fdd00-ee38-4123-831f-750cf5161af7@www.fastmail.com>
In-Reply-To: <0B32A612-6F45-48A1-96BC-28FCB247870B@mnot.net>
References: <20191103073305.BE125306005C@mailuser.nyi.internal> <0B32A612-6F45-48A1-96BC-28FCB247870B@mnot.net>
Date: Mon, 04 Nov 2019 14:37:18 +1100
From: Martin Thomson <mt@lowentropy.net>
To: tools-discuss@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tools-discuss/N54G6258tYjhS4YQqth0Qkp--1M>
Subject: Re: [Tools-discuss] Why is inline CSS editing on IETF mailing lists?
X-BeenThere: tools-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Tools Discussion <tools-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tools-discuss/>
List-Post: <mailto:tools-discuss@ietf.org>
List-Help: <mailto:tools-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tools-discuss>, <mailto:tools-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Nov 2019 03:37:41 -0000

I've seen an extra dot on numerous occasions, so this isn't just HTML mail.  It often causes problems for me when it appears in URLs.

On Mon, Nov 4, 2019, at 08:09, Mark Nottingham wrote:
> Hi,
> 
> I've noticed that mail sent to IETF lists appears to have its inline 
> CSS edited; in the message below, an extra "." is prefixed onto these 
> rules, with the effect that they aren't applied:
> 
> > ..repos { margin-bottom: 0; margin-top:0; line-height: 1.2; }
> > ..new { color: red; }
> > ..label { display: inline;
> > padding: .2em .6em ..3em;
> > font-size: 75%;
> > font-weight: 700;
> > line-height: 1;
> > color: #fff;
> > text-align: center;
> > white-space: nowrap;
> > vertical-align: baseline;
> > border-radius: .25em;
> > }
> 
> Compare with 
> <https://www.w3.org/mid/20191103073300.39B0780061@mailuser.nyi.internal>.
> 
> Cheers,
> 
> > Begin forwarded message:
> > 
> > *From: *Repository Activity Summary Bot <do_not_reply@mnot.net>
> > *Subject: **Weekly github digest ( Activity Summary)*
> > *Date: *3 November 2019 at 6:33:05 pm AEDT
> > *To: *quic@ietf.org
> > *Archived-At: *<https://mailarchive.ietf.org/arch/msg/quic/1AuiZGyvn5u07O-obAlXV6-AooM>
> > 
> > Sunday November 03, 2019
> 
> > Events without label "editorial"
> 
> > Issues
> 
> > quicwg/base-drafts (+1/-9/💬28)
> 
> > 1 issues created:
> 
> >  * #3179 Duplicate NEW_TOKEN should only be on same connection <https://github.com/quicwg/base-drafts/issues/3179> (by mikkelfj) 
> > 5 issues received 28 new comments:
> 
> >  * #3173 TLS MUST NOT deliver server 1RTT Rx keys until getting Finished <https://github.com/quicwg/base-drafts/issues/3173> (10 by ghedo, kazuho, martinduke) -tls
> >  * #3159 Server should not accept 1-RTT traffic before handshake completion <https://github.com/quicwg/base-drafts/issues/3159> (11 by ad-l, ghedo, ianswett, mikkelfj) -tls
> >  * #3155 The method of identifying "the same server" <https://github.com/quicwg/base-drafts/issues/3155> (2 by kazuho, mikkelfj) -transport design proposal-ready
> >  * #3151 loss detection timer description could be simplified by definining a timer mode <https://github.com/quicwg/base-drafts/issues/3151> (4 by ianswett, janaiyengar, marten-seemann) -recovery
> >  * #3135 allow sending PADDING after receiving a non-ack-eliciting packet <https://github.com/quicwg/base-drafts/issues/3135> (1 by mnot) -transport
> > 9 issues closed:
> 
> >  * #3041 kMaxDatagramSize should use the PMTU rather than be fixed <https://github.com/quicwg/base-drafts/issues/3041> -recovery design
> >  * #2928 Lift single-packet ClientHello requirement? <https://github.com/quicwg/base-drafts/issues/2928> -tls design has-consensus
> >  * #2823 Do Initial secrets change after Retry packet? <https://github.com/quicwg/base-drafts/issues/2823> -tls design has-consensus
> >  * #3046 Handling of Retire Prior To field <https://github.com/quicwg/base-drafts/issues/3046> -transport design has-consensus
> >  * #3085 Stateless reset detection should be datagram-based <https://github.com/quicwg/base-drafts/issues/3085> -transport design has-consensus
> >  * #2152 Why does stateless reset have to be checked after MAC failure <https://github.com/quicwg/base-drafts/issues/2152> -transport design has-consensus
> >  * #3097 Is CONNECTION_CLOSE ACK-eliciting? <https://github.com/quicwg/base-drafts/issues/3097> -recovery -transport design has-consensus
> >  * #2741 Re-visit initial keys discard <https://github.com/quicwg/base-drafts/issues/2741> -tls -transport design has-consensus
> >  * #2944 Layout of PreferredAddress <https://github.com/quicwg/base-drafts/issues/2944> -transport design has-consensus
> > Pull requests
> 
> > quicwg/base-drafts (+3/-5/💬14)
> 
> > 3 pull requests submitted:
> 
> >  * #3183 Limit CWND increase in slow start <https://github.com/quicwg/base-drafts/pull/3183> (by ianswett) -recovery
> >  * #3182 Add an enum indicating the timer_mode <https://github.com/quicwg/base-drafts/pull/3182> (by ianswett) -recovery
> >  * #3178 token-based greasing / initial packet protection (downgradable variant) <https://github.com/quicwg/base-drafts/pull/3178> (by kazuho) 
> > 8 pull requests received 14 new comments:
> 
> >  * #3183 Limit CWND increase in slow start <https://github.com/quicwg/base-drafts/pull/3183> (2 by ianswett, janaiyengar) -recovery
> >  * #3182 Add an enum indicating the timer_mode <https://github.com/quicwg/base-drafts/pull/3182> (2 by ianswett, marten-seemann) -recovery
> >  * #3166 token-based greasing / initial packet protection <https://github.com/quicwg/base-drafts/pull/3166> (1 by kazuho) -transport design
> >  * #3120 Add retry integrity tag <https://github.com/quicwg/base-drafts/pull/3120> (3 by kazuho, martinthomson, mikkelfj) -tls -transport
> >  * #3099 Idle timeout indicates you will timeout <https://github.com/quicwg/base-drafts/pull/3099> (1 by ianswett) -transport
> >  * #3066 Change PTO to be per packet number space <https://github.com/quicwg/base-drafts/pull/3066> (1 by marten-seemann) -recovery design
> >  * #3050 Rewrite key update section <https://github.com/quicwg/base-drafts/pull/3050> (3 by DavidSchinazi, martinthomson) -tls design
> >  * #3042 Use the FRAME_ENCODING_ERROR for errors in frame encoding <https://github.com/quicwg/base-drafts/pull/3042> (1 by martinthomson) -transport design
> > 5 pull requests merged:
> 
> >  * #3167 kMaxDatagramSize -> max_datagram_size <https://github.com/quicwg/base-drafts/pull/3167> -recovery
> >  * #3045 Allow ClientHello to span multiple QUIC packets <https://github.com/quicwg/base-drafts/pull/3045> -tls
> >  * #3096 MUST retire Connection IDs becoming stale <https://github.com/quicwg/base-drafts/pull/3096> -transport design
> >  * #2993 Stateless reset comparisons (constant time/any order/datagram) <https://github.com/quicwg/base-drafts/pull/2993> -transport design
> >  * #3098 CONNECTION_CLOSE is non-ack-eliciting <https://github.com/quicwg/base-drafts/pull/3098> -recovery -transport design
> > Repositories tracked by this digest:
> 
> >  * https://github.com/quicwg/base-drafts
> 
> --
> Mark Nottingham https://www.mnot.net/
> 
> ___________________________________________________________
> Tools-discuss mailing list
> Tools-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> Please report datatracker.ietf.org and mailarchive.ietf.org
> bugs at http://tools.ietf.org/tools/ietfdb
> or send email to datatracker-project@ietf.org
> 
> Please report tools.ietf.org bugs at
> http://tools.ietf.org/tools/issues
> or send email to webmaster@tools.ietf.org
>