Ok, now, that wasn't so hard, was it? Thank you. :-)
----- Original Message -----
From: <Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Cc: <ietf-smtp(_at_)imc(_dot_)org>; <moore(_at_)cs(_dot_)utk(_dot_)edu>
Sent: Tuesday, February 10, 2004 10:46 PM
Subject: Re: MX Domain Name --> Was Re: Some Ideas I would like to Bounce
off ya
On Tue, 10 Feb 2004 17:21:24 EST, Hector Santos said:
smtp.SENDER.vt.edu ip: 128.173.54.129
Compute how many of these you can get back in a single
512-byte DNS response (hint - go back and look at
WHY AOL round-robins their stuff the way they do).
Right. But I do think yet this is a reason to nix the discussion or idea
yet. Go to my
original message and zoom to the bottom "Potential Problems" where I
discussed this the topic of large expanded list.
Question:
How do you think AOL will describe their SPF records?
Compute the operational cost of having to drop back to TCP
(if even feasible) for more responses. It's quite possible
that for vt.edu you'd get at least 400 or so responses back
(that's just the ones I *know* about that are Unix/Linux
workstations that do their own SMTP handling).
First, was not suggesting for the addition of 400 records or
whatever. That would be ludricrous.
Let me simplify this by summarize what I am seeking:
Is it possible to expose or translate into a specially crafted yet 100%
compliant MX domain name format the total possible SPF record
information which describes the lookup rules for cross checking sender
machine(s)?
This is a non-starter unless you find a way to do the query such
that it returns one packet or less of data (for multiple reasons).
I think that is what my original question attempted to poise.
Look, the issue is this:
LMAP based proposal implementations will be VERY VERY expensive. It is
quite obvious now that the technical analysis of its implications have
not been fully thought out and explored. Just take a look at the SPF
source code!!! Most developers will need an API just to implement it
correctly! It is not for the faint hearted. The DNS workload will
be awful on the server-side and across the network! DoS attacks are
MORE a reality than you think.
My proposal raises the idea whether it is FEASIBLE under the following
fundamental premise of:
100% current MX implementation COMPLIANCE and COMPATIBILITY
to:
Expose the same or similar information attempted to be advertised by
LMAP proposals into a special crafted MX sub-domain naming nomenclature
in order to eliminate for multiple TXT lookups and followup lookups as
reguired by SPF like proposals.
The idea is not as foreign as you might think.
AOL uses a sub-domain format to identify the IP of the sending machine.
I don't know how consistent this is, but it definitely be used as
cross-check. Here are a few examples:
acbbaf2e.ipt.aol.com
acbbe0d6.ipt.aol.com
acbcca06.ipt.aol.com
acbe9b44.ipt.aol.com
acbec50d.ipt.aol.com
acbec811.ipt.aol.com
The first sub-domain is a hex representation of the connecting IP. I got
atleast 500 or so of these systems in the month of January.
Yes, these are not MX records. But the idea is the same.
Yes, the AOL large type systems will have to define a way to
advertise their sending machines.
How will they do this with SPF?
Do you think they can define this in one SPF line?
If so, then why can this "information" by translated into a compliant
sub-domain syntax?
If you can tell me this is not possible. Then its a non-starter. But this
has not been shown yet.
I want you to realize what SPF will mean to you:
For example, for your system, assuming class C, DMP allows for masking:
*.in-addr._smtp-client.vt.edu TXT DMP=DENY ; global
default
*.54.173.128.in-addr._smtp-client.vt.edu TXT DMP=ALLOW ; allowed
senders
But you will need to add two more TXT records to cover your machine
domain turing-police.cc.vt.edu (formatted in the same manner above).
This allow you to use different return path address.
For SPF, it would be TXT records (not 100% sure for your setup):
_spf.vt.edu TXT "v=spf1 a:turing-police.cc.vt.edu"
vt.edu TXT "v=spf1 a:turing-police.cc.vt.edu"
or with IP4:
_spf.vt.edu TXT "v=spf1 ip4:128.173.54/16 -all"
vt.edu TXT "v=spf1 ip4:128.173.54/16 -all"
This basically says that when a SPF TXT lookup for the return path
domain vt.edu is made, the v=spf1 record will say that only this
turing-police.cc.vt.edu or that set of Ip addresses are valid sender
machines.
I want you to realize what this will will mean in practical terms based
on real first-hand experience in real operations.
It means 2 or more text records lookups. Its not even a standard yet
and we already have BACKWARD compatibility issues with two different types
of
lookups. Why not just stick with _SPF sub-domain? Poor. simply poor.
Now remember what the INTENT is:
To BLOCK out the spoofers or validate legitmate sending domains
Well this INTENT is based on the flawed thinking that MOST of your
spammers are not spoofers.
The fact or reality is that atleast a good bit of your spams are from
spoofers with spoofs or bad domains.
The result?
The majority of your LMAP lookups will fail putting a major
dent on non-authority and authority DNS lookups.
Now since the RETURN-PATH is still an IMPORTANT identity of the system,
which requirements or concepts that the domain exist, a MX lookup "may"
be able to provide ALL the information required.
We do a suite of test:
RBL A
DMP TXT with possible recursive alternative domains lookups
SPF TXT with follow up A, MX or PTR lookups
CBV MX
RBL is the best current method to stop spammers. Thats a non-starter
to attempt or think this will ever go away or be replaced by something
else. No proposal will replace this.
With DMP/SPF, we had to make it an option to just check LOCAL domains
spoofs because the overhead was TOO HIGH in external domain checks.
MX is used for the CBV. Others may use a C/R or other return-path
validations
methods.
So if it is possible to expose the sender machines information in MX defined
host
or group of host sub-domain names, not only do you get the same results of
DMP/SPF but you also GET to do able to do a return address validatation.
I hope this better explains it.
What I want to know it is makes sense or possible to put expose this
information
on the MX records. That is all I am asking. Saying MX is for RECEIVERS
only
is not an answer. Saying AOL presents a problem, hence a non-starter, is
not
a complete reason yet to nix the idea.
Sure, there will ALSO be the "extended systems" where it is difficult, but
if atleast 80% of the systems can support this, well, that could mean it
is feasible or warrant more investigation.
All I am saying is that LMAP is a mistake! It adds a COMPLICATED layer
of technology with a high overhead which addresses what ULTIMATELY will
be a short term problem.
We added it. I speak with emperical results behind me. I can see the
total picture in action and the bottom line is:
boy, it would be sweet if ALL the redundant lookups can be
minimized!
Its likes going to the grocery store 5 times to pick up 1 item at a time
knowing all along that the 5th item may be ultimately necessary and would
of made the first 4 trips unnecessary!
Why not pick it up all on one trip? or better yet, pick up item #5
first and save money not buying items 1 to 4?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com