IETF Logo Mail Archive

Re: [ietf-822] WSJ/gmail/ML, was a permission to...

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 04 May 2014 19:33 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: ietf-822@ietfa.amsl.com
Delivered-To: ietf-822@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09E61A0172 for <ietf-822@ietfa.amsl.com>; Sun, 4 May 2014 12:33:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.942
X-Spam-Level:
X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] 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 jgdyuB0D0oKJ for <ietf-822@ietfa.amsl.com>; Sun, 4 May 2014 12:33:02 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id F021D1A0161 for <ietf-822@ietf.org>; Sun, 4 May 2014 12:33:01 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 179FE20028 for <ietf-822@ietf.org>; Sun, 4 May 2014 15:34:23 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id E644963ABD; Sun, 4 May 2014 15:32:57 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D442163AB6 for <ietf-822@ietf.org>; Sun, 4 May 2014 15:32:57 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: ietf-822@ietf.org
In-Reply-To: <536687F5.2040503@isdg.net>
References: <20140418123721.3610.qmail@joyce.lan> <5365357D.2020101@tana.it> <53653C7A.3090304@pscs.co.uk> <53655C13.9070201@isdg.net> <6116.1399163723@sandelman.ca> <536687F5.2040503@isdg.net>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Sun, 04 May 2014 15:32:57 -0400
Message-ID: <12781.1399231977@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-822/HyQi4RJf2xgZrHsw6t4SHmrkXHQ
Subject: Re: [ietf-822] WSJ/gmail/ML, was a permission to...
X-BeenThere: ietf-822@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of issues related to Internet Message Format \[RFC 822, RFC 2822, RFC 5322\]" <ietf-822.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-822/>
List-Post: <mailto:ietf-822@ietf.org>
List-Help: <mailto:ietf-822-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 May 2014 19:33:04 -0000

Hector Santos <hsantos@isdg.net> wrote:
    > On 5/3/2014 8:35 PM, Michael Richardson wrote:

    >> So, how in the world does this scale to having thousands of "trusted"
    >> mailing lists?  Seriously.

    > We won't know if we don't try it.  Of course, there is a management
    > issue, but its doable. Simple but new DNS tools are needed. Surely, DNS
    > is robust enough it.

Uhm, there is a limit on how big a TXT record can be.
As far as I can see, I have to list all the mailing lists into asl=

    > It would not fit within a "asl=" tag list of course, but ATPS records
    > would be used for a larger scale.  For example, for isdg.net I have the
    > following records:

    > _adsp._domainkey TXT ( "dkim=all; atps=y;
    > asl=ietf.org,beta.winserver.com,santronics.com,isdg.net,winserver.com,megabytecoffee.com,mapurdy.com.au,mipassoc.org,gmail.com,googlegroups.com;"

    > e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT ( "v=atps01;
    > d=megabytecoffee.com;" ) jchjykxmwknbyfge2bg4td6add264olh._atps TXT (
    > "v=atps01; d=winserver.com;" ) kjshf2duqstols65zbhuytbbyr3zdecf._atps
    > TXT ( "v=atps01; d=gmail.com;" ) n3lsehml2wgbfxov7hsak2qzsubsefhb._atps
    > TXT ( "v=atps01; d=mipassoc.org;" )
    > pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ( "v=atps01; d=ietf.org;" )
    > q42vdaxs6p26zflt3hcvqey3zp5aivxj._atps TXT ( "v=atps01; d=isdg.net;" )
    > rni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT ( "v=atps01;
    > d=mapurdy.com.au;" ) tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT (
    > "v=atps01; d=santronics.com;" )

    > Can DNS handle 30,000 for a zone file?  No problem.

Yes, but that's not the place there is a scaling problem.

    >> I was thinking that a (list) machine, receiving a signed message with
    >> p=reject, would respond with some new 3xx code that would say, "great,
    >> I'd love to help you, but you didn't delegate to me....", and then
    >> include some transactional part that would help the right
    >> authorization occur.  Perhaps going back to the *user* to confirm.

    > Yes, it would be one deployment option.

    > The IETF should be documenting the practical possible deployment
    > options for a SMTP REJECT protocol semantic without the lost of
    > security. The alternative options provide the same security protection
    > to the end-user -- no harm, which I think includes:

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email