Re: WSJ/gmail/ML, was a permission to...
Michael Richardson <[email protected]> Sun, 04 May 2014 15:32:57 -0400
| Newsgroups | gmane.ietf.rfc822 |
|---|---|
| Message-ID | <[email protected]> |
Hector Santos <[email protected]> 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 [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ ietf-822 mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-822
signature.asc
(application/pgp-signature, 481 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU2aV6YCLcPvd0N1lAQLaKwf6Ay49E3aibzUEt/xddu8go6EMjVYQcKcs xyu9dyWop4LieEfNnzLksy7tMxSTw9YN3eF2eszkgd/qQhwT9aoCCymIR1be+XfF j5r4RVqqD8aX2CsfToz+Cf6tAdbaLtyydV3ZpkZogF1JqKOQJ0lh+DY/sSg6KIS6 36itss0NNwrMZ3yOYYEU0lrEJu+L7abKhQaDB256JSiav2bs2ZvT9TzOme3scEP0 f38MmMQ9b6NjOBEbIT4LFxPVhtz1xxwmFKGE6wod1EqhUN1x+X+9bmsWvfkO42Nk hYo2GEdEPUD9o2XB+QZ/UnIfX0qkaHGmHM2ITGn32ce7XcyZGEf14g== =JtRH -----END PGP SIGNATURE-----