Wildcards in reverse DNS
mh+bind-users at zugschlus.de
Sat Jan 13 12:53:23 UTC 2007
On Mon, Jan 08, 2007 at 09:28:39AM -0800, Clenna Lumina wrote:
> >> Marc Haber wrote:
> >> >> so if it's generating a bad HELO, then thats the fault of the
> >> >> foreign mail server, which is likely not configured correctly to
> >> >> begin with.
> >> >>
> >> >> My personal mail server which sits behind my home NAT, has never
> >> >> failed to get a proper HELO from proper foreign hosts.
> >> >
> >> > It's the connecting server who says HELO, not the server connected
> >> > to.
> >> That *is* what I said - s/foreign/connecting/
> >> " so if it's generating a bad HELO, then thats the fault of the
> >> foreign mail server "
> >> ^^^^^^^
> > I am talking about connecting via SMTP to the outside. How is a server
> > behind NAT supposed to know which HELO to use when connecting to the
> > outside?
> If it's connecting to the outside, it would already know which one (the
> domain of the mail it's sending to the destination server, of course...
> it's not exactly magic.)
A server connecting to the outside gives its own host name as
parameter to the HELO command. See here a transcript of sending a
message from nechayev.zugschlus.de to torres.zugschlus.de:
$ swaks --to mh+bind-users at zugschlus.de --from mh+bind-users at zugschlus.de --server torres.zugschlus.de
=== Trying torres.zugschlus.de:25...
=== Connected to torres.zugschlus.de.
<- 220 torres.zugschlus.de ESMTP Exim 4.64 Sat, 13 Jan 2007 13:43:37 +0100
-> EHLO nechayev.zugschlus.de
<- 250-torres.zugschlus.de Hello nechayev.zugschlus.de [220.127.116.11]
<- 250-SIZE 20971520
<- 250 HELP
-> MAIL FROM:<mh+bind-users at zugschlus.de>
<- 250 OK
-> RCPT TO:<mh+bind-users at zugschlus.de>
<- 250 Accepted
<- 354 Enter message, ending with "." on a line by itself
-> Date: Sat, 13 Jan 2007 13:43:37 +0100
-> To: mh+bind-users at zugschlus.de
-> From: mh+bind-users at zugschlus.de
-> Subject: test Sat, 13 Jan 2007 13:43:37 +0100
-> X-Mailer: swaks v20061116.0 jetmore.org/john/code/#swaks
-> This is a test mailing
<- 250 OK id=1H5iEv-0006t0-7O
<- 221 torres.zugschlus.de closing connection
=== Connection closed with remote host.
Some receiving servers check whether the HELO/EHLO name presented to
them matches the reverse DNS entry of the IP that is used to connect
from and use this as input to spam scoring techniques, thus it is
important that the connecting server knows which IP the remote side
will see to issue the correct HELO/EHLO parameter. This is trivial
(look it up in the DNS) as long as no NAT is in the game - if NAT is
in the game, the connecting server behind NAT needs to be aware of
which IP address this particular connectio will be NATted to. Which at
least involves some extra configuration and is even harder if the
NATted-to IP address is a dynamic one.
> As I've already told you, I've run mail servers *behind* (and still
> do, even my private one on my home network) and NEVER had any issues.
> You're once again confusing NAT itself with bad implimentations.
NAT is evil because rarely anybody gets it completely right because it
is awfully hard to get right. How do you configure your outgoig mail
server to issue the correct HELO/EHLO name?
> > Having more than one double-colon abbreviation in an address is
> > invalid, as it would make the notation ambiguous.
> How so? If such a notation means zero, wouldn't
> just essentially translate to
> I mean, it would seem pointless of course, although I don't think it
> would be ambiguous if they amount to zero (in other words I would of
> thought extra pairs would be essentially discarded in a manner, as they
> wouldn't really make a difference.
I reckon that 2001:db8:::1428:57ab would be equivalent to
2001:db8::1428:57ab, and fully expand to
> > A sequence of 4 bytes at the end of an IPv6 address can also be
> > written in decimal, using dots as separators. This notation is often
> > used with compatibility addresses (see below). Thus, ::ffff:18.104.22.168 is
> > the same address as ::ffff:102:304.
> Nice. That is exactly what I was hoping for, some way of using old
> adddresses (and with compatibility, may I assume you mean mapping to
> IPv4 equivlents of the DEC portion (for a IPv4 IP within an IPv6 space
An IPv6 aware service will see an IPv4 connection from a.b.c.d as
::ffff:a.b.c.d. This has caused a little grief in the past when a
supposedly minor software upgrade to a remote box suddenly made it
IPv6 aware, the IPv4 addresses in /etc/hosts.allow didn't match any
more and the box started to reject the management ssh connections.
> >> While I like how the Germans did it, there is an
> >> obvious benefit to using area codes, especially in a country the
> >> size of the US. When you see a phone number with an area code,
> >> you can easily deduce or determine where it may actually be
> >> located.
> > Actually, we have area codes. They are longer for rural areas, and
> > shorter for the big cities, to allow the actual subscriber number to
> > vary in length according to the size of the local network.
> I see. Not a bad system. I would not say either the German or US system
> is right or wrong, as they oth seem to serve a purpose, though I find
> the German system appears to scale better.
It causes some grief for international operators, as I have been
recently informed in private mail.
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
More information about the bind-users