Re: OT Brainstorm: Email Validation among different systems

David F. Skoll wrote:
> Hector Santos wrote:
>
> > My point here is simply that a professional AVS email security service
> > bureau will most likely have and offer (if they want the business) a
> > "interface" specification such as http://www.virtualconnect.net which
> > allows the operator to update their list of valid users via an email
> > automated fashion.
> Ponder the security risks of such an implementation.
Like what?

I could imagine there is always security risk everywhere. But this is a 
100% trusted private exchange and thus lean more on an internal security 
threat, not external, if there is going to be a problem.  Also, I would 
imagine a broken or cancel contract will prohibit the service bureau 
from selling or using the email list any further.  I doubt a legitimate 
service would risk a bad reputation by abusing customer trust.  Not 
worth it.  But I can't tell ya, because we never experienced any 
customer security related issue or problem with our export tool. :-)
If it wasn't obvious, the operator always had the ability to export 
their user accounts.  But this tool was a simulation output of a real 
dynamic  SMTP level validation.  That means all the translations, 
aliases, mailing list names, administrative names, any other special 
names that would be normally be valid at SMTP is outputted.
Example, user account is "David Scroll", there could be 1 or 20 valid 
SMTP level addresses that represent "David Scroll" and this would be 
outputted by the tool.
> DNS has proven pretty scalable, I reckon. :-)  
Well, it depends how widely popular it would be and also how might the 
databases. But I would think the larger it is, the more likely the 
customer would not need other people services. :-)
> As another poster mentioned,
> you could look up the hash of an address to reduce information exposure.
>
> > Who would create/maintain the zone?
> If example.com publishes an MX record, then example.com could equally
> publish e-mail validation records.
Let me put it this way, speaking for myself, lets just say, I have a 
very strong ethical philosophical engineering delima with the idea of 
publicly exposing user information, especially in large database 
amounts.  The concept is well understood (at least to me and its not the 
first time the DNS based "userid" idea has been explored.  Unless it is 
coupled with a client access concept, negotiated authorization, 
permission, public/private or secret key, what have you, I would be 
interested in seeing your proposal. Otherwise, I won't touch it.  But 
thats just me. :-)
Lets see, why not use existing user validation LDAP? RADIUS?  Existing 
protocols. DKIM also has some user-level authentication, which I believe 
has been put on the back burner.
> Your server incorrectly claims an SPF failure for:
Correct. That was the goal of the example. The IP input was my address 
using your address - SPF rejected it as expected.
> But that's ad-hoc and isn't what I'm talking about.  I'm talking about
> a way to validate RECIPIENT addresses.
Of course. Simply pointing out more than one way to skin a cat.  Trying 
to keep your mind open here. :-)  This Secondary MX services were borne 
yesterday.  These needs were already addressed.  Personally, I have a 
problem with exposing my user database or suggesting to customers to 
expose their user database via DNS - I prefer to do that in a very 
exclusive trust exchange environment - not publicly, opening it up to 
MDx/SHaX security threat hacking exploits.
Consider, that for many old school systems, such as ours when users 
accounts are created, and email service is provided, we use a choice of 
old school Novell's MHS naming convention or an old school straight 
forward user account to email translation:
    first last -->  first(_dot_)last(_at_)localhost_domain(_dot_)com

So right there that is HALF the battle for guessing user login names. 
Not everyone uses "email addresses" to login.
Anywho, I think the only value from this exercise, at least for 2821bis 
is a possible consideration to talk about persistent SMTP behavior for 
multiple MX environments.  That that is best advice it can give, IMO.
But I will still love to see your DNS-VRFY I-D proposal! <g>

--
HLS