Some Ideas I would like to bounce off ya. You're welcome to comment.
These ideas are based on the following premises:
- Adding more value to addressing important 'issues' faced today in SMTP
- Maximum compatibility
- Minimum changes
Using the MX record lookup to provide additional
information
"Why the need for additional Information or what sort of information?"
To address sender machine access concerns. A few new proposals are being
drafted that promote additional lookups to address machine access questions.
In addition, to help in the no-solicitation or "no-spam wanted here"
proposals as well. Basically to provide server attribute information that
can help address the key issues we have today (or better said, most systems
in the industry are concern with).
"Why the MX record?"
Since all SMTP servers require support for MX lookup, I think it would a
way to avoid the additional overhead issues related to TXT lookups promoted
by these new DNS based sender-machine drafts. It will be a major overhead
reduction by using the MX record instead of the TXT record.
"How?"
By proposal a special MX domain name format which includes this
information, and even possibly using the preference with a hi/lo 2 word
concept. Lo word having the preference value, the hi word having bit map
flags.
"No paper hat! I didn't mean that, How will this be a major overhead
reduction?"
Oops Sorry! (slap across the head)
I am bringing this up in the first place having first hand experience of how
these new TXT based DNS lookup features work in the real world - basically
high expensive DNS lookup overhead when looking up non-compliant domains
which if we are going to use these as a basis to address the spoofing domain
problem means over 75% of the time - the DNS lookup will fail.
The major benefit the drafts have is to secure your own local domains. Once
you use them to check other systems - your performance goes down the drain.
Sure, that could be a deployment issue but as someone here recently
highlighted about his trip to the MIT Anti-Spam Conference:
"If everyone used idea XYZ, we solve the problem."
Well, DUH! I guess that includes the spammers implementing the ideas too!
"Ok silly, wouldn't this be asking a lot of administrators to change their
MX records?
Don't you think the DNS based TXT lookup proposals will be asking more!? At
least with MX, it is something they will be familiar with and if kept
simple, a change can be done in 1 minute.
However, the real icing on the cake is that developers will have a VERY
simply way to implement a MX logic when then the TXT lookup logic. I guess
you guys have not yet seen the technical implementation detail requirements
for SPF have you? HA!
"But why the MX record again or how would a new MX format be used?"
At face value, in the same way the DNS-based TXT lookups are used. Instead
you are not looking up a TXT record but instead a MX record to obtain the
same information. In additional, by using a MX record, it falls more
inline with SMTP compatibility in regards to Return Path validations. If
at some point of a normal SMTP transaction, a bounce or DSN is required, the
MX will need to be looked up based on the domain part of the return path.
You can kill 2 birds with one stone!
"Ok, even if I am not totally convinced, what information would be the MX
record and how can we use it?"
Well, there I don't have all the ideas, maybe those who see some "value or
merit" here can jump in with some MX domain name format ideas, before they
below the idea away. But I can give you some examples based on our
current work with DMP and SPF support in our product which again is WHY I
am bringing this up in the first place - first hand experience shows a
tremendous overhead issue with non-compliant domain lookup.
When the return path is provided, a MX lookup is performed:
With no change to the format, one can possible used the IP addresses
returned to compare with the connection IP address. This addresses the
simplest scenario of a SMTP host to final destination transaction. The
non-server MUA (end-user sending to host) is still an issue which I think
remains an issue with the TXT based lookup drafts.
With a change format, it could be something as simple as these (note,
verbosity is intended for illustrative purposes only. Brighter people can
come with a better naming scheme):
mx1.nospam.winserver.com
mx1.sendonly.winserver.com
mx1.rcvdonly.winserver.com
mx1.sendrcvd.winserver.com
First let me get this nospam tag out of the way since it is pretty straight
forward. A MX with nospam basically puts a "sign" out there (DNS) with the
hope spammers may use this to avoid trying to spam your system. They
benefit too by having "no spam" attribute in the MX record because a) its
easy to add to software that already has a MX lookup logic, and b) they can
now avoid connection overhead which they can shift to spamming other systems
that don't advertise their desire to not spam them. This can have a major
network overhead reduction benefit.
Back to the sender validation. In my opinion, the following two major points
with any of the new wave "sender" management foundations being contemplated
are important:
o True Result Information is the only 100% valid result.
o False/Unknown results provides no decision or low confidence.
The same principles apply does in DMP/SPF. If the domain contains DNS txt
record information, you can perform DMP/SPF logic, otherwise "no decision"
can be made and you move on.
Both are based on using the connection IP (CIP) and the return path domain
(RPD) as part of the lookup process. DMP is a simpler to deploy but more
expensive. SPF is harder to deploy and *CAN* provide the same results with
when compared at equal level. SPF offers more logic than DMP is designed to
do. This is why we implemented both.
Now, these proposals only validate the sender machine. They do not address
the sender or return path. We address this with CBV (Callback Verifier).
All together, they offer great spoofing protection.
But in the end, it all boils down to logic to pulling DOMAIN information
from DNS at the protocol level:
o One or more TXT lookups (DMP/SPF) to check sender machine
o One MX lookup to initiate the CBV process
where both have a common return path domain lookup logic (DMP/SPF secondary
lookup is based on the machine domain name presented at HELO/EHLO)
In my view, what makes it all easy to see is that is a DNS lookup is
required based on the return path domain, it might as well be based on a
lookup with a high expectancy to be there - the MX record.
So logically, if the MX record can also provide the same information that
DMP/SPF wish to expose about a system, it will offer a great benefit in the
following areas:
- Lower overhead/bandwidth for servers and clients and network
- Lower implementation/change requirements by Software developers
- Lower learning curve for DNS administrators
- Promotes a standard method for MX domain naming.
- Higher compatibility with SMTP
which to me, yields higher acceptance and faster deployment.
Look folks. This has nothing to do with trying to kill efforts by ARSG.
After all, we did implement DMP and SPF, but these proposals will have a
problem of acceptance because it require significant change to your
software. So it make more sense within the development industry to see
"what best" works with minimal changes. I don't think 1 solution can be
used so maybe multiple offering will be required. At least that is the
approach we took at this early stage adding "SMTP Sender Management"
concepts to our software. But in the end, one will prevail and I think
that will be based on a) easy of implementation and b) solve the main issue.
While others would say "We waited until the endorsed method was selected and
based on that SPF seems to be the winner," I would say what I said above -
DMP is easier to add and gives you basically the same results as SPF - but
more importantly, you achieve the same results with much more benefits
across the board by just using what is already there - the MX record.
In any case, in my belief, ultimately I see it will be important to get
"server" information before connections are made as a important development.
Wither its TXT records or new records, etc, whatever it is, it should be 1
or as few as lookup as possible to get everything that is required.
Potential Problems using the MX record?
Large farms - separate receivers farms vs. separate sender farms.
Issue #1
one of the enhancements made to our DNS resolver, assisted with some input
gathered from discussions here, is to establish the complete expanded list
of MX host. Before, we just used the MX records returned with no A record
expansion. The final optimized, sort list *may* include logic for delay
host IP lookup.
In this case, a potential for some overhead reduction gains can be lost
with the requirement to have the IP resolves with additional DNS A record
lookups.
However, in practice, I see this only happen with large ISP with mucho MX
records and from what I see they rotate a fix set with resolved IPs, enough
to satisfy a transaction, i.e, AOL may yield 15 records with the first 10
resolved.
Issue #2
An send only machine with a return path to a receive machine. The
connection IP is that of the sending machine.
One solution is to include the MX record:
mx1.sendonly.winserver.com
so that the IP check can be made against the connection IP and the SMTP send
mail logic to be slightly alters to exclude this MX record from his DNS MX
resolver. To help support SMTP servers that are not excluding the record,
these sendonly MX records will have high preference values that when sorted
will be among those that are located at the bottom a HOST list. The
"rcvdonly" or "both" MX records resolved should be at the TOP of a sorted
host list. for example:
mx1.rcvdonly.winserver.com preference: 10
mx2.rcvdonly.winserver.com preference: 10
mx3.rcvdonly.winserver.com preference: 10
mx4.rcvdonly.winserver.com preference: 10
mx5.rcvdonly.winserver.com preference: 10
mx1.sendonly.winserver.com preference: 10000
mx2.sendonly.winserver.com preference: 10000
mx3.sendonly.winserver.com preference: 10000
mx4.sendonly.winserver.com preference: 10000
mx5.sendonly.winserver.com preference: 10000
Anyway, comments?