On Wed, 11 Feb 2004 23:36:22 EST, Hector Santos said:
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.
Actually, you *were* suggesting it.
You just didn't realize it, because you refused to think it through.
How will they do this with SPF?
We're not talking about SPF. We're talking about stupid MX tricks.
smtp.SENDER.aol.com MX acbbaf2e.ipt.aol.com
(and so on for the 500+ systems you've seen AOL mail from in January)
That's one honking big MX list. And that's what you proposed. If it
isn't what you proposed, you need to learn to write what you meant.
But as to how to do it with SPF:
Do you think they can define this in one SPF line?
aol.com. 300 IN TXT "v=spf1 ip4:126.96.36.199/24
ip4:188.8.131.52/24 ip4:184.108.40.206/24 ip4:220.127.116.11/24
ip4:18.104.22.168/24 ip4:22.214.171.124/24 ip4:126.96.36.199/24 ip4:188.8.131.52/24
ip4:184.108.40.206/24 ptr:mx.aol.com ?all"
Apparently, the AOL staff thinks they can do it in one line.
But we're discussing MX records, not SPF using TXT, remember?
If so, then why can this "information" by translated into a compliant
Because the SPF record is short because it allows wildcarding, and
you have to actually enumerate all the members if you're using an MX.
If you can tell me this is not possible. Then its a non-starter. But this
has not been shown yet.
Your proposal *as* *stated* doesn't work for my domain, and it doesn't work
for the aol.com domain. If you can't understand why a proposal absolutely
positively has to work for aol.com or it's a non-starter, please consider
a different line of business.
I want you to realize what SPF will mean to you:
If you can't keep SPF and MX straight, please come back when you have a clue.
I've considered SPF. SPF has its strong points and its weak points.
One of its strong points is that the author at least had enough clue to
realize that MX's are for one thing, and TXT records are for other things,
and not to try to encode TXT records in the MX tree.
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.
vt.edu TXT "v=spf1 ip4:220.127.116.11/16 ip4:18.104.22.168/16 ?all"
There. *Done*. Period. End Of Discussion. If SPF is a good idea,
the above single record is *all* that's needed. It does my domain in
one DNS entry, it does aol.com in one DNS entry.
Unfortunately, I can't comprehend the overwhelming wisdom of the rest
of your note, as I was too unable to follow the wisdom of using masses
of MX records to replace one TXT record, but I will point this out:
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.
Odd CAPITALIZATION is often considered a PRIME sign of net.kookery.
Description: PGP signature