----- Original Message -----
From: "Timothy DeHan" <timothy@tdehan.com>
To: <spf-help@v2.listbox.com>
Sent: Tuesday, October 14, 2008 4:28 PM
Subject: Re: [spf-help] Now I am really confused....
> Ok, I will contact Comcast to have them create a reverse DNS. I am
> guessing then that I would have to have them create one for each Domain
> Email accounts I host?
>
> I am still confused a bit by all the different responses I am getting per
> my original question so I would like to try asking this a little
> differently.
Please allow me to try.
It seems to me you are confused between hostnames, domains and zones. In
addition you are dealing with multiple problems.
Correct me if I'm wrong but I think you have only one server, which works
for multiple email domains. If not, the following may be incorrect in a
couple of details.
You have a server. This server is connected to the internet. The server
has an address. The server also has a name.
Computers connect by means of addresses, not by names. But humans like
names, not addresses. That's why a mapping exists from addresses to names.
Another mapping exists, from names to adresses. This mapping is done not
just for computer names but also for other purposes.
When your computer sends email to me, I (my server) know the following:
1: what is the address of your computer
2: who do you say you are
3: who is mailing whom
but what I really want to know is:
1: what is the name of your computer, so that I can contact its keeper in
case of problems
2: are you really who you pretent to be
3: is the message sender who he claims to be
That is because lots of people abuse the email system, e.g. for sending
viruses, spam and other malicious actions. I don't want that junk, and you
don't want it to reflect upon your name.
Nothing is 100% sure and safe, but nowadays the connecting address is
assumed to be valid. To a certain degree I can trust that it really is
70.89.155.193 which is connected to me.
Then your computer says: "Hello, my name is xyz. I have mail from pqr which
should go to abc".
My computer will lookup the name belonging to address 70.89.155.193 and to
do so it will contact the owner of that address: comcast. Comcast says the
name belonging to this address is mail.tdehan.com; my computer will then
lookup the address belonging to mail.tdehan.com and it finds 70.89.155.193.
That second mapping is done at whereever its owner (you) happens to have his
DNS hosted, godaddy in this case.
Step 1 completed. The owner of the address 70.89.155.193 agrees with the
owner of the name mail.tdehan.com that these two belong to each other.
SPF is another way to gain some trust in the connecting computer's name,
necessary because sometimes step 1 cannot be completed. Instead of mapping
from address to name and back, my computer could also react like so:
your computer says: "Hello, my name is xyz". My computer then contacts xyz
and asks for an SPF policy. That policy is very simple: which address(es)
is/are authorized to say "My name is xyz". If things are setup properly
there is only one host authorized to do so and thus there is only one copy
of this policy, published at one place listing just one server.
If the policy authorizes host 70.89.155.193 then I know the owner of 'xyz'
agrees that 70.89.155.193 uses his name. That completes step 2.
Make sure your host says "HELO mail.tdehan.com" (meaning: Hello, my
hostname is mail.tdehan.com). Keep your address-to-hostname mapping to point
to mail.tdehan.com and keep your hostname-to-address mapping point to
70.89.155.193
Either from step 1, step 2 or both, now I know I can trust that the computer
is really at xyz. But that does not mean this computer is authorized to
write messages on behalf of bill gates, santaklaus, the president of the
USA, and so on. Time for step three.
SPF's primarily use is to check authorization for using names in email
addresses. When your computer says "I have mail from pqr which should go to
abc", I need to verify that pqr is okay with this.
So my computer asks pqr for its SPF policy. In that policy a list of
addresses is authorized to speak on behalf of pqr.
If pqr does list 70.89.155.193 as an authorized user of the name pqr, I can
trust that pqr will handle complaints in case 70.89.155.193 abuses the
internet.
To complete the answer to your questions:
You need an SPF policy for hostname mail.tdehan.com; this policy should be
published under domainname mail.tdehan.com in a TXT record and, if
available, in an SPF record. (notice SPF _policy_ in an SPF _record_)
You also need an SPF policy for every email domainname, examples are
"tdehan.com", "wrathcat.com" and so on. Each of these policies need to be
published under the respective domainname.
(you say: mail from doesnotexist@tdehan.com then I lookup at tdehan.com, NOT
at mail.tdehan.com !)
Each policy should list all servers authorized to use the name. There can be
more than one such server, e.g. wrathcat could also be sending via another
host such as gmail, and the policy you are about to publish should authorize
them too!
Last but not least: *how* those IP addresses are listed in a policy is a
choice you have to make.
Listing each host by its address is the least resource intensive on the
internet.
Listing each host by its name is fine if the addresses change a lot but the
names do not.
Listing each host by its function is fine in some cases, but usually it is
just a waste of resources (IMHO, of course).
All policies start with "v=spf1".
If you just need to authorize one host, you can do so using
"ip4:70.89.155.193".
Most policies end with "-all".
Concatenate using spaces and get "v=spf1 ip4:70.89.155.193 -all"
Publish this policy for each domain name used for email:
mail.tdehan.com because it is the hostname sending mail and saying hello,
tdehan.com because your computer is authorized to send mail from anyone @
tdehan.com
wrathcat.com because your computer is authorized to send mail from anyone @
wrathcat.com
and so on
The use of hostname mail.wrathcat.com pointing to your IP address is
somewhat wrong. It won't hurt you and it has nothing to do with SPF, but
nevertheless:
1: lookup "who receives mail for wrathcat.com". Answer: "mail.wrathcat.com"
2: lookup "What is the address for mail.wrathcat.com". Answer
"70.89.155.193"
3: connect to 70.89.155.193 and send mail
4: lookup "who receives mail for tdehan.com". Answer: "mail.tdehan.com"
5: lookup "What is the address for mail.tdehan.com". Answer:
"70.89.155.193"
6: connect to 70.89.155.193 and send mail
Change this to:
1: lookup "who receives mail for wrathcat.com". Answer: "mail.tdehan.com"
2: lookup "What is the address for mail.tdehan.com". Answer "70.89.155.193"
3: connect to 70.89.155.193 and send mail
4: lookup "who receives mail for tdehan.com". Answer: "mail.tdehan.com"
5: use address still cached
6: connect to 70.89.155.193 and send mail
Short term benefit: step 5 needs no DNS lookup.
Now consider what you have to do when box mail.tdehan.com is moved to
another IP address. Do you want to make one DNS update (for
mail.tdehan.com) or do you want to spend the whole afternoon looping through
"mail.{next_domain}.com" ?
-------------------------------------------
Sender Policy Framework:
http://www.openspf.org Modify Your Subscription:
http://www.listbox.com/member/ Archives:
https://www.listbox.com/member/archive/1020/=now RSS Feed:
https://www.listbox.com/member/archive/rss/1020/ Powered by Listbox:
http://www.listbox.com