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.)