David F. Skoll wrote:
Hector Santos wrote:
If both the primary and secondary MX servers are administered by the
same organization or by closely-cooperating organizations, this works
well. However, there are ISPs that offer "secondary MX service" to
their customers, and they are unlikely (or sometimes unable) to make
special arrangments to synchronize user lists.
We offer a special utility to our customers who subscribe to these
secondary MX services which allows them to export their user email
addresses, translations, aliases, etc, which is then sent to the
service.
That's a neat feature, but an ISP that needs to support dozens of
different SMTP servers and many different ways of maintaining
user lists is still not going to be happy. A standard way to do
this sort of thing would be welcome.
I see your valid point.
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. Here is the VirtualConnect.tpl template for this service:
From: @from@
Date: @rfcdate@
Subject: @domain@ @date1@ @time1@
Message-Id: <@mid@>
To: @to@
X-Note: <insert password>
@body@
where the body is just a list of the valid addresses. Very simple idea.
Perhaps an RFC for querying whether or not an e-mail address is
valid using DNS? :-)
host -t txt some.email.AT.example.com.email-verification-zone.example.com
Ideally a good idea, I think there might be DNS overhead/scalability and
security exposure concerns but if coupled with some client access
concept it might get consideration. So why do expect to see the I-D? <g>
After all, there are already well-established and widely-used mechanisms
for synchronizing DNS data. (I skip tedious details like restrictions
on local-part of e-mail addresses, etc.)
Who would create/maintain the zone? I would think the service would
want to minimize call outs and prefer to just get a list from the
operator, its less overhead and also allows them to import the common
list from everyone into their own high speed database system.
But they might be an standard in obtaining the "common list."
Of course, there are many ideas to float around related to this idea.
The central idea is authorized integration of heterogeneous systems so
that they all look like one network.
For example, an SMTP extension can be written where an AUTH service is
defined to obtain server-side validation information, i.e., like a list
of valid users.
It is similar idea to VRFY. One future consideration to justify VRFY
usage is to make it an AUTHORIZED concept only. Won't work in the
general sense, but maybe good for something like this. That is how our
SMTP server offers VRFY - authorized clients only.
Also given the direction of the world (good or bad), maybe a SOAP or
REST API will probably get some a lot interest.
Similar to our WCSAP service that we use to validate the envelope
information. It is called directly from our SMTP but it can also be
called as a REST-like syntax:
http://www.winserver.com/public/code/html-wcsap?ip=64.26.171.99&cdn=%5b192.168.5.2%5d&from=dfs%40roaringpenguin.com&xid=public&debug=10
The above will attempt to validate your from address.
You can retest this at http://www.winserver.com/testwcsap with the
proper parameters relative to your workstation.
I can see a standard/common REST API "VRFY" function prototype that
backup or secondary MXs can use.
--
HLS