Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The Wednesday 2006-12-20 at 13:43 +0100, Sandy Drobic wrote:
Interesting... still, in my country it is very difficult or even impossible
to get rDNS even from the address space owner. They simply do not offer that
service, and the talk persons do not even know what it is (not really
technicians).
I simply can't imagine that a company with a/several static ip(s) and good
bandwidth will not get a correct reverse dns if they insist on getting one. If
that is the case and there is an alternative available the customer WILL
change.
I suppose so. A big customer can get almost anything.
Yep, money makes almost anything possible.
They definitely won't offer that service to small fry. I asked my current
provider (of my private internet connection) if I could get a static ip for
additional pay and they told me it is impossible. On the other hand they
simply don't have business customers. So it's logical that they won't set up
static ips and reverse dns.
No, my provider does give static IPs if you ask for it, on adsl (or
whatever). It is used by small businesses, and also people needing it to
work from home because their company has set their firewall to admit
connections from certain IPs only, and things like that.
Well, I wouldn't call it a static ip if these ips are in the same address
space as the dial up addresses. (^-^)
I know that making rDNS is almost impossible because I have a friend with
a Fidonet node and small mail server, and he doesn't have reverse dns
working. He once was a very small provider himself, with a partnership,
and he commented that he couldn't get it. Other people in the Spanish list
also commented they couldn't get it, and from several providers. Its quite
common around here, and unbeliveable for people like you ;-)
Here in Germany you can have your choice among a variety of providers, so
it's always possible to get a clean static ip if you are willing to pay
for it.
When asking for the r-name for my current IP (W.X.Y.Z), I get something like
this:
Z.Red-W-X-Y-.dynamicIP.rima-tde.net.
My server would block you, because that IP is listed as dynamic.
I know, I know. I meant the idea, not that particular IP range. Suppose
mine had the word "static". Just assume that it would not be rejected,
every thing else being correct. I'm just curious about getting a matching
rDNS name that way.
For my provider, static IPs are named as
"Z.Red-W-X-Y-.staticIP.rima-tde.net.".
Doesn't really matter that much, because I (and I assume a lot of other
mailadmins) use checks like
if (hostname contains (number and "-" or ".") at least three times) then
treat as probably dynamic and hit with your favorite choice of checks like:
reject_unknown_sender_domain
reject_rbl_client bl.spamcop.net
reject_rbl_client dynalist.njabl.org
greylisting
reject_unverified_sender
Because I did indeed get some desired mails from that address space I can't
block rima-tde.net hard.
It has millions of users, both home and businesses, both dynamic and static
;-)
As far as mailservers are concerned only the static server ips are
important. And if they don't have a matching reverse dns they obviously
can't be that important... (^-°)
So, suppose I had a domain name, but instead of pointing it to my static
address (if I had one), could I point it to the given reverse name instead?
I don't know how that is called in DNS parlance, but I suppose you get the
idea.
The rDNS on the "real" name would work, as my real name would not be the one
I choosed, but the one my ISP gave me...
:-?
This wouldn't change your IP, and many checks apply ip based blacklists.
I know, it's a theoretical idea, assuming an static IP, and not
blacklisted.
In most cases it won't matter. I only had one case in about a year of
productive use, where a mailserver refused to accept mail from my server
because the helo name and the dns name did not match (at that time).
I have a server on a dynamic ip, so I know very well that the situation might
be manageable if you are using the server to learn and only for your own
private purposes, that that will fail if more users are depending on the
server and they can't react and set a route for a domain that does not take
the mail directly.
In the end the only solution is to use the relayhost of your provider with all
the restrictions that apply to that solution.
Certainly, certainly, but I'm not receiving mail directly, and I don't
have users.
If you don't receive mail directly then you could probably better own a
virtual server at a serious hosting company for about 10 Euro per month.
Then use that server as relay server and mx for your domain. your internal
server would only talk to the relay server. That would be the most cost
effective way to get a static ip with almost full control of the server
(many virtual servers are configured in such a way that they can't use
localhost for internal network connections).
I decided to invest in a static ip and change provider because more and more
servers do not accept mails directly, and the relayserver of my provider is
not as reliable as I wish my server to be. So, I will soon be able to enjoy
the benefits of a static ip.
Might have to do that one day.
Try a virtual server as alternative. You get root access, lots of
bandwidth and a static ip. If you don't need much horsepower for a big
website, that is the easiest way to enter the static ip area.
One reason I send my mail directly, is that the relay host of my ISP only
accepts my email if the FROM is theirs, and reject it otherwise. So, using
their relay, I could not send using my sourceforge or ieee alias, for
instance. I'm still investigating it, because I think postfix is not being
able to authenticate properly to them.
Postfix can use authentication for the smtp client. With Postfix 2.3 or
newer you can even use sender_dependent_relayhost settings. Though I still
think that it is an evil construct.
Sandy
--
List replies only please!
Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
