On Tue, 22 Nov 2005, Hector Santos wrote:
So for the server to assumed a valid A record, it is presuming the
client has a proper PTR record setup and that may not be the case.
Huh? I am not talking about PTR records. I don't want mail servers to use
PTR records. PTR records are unreliable, and small domain owners can't fix
it - no matter how competent they are.
The bottom line is this, if the client uses a DNS API function call to
perform a PTR query on the socket IP address, then it will most likely
get the proper client name. If it uses the socket layer
gethostbyaddr() function, it may not.
The client should be a proper MTA, and should be configured with a correct
FQDN. Manually, if automatic guesses fail. If there is an MX or A record
for an MTA to receive mail, then that MTA certainly has a correct HELO name
to use. If the shop has separate SMTP out servers, the *ability* to create
MX records implies the ability to create A records for their outgoing
servers.
On the other hand, a small domain (less than class C) does *not* have the
ability to create PTR records. Only their ISP does!
=======================================
That's not completely correct, Hector. If you are working with a
knowledgeable bandwidth provider, they can DELEGATE a subnet within a Class
C network to you and you can then control your PTR records by setting up an
IN-ADDR.ARPA for the full subnet. The delegated address range will then be
referred to your Class C subnet to poll your primary DNS server and will be
given the PTR record for your mail server.
The key is working with a KNOWLEDGABLE provider.
We have just such a provider for one of our mail servers and have a /27
subnet on a larger net delegated to us. It works just fine. Here's the
report showing the delegation of the subnet address to us:
http://www.dnsstuff.com/tools/whois.ch?ip=65.86.164.132.
Here's the report showing the PTR record for the mail server
http://www.dnsstuff.com/tools/ptr.ch?ip=65.86.164.132 on the delegated /27
address group within the Class C.
Note, that in this case, the delegation was done by DSL.NET for a full T-1,
for service provided on a sub-contracted COVAD circuit. We also do
something similar with another T-1 from Broadwing Communications, formerly
Focal Communications. Both are very reliable providers and both have sub
netted and delegated a portion of a Class C without any PTR or
"in-addr.arpa" problems.
Granted, if you read my earlier post, we did have a problem with a new tech
in one of the centers who had the initial delegation incorrect. Once it was
deleted and re-delegated, it took about a 3 days to populate throughout the
net and all was well again.
Because of the price reductions that have taken place over the last few
years, we can run multiple T-1s, have a much better reliability factor, and
can provide better bandwidth availability to our customers who's websites
tend to have hefty traffic; without the bottlenecks and potential outages
experienced with only one provider.
Bruce Barnes
ChicagoNetTech Inc
So these days, there *might* be a safe correlation that a HELO
mismatch is associated with a bad client. I think so, but not strong
enough, YET, to make this a hard coded rule. There is too much legacy
reasons to make this reliable.
I don't have any problems with my three strikes rule: "you must have at
least one (valid version) of the three 2821 IDs I check: PTR, HELO, MFROM
(SPF)".
I would add CSV to the list, but the 6 servers that use it aren't much of a
motivation.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for a
Microsoft sponsored "Where do you want to go from here?" commercial.
-------
Sender Policy Framework: http://www.openspf.org/ Archives at
http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription, please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com