From nobody Sat Aug 1 05:56:58 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA511B2E56 for ; Sat, 1 Aug 2015 05:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 QCGXmjPiylQg for ; Sat, 1 Aug 2015 05:56:55 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C621A00C7 for ; Sat, 1 Aug 2015 05:56:55 -0700 (PDT) Received: by ykek23 with SMTP id k23so6173331yke.0 for ; Sat, 01 Aug 2015 05:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OQMlUPA9b7vqhSQNBl1sGFmW3pawBZ2eLqBYzKo4acE=; b=O3i2a5TRhJ2RYc/bYSOej0bqNjz4F/RMPqS8H+5zv6C9sR6v4dc7zXRLAeK4RNk8Mm SS9qL2F+d7rbTSZA8yUEd4+Dv5Klk62AM3QSFrQJqojwkQHcetvtyM/X4eqZpWSDTwZX xqizg/NFhA6yzpxpRT5U815qBfUBQuwloHJaGxpzpPLX57hvsVJiaZ438QtPfVkfqbPN w3ICu1KLjx6a8/NIPPzMGTjL709girW/5UHeW0gxTo0XSFuy82NhzunYSmcQuLqoENgD wqDJ7Bk9WDMULBuq7vS1SkXkWoKM3xeybq+BQTfSbyVYEd7H1038cMJFvKEexyxlwQ6M GRaw== MIME-Version: 1.0 X-Received: by 10.170.203.215 with SMTP id u206mr9635327yke.116.1438433814856; Sat, 01 Aug 2015 05:56:54 -0700 (PDT) Received: by 10.37.209.214 with HTTP; Sat, 1 Aug 2015 05:56:54 -0700 (PDT) Date: Sat, 1 Aug 2015 13:56:54 +0100 Message-ID: From: Nik Tomkinson To: slim@ietf.org Content-Type: multipart/alternative; boundary=001a1139e4da9149b4051c3f7808 Archived-At: Subject: [Slim] multipart/multilingual spam filtering X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 12:56:57 -0000 --001a1139e4da9149b4051c3f7808 Content-Type: text/plain; charset=UTF-8 Hi all, there were a couple of things I wanted to discuss at the lunch meeting in Prague, but we ran out of time. In the interests of clarity I will keep them to individual list posts. Here is the first: On the M3AWG senders list, a situation was discussed whereby a spam subject may be able to get through a spam filtering service. The situation would need to be as follows: - a non-conforming spam filtering service combined with a conforming email client A spam filter service that is not aware of multipart/multilingual might use the top-level subject header field ONLY to determine if the email is spam, which passes through. The email client (which IS aware of multipart/multilingual) would render the lower-level translated subject field (in the matched language message part) in a message listing to be seen by the recipient. For all other combinations of conforming/non-conforming status for email client and spam filter, a multipart/multilingual message would be fine as the spam subject would either be checked correctly or not displayed. If the spam filter service checks the whole message content, the message is likely to be rejected unless it is ONLY the subject that could cause offence. So the question is, how should this be represented in the I-D for multipart/multilingual email? Can it be seen as an edge case and that it will only be an issue until spam filtering checks lower-level subjects too? Therefore could it just be mentioned in the security considerations section? or should there be some rework to close this small hole? Thanks in advance, Nik. --001a1139e4da9149b4051c3f7808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

there were a couple = of things I wanted to discuss at the lunch meeting in Prague, but we ran ou= t of time. In the interests of clarity I will keep them to individual list = posts. Here is the first:


On the M3= AWG senders list, a situation was discussed whereby a spam subject may be a= ble to get through a spam filtering service. The situation would need to be= as follows:

=C2=A0- a non-conforming spam filteri= ng service combined with a conforming email client

A spam filter service that is not aware of multipart/multilingual might us= e the top-level subject header field ONLY to determine if the email is spam= , which passes through. The email client (which IS aware of multipart/multi= lingual) would render the lower-level translated subject field (in the matc= hed language message part) in a message listing to be seen by the recipient= .

For all other combinations of conforming/non-con= forming status for email client and spam filter, a multipart/multilingual m= essage would be fine as the spam subject would either be checked correctly = or not displayed.

If the spam filter service check= s the whole message content, the message is likely to be rejected unless it= is ONLY the subject that could cause offence.

So = the question is, how should this be represented in the I-D for multipart/mu= ltilingual email?

Can it be seen as an edge case a= nd that it will only be an issue until spam filtering checks lower-level su= bjects too? Therefore could it just be mentioned in the security considerat= ions section? or should there be some rework to close this small hole?

Thanks in advance,

Nik.
=

--001a1139e4da9149b4051c3f7808-- From nobody Sat Aug 1 15:35:56 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AECE1A7018 for ; Sat, 1 Aug 2015 15:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.887 X-Spam-Level: X-Spam-Status: No, score=0.887 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01] autolearn=no 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 bHbH04_t6dWz for ; Sat, 1 Aug 2015 15:35:54 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1397F1A7017 for ; Sat, 1 Aug 2015 15:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:References:Message-Id:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=szx4+/RW0yza7zb5OnvavM9sFcn2sy7BKi6FkIaTaIQ=; b=kFsLnpiOxsjHd1lZXXS/aY7skpQHKEYWc8xk1FMQJE/5H92iUfYlY5BoxqsT+y6meaiH+0FfkHdm9AEAHOppMaqJ7U5mIT1C6vBJqM1eKrBsoJO/854r+FyyT1lksKEryUmF21wHwBiAsaPnBgDezORa/wOsBkM6eahq7NZJ0K8=; Received: from ip68-100-196-239.dc.dc.cox.net ([68.100.196.239]:62498 helo=[192.168.15.107]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZLfNg-0008Iy-Ji for slim@ietf.org; Sat, 01 Aug 2015 15:35:53 -0700 Content-Type: multipart/signed; boundary="Apple-Mail=_513C1B35-2DC5-4990-9437-0F794F620A55"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Pgp-Agent: GPGMail 2.5 From: Eric Burger In-Reply-To: Date: Sat, 1 Aug 2015 18:35:51 -0400 Message-Id: <1420BF93-49C5-4F9A-917D-18023BEE3453@standardstrack.com> References: To: slim@ietf.org X-Mailer: Apple Mail (2.2102) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed Archived-At: Subject: Re: [Slim] multipart/multilingual spam filtering X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2015 22:35:55 -0000 --Apple-Mail=_513C1B35-2DC5-4990-9437-0F794F620A55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m not on the M3AWG list, but I would be shocked if a spam = filter called itself a spam filter by reading only the subject line of = the message. I think the market would bankrupt such a vendor. So, we do = not need to worry about it. > On Aug 1, 2015, at 8:56 AM, Nik Tomkinson = wrote: >=20 > Hi all, >=20 > there were a couple of things I wanted to discuss at the lunch meeting = in Prague, but we ran out of time. In the interests of clarity I will = keep them to individual list posts. Here is the first: >=20 >=20 > On the M3AWG senders list, a situation was discussed whereby a spam = subject may be able to get through a spam filtering service. The = situation would need to be as follows: >=20 > - a non-conforming spam filtering service combined with a conforming = email client >=20 > A spam filter service that is not aware of multipart/multilingual = might use the top-level subject header field ONLY to determine if the = email is spam, which passes through. The email client (which IS aware of = multipart/multilingual) would render the lower-level translated subject = field (in the matched language message part) in a message listing to be = seen by the recipient. >=20 > For all other combinations of conforming/non-conforming status for = email client and spam filter, a multipart/multilingual message would be = fine as the spam subject would either be checked correctly or not = displayed. >=20 > If the spam filter service checks the whole message content, the = message is likely to be rejected unless it is ONLY the subject that = could cause offence. >=20 > So the question is, how should this be represented in the I-D for = multipart/multilingual email? >=20 > Can it be seen as an edge case and that it will only be an issue until = spam filtering checks lower-level subjects too? Therefore could it just = be mentioned in the security considerations section? or should there be = some rework to close this small hole? >=20 > Thanks in advance, >=20 > Nik. >=20 > _______________________________________________ > SLIM mailing list > SLIM@ietf.org > https://www.ietf.org/mailman/listinfo/slim --Apple-Mail=_513C1B35-2DC5-4990-9437-0F794F620A55 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVvUnHAAoJEORoZaSQsc1I9I4P/0AxDfUL0G8aSOx29O4kdvq3 f5SpmJcGCBDTwACrdOmnSw/S960Xrvz7iSaiOH1/npcyv6FsbdnHwrsLAo7EFTei DwN0488v7h7Hp0IVhtQrDLhWGyJtzgCI1ngk6WQXyt5k2Ti9D3bAqNnm7h+uQHIb 912ZsLYrI28iqdxDJoT4EDyEobdACSlth6JwCZZVGvtpwztpizIzze40daVYyGgU jiJ55PGnbPr1lXAs1dYCyyRB6cEaTdPHs/7OpGqQQqEvNlLT811baXYAXcLqOYXb D957Ocp7oviBByyCNHYPgX8YTGUObucUzeQbg1/9WDwxSXeNIskNYs66J9Rr46gd q+7YNA9cv/Gs/CIQdJJcN5pfk1RZ1UwTKhs4V7f3kySNlvUPQZjVgGL5qwHzKNtM u3DQzOLq9J0Ryds7wTn6qyf11V6X3YbxOZpE+6qsk4M7pxr+eBfVFhkDwtXGyXoA oTifET3Nfbvg3i952bxB47a9uiYMd9TfLv0fwe2g1j5vkf2lmLu8dz0/3CAPmg+y jZ/w7zjpLFhvPz7SJWn1YSrJh/6mYwyFPzXBmELYhp4BLOksByon6A3PP55a+XLN 0P4hTRJFUpmZd2OKsnk7f5aLSuqBU4H3/SDZRTME7NvA0gApu4+p3ohzXkRonNd/ pyHGGF5fJ8GpLlqv/7xa =NUO5 -----END PGP SIGNATURE----- --Apple-Mail=_513C1B35-2DC5-4990-9437-0F794F620A55-- From nobody Fri Aug 14 02:05:50 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746621A8790 for ; Fri, 14 Aug 2015 02:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 yekDkubwltFx for ; Fri, 14 Aug 2015 02:05:47 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3C971A8770 for ; Fri, 14 Aug 2015 02:05:47 -0700 (PDT) Received: by ykek5 with SMTP id k5so11597329yke.2 for ; Fri, 14 Aug 2015 02:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=W+F6SzLRVRjMUkynp1W/0WUCek5qq74d4foFJPns26U=; b=e0XXLqmkGG41oc16mnZAUfA5iGgPjBl4biuxpJd6KjEiZxgr1cNPYUlmghpZomqNUo 7hPRm3+ueQTa+fPcOvpdo2eIW3nlQ455WPyNfU8OQsC1soKNZSK0V3aFyZ1lC5HtemOO QnIxBoSCVWuzdaP3zyrACqBizTyZ3XmNlqaJcCDIV9ElEvMIkHSO0IZ8rEAenNgVdmWp yXglmjF/LXZZ5S6cPbjS5HBD9epAdA+XodlHTKqQR2MH2Giq78Vbe61rznB1kYCywk8Y kQQIms7tRAbTqVVem8rEQIe2E9iAqrjp2R0oVQXXxZlmKgMuZf9leY0Fd7FcNpD5L+Fp yF2w== MIME-Version: 1.0 X-Received: by 10.13.199.195 with SMTP id j186mr43442848ywd.112.1439543147164; Fri, 14 Aug 2015 02:05:47 -0700 (PDT) Received: by 10.37.216.19 with HTTP; Fri, 14 Aug 2015 02:05:47 -0700 (PDT) Date: Fri, 14 Aug 2015 10:05:47 +0100 Message-ID: From: Nik Tomkinson To: slim@ietf.org Content-Type: multipart/alternative; boundary=001a114e61aeecfbcc051d41c11f Archived-At: Subject: [Slim] non-real-time: Translation-Type as parameter of Content-Language not a separate field X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 09:05:49 -0000 --001a114e61aeecfbcc051d41c11f Content-Type: text/plain; charset=UTF-8 Hi, After a suggestion by Randy, I am thinking that the new Translation-Type field that appears in each of the language message parts may be better suited to being a parameter of the existing Content-Language field. There are a number of reasons for this: - the Translation-Type field is coupled to the Content-Language field to some extent because the Translation-Type value is only applicable where the Content-Language value is also applicable - they both concern the language that a piece of the message content is in so they are naturally related - there are no additional issues with having multiple languages combined with multiple translation types than there were with two separate fields - I don't think that there will be any backwards compatibility issues with existing implementations of Content-Language as it would be a new parameter For example: Content-Language: en; translation-type=original instead of: Content-Language: en Translation-Type: original So, does anyone have any compelling reason that I may have missed why this is not a better solution? If not, I will adjust the I-D accordingly. Thanks in advance, Nik. -- ----------------------------------------------------------------- Multiple Language Content Type Internet Draft: http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangcontent/ ----------------------------------------------------------------- --001a114e61aeecfbcc051d41c11f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

After a suggestion by Ra= ndy, I am thinking that the new Translation-Type field that appears in each= of the language message parts may be better suited to being a parameter of= the existing Content-Language field. There are a number of reasons for thi= s:

=C2=A0- the Translation-Type field is coupled t= o the Content-Language field to some extent because the Translation-Type va= lue is only applicable where the Content-Language value is also applicable<= /div>
=C2=A0- they both concern the language that a piece of the messag= e content is in so they are naturally related
=C2=A0- there are n= o additional issues with having multiple languages combined with multiple t= ranslation types than there were with two separate fields
=C2=A0-= I don't think that there will be any backwards compatibility issues wi= th existing implementations of Content-Language as it would be a new parame= ter

For example:

Content-= Language: en; translation-type=3Doriginal

instead = of:

Content-Language: en
Translation-Typ= e: original


So, does anyone have an= y compelling reason that I may have missed why this is not a better solutio= n? If not, I will adjust the I-D accordingly.
=C2=A0
Th= anks in advance,

Nik.

--
<= div class=3D"gmail_signature">
<= div dir=3D"ltr">
----=
-------------------------------------------------------------
Multiple L=
anguage Content Type Internet Draft:
http://datatracker.ietf.org/doc/draft-tomkinson-slim-multilangconten= t/
----------=
-------------------------------------------------------
--001a114e61aeecfbcc051d41c11f-- From nobody Mon Aug 31 10:26:52 2015 Return-Path: X-Original-To: slim@ietfa.amsl.com Delivered-To: slim@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B921B34E2; Mon, 31 Aug 2015 10:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 EvRyIOq7qLlX; Mon, 31 Aug 2015 10:26:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C3D1B34D3; Mon, 31 Aug 2015 10:26:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150831172649.24130.91024.idtracker@ietfa.amsl.com> Date: Mon, 31 Aug 2015 10:26:49 -0700 From: IETF Secretariat Archived-At: Subject: [Slim] Telechat update notice: X-BeenThere: slim@ietf.org X-Mailman-Version: 2.1.15 List-Id: Selection of Language for Internet Media List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 17:26:50 -0000 Telechat date has been changed to 2015-09-17 from 2015-07-09 ID Tracker URL: https://datatracker.ietf.org/doc/charter-ietf-slim/