Re: Email System Model
Alessandro Vesely <vesely@tana.it> Fri, 22 May 2009 13:42 UTC
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4MDgJsH004462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 May 2009 06:42:19 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n4MDgJiq004461; Fri, 22 May 2009 06:42:19 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n4MDg7rN004433 for <ietf-smtp@imc.org>; Fri, 22 May 2009 06:42:18 -0700 (MST) (envelope-from vesely@tana.it)
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Fri, 22 May 2009 15:41:52 +0200 id 00000000005DC02F.000000004A16ABA0.00005799
Message-ID: <4A16ABAE.3070008@tana.it>
Date: Fri, 22 May 2009 15:42:06 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: ned+ietf-smtp@mrochek.com
CC: ietf-smtp@imc.org
Subject: Re: Email System Model
References: <4A1047EB.4010708@ece.arizona.edu> <4A112228.2060501@tana.it> <4A1345B3.6040509@ece.arizona.edu> <4A13ED15.4080509@tana.it> <01N96HIIPHF000007A@mauve.mrochek.com> <4A156259.5020604@tana.it> <01N97HCA0JFM000078@mauve.mrochek.com>
In-Reply-To: <01N97HCA0JFM000078@mauve.mrochek.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>
ned+ietf-smtp@mrochek.com wrote: >>>> Externally administered backup MXes run into backscattering because >>>> they don't maintain a copy of the users database. >>> >>> Some don't, many do. > >> Hm... would you expand on that, please? I browsed a few backup MX >> providers (DydDNS, ZoneEdit and Mailfail) and saw no evidence that >> they do. > > You're looking at commercial backup provision services. Historically this isn't > how backuup MX arrangements have worked. Most of them are simply one small site > helping out another. In such cases providing a copy of your address list often > isn't a big deal. Offering backup MX services to a 98+% uptime server didn't require much resource allocation, at the time. Holding a cache copy of the users database may be slightly heavier. > In fact there's even a suggested protocol for it. I don't recall the draft > name, but it works by putting the address list in the DNS. You then use > zone transfer to move the data around and keep it up to date. I only found "Minger", Expires: January 9, 2009 http://tools.ietf.org/html/draft-hathcock-minger In short, it provides an UDP-based security-enhanced alternative to VRFY, and uses no DNS. It might have worked, but would have required a backup minger server... >> in principle, users should be aware of what organizations >> take part in managing their data. Currently, that info is relegated to >> a non-machine readable ISP's policy page, if any. > > That's ... idealistc, I must say. I doubt very much if most administrators > agree that simply the list of active addresses, with no additional attached > data whatsoever, in their domains have such serious privacy implications. Serious or not, it is what privacy laws require in several countries. While a policy page is enough for the law, I think privacy concerned users would appreciate the ability to retrieve the effective list of servers where their email addresses are stored. I agree it's an idealistic wish, and it will probably remain that way until some marketing function will say otherwise. >> The rule to strip subaddresses is a good point. Apparently, a regex >> might suffice, > > At one point I suggested using NAPTR records as part of the address > distribution protocol for secondaries in order to get exactly this effect. Is it practical to use DNS at all for this purpose? Why not LDAP, SQL, rsync, or ...? Regexes could also be passed along with other metadata, such as agreements on DNSBLs, whitelists, etcetera (and what of that can be overridden by per-user flags.)
- Re: Email System Model Alessandro Vesely
- Re: Email System Model Douglas Otis
- Re: Backup MXes (was: Re: Email System Model John C Klensin
- Backup MXes (was: Re: Email System Model Alessandro Vesely
- Re: Email System Model Russ Allbery
- Re: Email System Model ned+ietf-smtp
- Re: Email System Model Alessandro Vesely
- Re: Email System Model Arnt Gulbrandsen
- Re: Email System Model John R Levine
- Re: Email System Model ned+ietf-smtp
- Re: Email System Model John Levine
- Re: Email System Model Hector Santos
- Re: Email System Model ned+ietf-smtp
- Re: Email System Model Hector Santos
- Re: Email System Model Alessandro Vesely
- Re: Email System Model ned+ietf-smtp
- Re: Email System Model Alessandro Vesely
- Re: Email System Model David MacQuigg
- Re: Email System Model Hector Santos
- Email System Model David MacQuigg
- Re: Abort data transfer? Alessandro Vesely
- Re: Abort data transfer? ned+ietf-smtp
- Re: Abort data transfer? John C Klensin
- RE: Abort data transfer? ned+ietf-smtp
- Re: Abort data transfer? Paul Smith
- Re: Abort data transfer? Dave CROCKER
- Re: Abort data transfer? Paul Smith
- RE: Abort data transfer? Murray S. Kucherawy
- Re: Abort data transfer? Hector Santos
- Re: Abort data transfer? David MacQuigg
- Re: SMTP and DKIM/POLICY Rejection Handling [OFF … David MacQuigg
- Re: Abort data transfer? John R Levine
- Re: Abort data transfer? Hector Santos
- Re: Abort data transfer? SM
- Re: Abort data transfer? David MacQuigg
- Re: Abort data transfer? ned+ietf-smtp
- Re: Abort data transfer? ned+ietf-smtp
- Re: Abort data transfer? Hector Santos
- Re: Abort data transfer? Arnt Gulbrandsen
- RE: Abort data transfer? Murray S. Kucherawy
- Re: Abort data transfer? David MacQuigg
- Re: Abort data transfer? John R Levine
- Re: Abort data transfer? Paul Smith
- Re: Abort data transfer? John R Levine
- Re: Abort data transfer? Hector Santos
- Re: Abort data transfer? Hector Santos
- Re: Abort data transfer? Arnt Gulbrandsen
- Re: Abort data transfer? John Levine
- Re: Abort data transfer? David MacQuigg
- Re: Abort data transfer? Paul Smith
- Re: SMTP and DKIM/POLICY Rejection Handling Hector Santos
- Re: Abort data transfer? Sabahattin Gucukoglu
- Re: Abort data transfer? David MacQuigg
- Re: Abort data transfer? Hector Santos
- Re: Abort data transfer? Sabahattin Gucukoglu
- Re: Abort data transfer? SM
- Re: Abort data transfer? Arnt Gulbrandsen
- Re: Abort data transfer? David MacQuigg
- Re: SMTP and DKIM/POLICY Rejection Handling Alessandro Vesely
- Re: SMTP and DKIM/POLICY Rejection Handling Hector Santos
- Re: SMTP and DKIM/POLICY Rejection Handling Alessandro Vesely
- SMTP and DKIM/POLICY Rejection Handling Hector Santos
- Re: Abort data transfer? Hector Santos
- Re: Abort data transfer? Hector Santos
- Re: Abort data transfer? SM
- Re: Abort data transfer? Dave CROCKER
- Re: Abort data transfer? Steve Atkins
- Abort data transfer? David MacQuigg
- Re: sequential processing (was Re: Abort data tra… ned+ietf-smtp
- Re: sequential processing (was Re: Abort data tra… David MacQuigg
- Re: sequential processing (was Re: Abort data tra… Hector Santos
- sequential processing (was Re: Abort data transfe… Dave CROCKER
- RE: Abort data transfer? Murray S. Kucherawy
- Re: Abort data transfer? David MacQuigg
- RE: Abort data transfer? ned+ietf-smtp
- RE: Abort data transfer? Murray S. Kucherawy
- Re: Abort data transfer? David MacQuigg
- RE: Abort data transfer? Tony Finch
- RE: Abort data transfer? ned+ietf-smtp
- Re: Abort data transfer? John C Klensin
- Re: Abort data transfer? Tony Finch
- RE: Abort data transfer? Tony Finch