Bug? Reverse DNS not handled properly for sub-class-C
Vivek Khera
BG> status=deferred (host ...[...] said: 450 Client host rejected: cannot
BG> find your hostname, [166.70.176.119])
[onceler]% host 166.70.176.119
119.176.70.166.IN-ADDR.ARPA is a nickname for 119.112/28.176.70.166.IN-ADDR.ARPA
119.112/28.176.70.166.IN-ADDR.ARPA domain name pointer mojo.cold.org
[onceler]% host mojo.cold.org
Host not found.
[onceler]%
Seems like postfix rejects it as forged data, since mojo.cold.org
doesn't point back to the IP.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: kh...@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Brandon Gillespie
> BG> to have a reverse pointer, I dont care if that pointer also resolves...
> BG> They are different orders of magnitude IMHO, and asking for the latter
> BG> can get really hairy, especially considering some places which have
> BG> server farms and the like...
>
> You cannot change the way others operate their mailservers. If they
> wish to reject mail from you for this violation, then you need to
> contact them some other way and ask them to bypass you from that
> check.
I dont think I was fully clear. This is _MY_ server, I do not want to
have this level of check. I do want to bounce if reverse DNS does not
work. I do NOT want to bounce if the reverse DNS name does not also
resolve. As far as I can tell the reject_unknown_client does a reverse
lookup followed by a forward lookup. I Only want to do the reverse...
-Brandon
--
Phone/Fax: 801 332 4260
Mobile: 801 726 9587
gill...@iomega.com
Brandon Gillespie
zone. I mail a postfix server which requires reverse DNS to work on
your client hostname, and get a bounce with:
status=deferred (host ...[...] said: 450 Client host rejected: cannot
find your hostname, [166.70.176.119])
However, that IP does resolve in reverse DNS, even using 'host' on the
relay which is bouncing it. It DOES resolve to a sub-class-C:
# host 166.70.176.119
119.176.70.166.in-addr.arpa is an alias for
119.112/28.176.70.166.in-addr.arpa.
119.112/28.176.70.166.in-addr.arpa domain name pointer mojo.cold.org.
So why is postfix bouncing this email? The same email sent from another
host which has a full reverse lookup does not break. My best guess is
how its handling its reverse lookups. OS is Solaris 8, Postfix version
1.1.11.
-Brandon Gillespie
Wietse Venema
The reject_unknown_client restriction requires that clients have
a known hostname. A hostname that isn't backed by an A record is
meaningless, since anyone can return any PTR junk as the hostname.
Don't bother asking me to change this, as I haven't changed this
in the past 10+ years.
Wietse
Brandon Gillespie
> BG> find your hostname, [166.70.176.119])
>
> [onceler]% host 166.70.176.119
> 119.176.70.166.IN-ADDR.ARPA is a nickname for
> 119.112/28.176.70.166.IN-ADDR.ARPA
> 119.112/28.176.70.166.IN-ADDR.ARPA domain name pointer mojo.cold.org
> [onceler]% host mojo.cold.org
> Host not found.
> [onceler]%
>
> Seems like postfix rejects it as forged data, since mojo.cold.org
> doesn't point back to the IP.
Good observation.
Which brings up another Question, how to disable this? I just want it
to have a reverse pointer, I dont care if that pointer also resolves...
They are different orders of magnitude IMHO, and asking for the latter
can get really hairy, especially considering some places which have
server farms and the like...
-Brandon Gillespie
Ralf Hildebrandt
> I am guessing the problem comes in because I have a sub-class-C dns
> zone. I mail a postfix server which requires reverse DNS to work on
> your client hostname, and get a bounce with:
>
>
> relay which is bouncing it. It DOES resolve to a sub-class-C:
>
> # host 166.70.176.119
> 119.176.70.166.in-addr.arpa is an alias for
> 119.112/28.176.70.166.in-addr.arpa.
> 119.112/28.176.70.166.in-addr.arpa domain name pointer mojo.cold.org.
>
> So why is postfix bouncing this email? The same email sent from another
> host which has a full reverse lookup does not break. My best guess is
> how its handling its reverse lookups. OS is Solaris 8, Postfix version
> 1.1.11.
Is it running chrooted? Does it work when smtpd is not chrooted?
--
Ralf Hildebrandt Ralf.Hil...@charite.de
Postfix Tips: http://www.arschkrebs.de/postfix/ Tel. +49 (0)30-450 570-155
When the going gets weird, the weird turn pro.
Victor....@morganstanley.com
> Vivek Khera wrote:
> >>>>>>"BG" == Brandon Gillespie <gill...@iomega.com> writes:
> >>>>>
> >
> > BG> Which brings up another Question, how to disable this? I just want it
> > BG> to have a reverse pointer, I dont care if that pointer also resolves...
> > BG> They are different orders of magnitude IMHO, and asking for the latter
> > BG> can get really hairy, especially considering some places which have
> > BG> server farms and the like...
> >
> > You cannot change the way others operate their mailservers. If they
> > wish to reject mail from you for this violation, then you need to
> > contact them some other way and ask them to bypass you from that
> > check.
>
> I dont think I was fully clear. This is _MY_ server, I do not want to
> have this level of check. I do want to bounce if reverse DNS does not
> work. I do NOT want to bounce if the reverse DNS name does not also
> resolve. As far as I can tell the reject_unknown_client does a reverse
> lookup followed by a forward lookup. I Only want to do the reverse...
>
Develop a new restriction primitive called "reject_nonptr_client". Test
it, see how much uce it blocks, if it turns out to be significantly
useful, describe its effectiveness and merits, with luck it will get
adopted. Otherwise maintaining a private patch for this should not prove
too hard. You can reuse some of the state from reject_unknown_client
because any "known" client is necessarily a PTR client. So your
restriction would recheck unknown clients, and not reject them if they
have a PTR record.
The usefulness of this is questionable. It is also not safe in combination
with domain-name based client white-lists (for which the defer
functionality of reject_unknown_client is necessary).
It may be useful to also implement "defer_unverified_client" so one can
bullet-proof domain-name client white-lists without being forced to
blacklist verifiably unknown clients.
--
Viktor.
Brandon Gillespie
> Brandon Gillespie:
>
>>Vivek Khera wrote:
>>
>>>>>>>>"BG" == Brandon Gillespie <gill...@iomega.com> writes:
>>>>>>>
>>>BG> Which brings up another Question, how to disable this? I just want it
>>>BG> to have a reverse pointer, I dont care if that pointer also resolves...
>>>BG> They are different orders of magnitude IMHO, and asking for the latter
>>>BG> can get really hairy, especially considering some places which have
>>>BG> server farms and the like...
>>>
>>>You cannot change the way others operate their mailservers. If they
>>>wish to reject mail from you for this violation, then you need to
>>>contact them some other way and ask them to bypass you from that
>>>check.
>>
>>I dont think I was fully clear. This is _MY_ server, I do not want to
>>have this level of check. I do want to bounce if reverse DNS does not
>>work. I do NOT want to bounce if the reverse DNS name does not also
>>resolve. As far as I can tell the reject_unknown_client does a reverse
>>lookup followed by a forward lookup. I Only want to do the reverse...
>
>
> a known hostname. A hostname that isn't backed by an A record is
> meaningless, since anyone can return any PTR junk as the hostname.
It is not useless nor meaningless. I have been slowly turning on some
of these rules for anti-spam purposes. [does some quick number
crunching] ... Since I have turned it on three hours ago it has rejected
2984 emails (this relay usually processes 200,000+ inbound/outbound
corporate emails a day). Of these 2984, 583 of them had unique IP
addresses. Of these 583, 392 had absolutely no reverse DNS (a decent
majority). Of those which do have reverse pointers but which the
forward name resolves differently there are 68 (the remaining have a
reverse pointer which gives a name that presumably does not resolve at
all). Of these 68, probably 1/4 of them are legitimate. I.e. I WANT to
receive the email from them. So how is it meaningless to reject a
decent amount (68% of what it does currently), and still allow in some
unwanted email but also to NOT reject some wanted email. Vs the current
configuration which just doesn't work in a real world.
I was hoping to use this to help weed out the noise, before passing
things into an RBL and other anti-spam measures. It seems perfectly
appropriate to have a switch which will let few a possible problems onto
the next level, but which can be used to help immediately drop problems
before moving them onto more obtrusive checks. Yes, it only drops the
really stupid people who cannot even setup a reverse DNS record (or
forge one), but apparently this is the majority. It is also better than
not dropping them, which is what I am faced with at this point in time.
While in a perfect world everybody would setup their IPs to do complete
reverse and forward lookups in order. I do not do it ON PURPOSE for
many of my servers. I just don't want to provide this much information
to the world. I have set it up for my mail servers, only to keep things
working well. Unfortunately, I cannot control the policy of another
site, and when push comes to shove people would rather get some spam
with their mail, than no mail at all. If anything is meaningless or
useless, it is the way reject_unknown_client works currently.
As for the server farm issue, I know it is common (I dont do this
myself, but have seen it even in the last three hours) for a site to
setup a server farm which has multiple IPs all reverse resolving to one
primary IP, which then is a round robin. It is unlikely that this
reverse->forward process will be lucky and hit the right combination
(and is aggrivated by how many servers are in the farm).
Victor....@morganstanley.com
> with their mail, than no mail at all. If anything is meaningless or
> useless, it is the way reject_unknown_client works currently.
>
A fine way to win friends and influence people. The design rationale of
the "reject_unknown_client" restriction is to defend an MTA from
clients that hide or forge their identity. It works as designed.
This may not coincide with your goals. It is imprudent to call good
software "useless" in an effort to convince a community of
unpaid volunteers (and especially the unpaid author) to help you.
You want a new feature. Make a clear case for your new feature, but this
is not a good start...
I think that "reject_nonptr_client" (as a new restriction, not a
replacement for reject_unknown_client) may be a reasonable first step for
an administrator to take while thinking about the stricter
"reject_unknown_client".
I have also observed that sometimes one wants "reject_unknown_client" only
for the side-effect of deferring mail from clients whose double
verification fails due to temporary DNS problems. One could also distill
this into a narrower restriction. Such a restriction would only be useful
if can bound the scope of the its "defer_if_reject" action to apply just
to the immediately following "check_client_access" restriction. This would
be a new mechanism. Perhaps this would be a modifier like warn_if_reject,
for example:
...
defer_if_temp_unknown check_client_access hash:/etc/postfix/white-list,
...
Justifying more complexity in already complex logic takes good evidence
that it is broadly useful and solid logic to show that it can be
implemented reasonably and explained to its potential users. In the
above case this is far from clear, so I am illustrating how to explain
what you are looking for without losing your cool.
As for "reject_nonptr_client", just implement it in
"src/smtpd/smtpd_check.c" and share your experiences. If it proves useful
to a broad list of users it might be adopted one day, although the chances
just got substantially lower :-(
--
Viktor.
Brandon Gillespie
> On Mon, 11 Nov 2002, Brandon Gillespie wrote:
>
>>with their mail, than no mail at all. If anything is meaningless or
>>useless, it is the way reject_unknown_client works currently.
>
> A fine way to win friends and influence people. The design rationale of
> the "reject_unknown_client" restriction is to defend an MTA from
> clients that hide or forge their identity. It works as designed.
My response was due to the previous three responses that said what I was
asking for is meaningless, useless and apparently without rhyme or reason.
While it may be obvious to the developers that reject_unknown_client
does a full loop in its DNS lookup, it is not clear in at least the
sample-* documentation. The specific statement is:
reject the request if the client hostname is unknown.
But I dont recall ever seeing how 'unknown' is quantified. Since I can
do a reverse DNS on the IP address (which it complains about) it appears
to be known by the tools I use.
> As for "reject_nonptr_client", just implement it in
> "src/smtpd/smtpd_check.c" and share your experiences. If it proves useful
> to a broad list of users it might be adopted one day, although the chances
> just got substantially lower :-(
I may or may not get around to it. Were I to believe the code would
actually end up somewhere I probably would, but the response so far is
"you ask for something which is meaningless, useless, etc." or "We
havn't done it for 10+ years, and dont see why we should start now, so
go away". Before lecturing the community, perhaps consider how you come
across yourself. I have contributed to many open source projects, but
do find it a common failing the air of general indifference towards
other people's desires and goals. While this is a direct result of
developers "scratch their own itch" it tends to turn off new users let
alone people who may also end up contributing code to the end project.
Wietse Venema
ADD something that does what you want, instead of requesting an
INCOMPATIBLE CHANGE to something that people have been deploying
for years.
Talking about attitudes, barging into a mailing list screaming BUG
in the subject line is not how one usually makes friends.
Wietse
Brandon Gillespie:
Wietse Venema
> On Mon, 11 Nov 2002, Brandon Gillespie wrote:
>
> > While it may be obvious to the developers that reject_unknown_client
> > does a full loop in its DNS lookup, it is not clear in at least the
> > sample-* documentation. The specific statement is:
> >
> > reject the request if the client hostname is unknown.
>
>
> Looking at the sample configuration files aren't a good substitute for
> reading the approrpiate documentation. You really, really want to
> understand what your mail system will and won't accept.
And accurate documentation is even more valuable. The text in the
referenced URL needs updating to reflect the reverse/forward lookup
strategy.
Wietse
Bill Campbell
...
>And accurate documentation is even more valuable. The text in the
>referenced URL needs updating to reflect the reverse/forward lookup
>strategy.
If I understand this correctly, this strategy is to (a) get a hostname
using the PTR, (b) check for ``MX'' or ``A'' records for that hostname.
Bill
--
INTERNET: bi...@Celestial.COM Bill Campbell; Celestial Software LLC
UUCP: camco!bill PO Box 820; 6641 E. Mercer Way
FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
URL: http://www.celestial.com/
``Are we at last brought to such a humiliating and debasing degradation,
that we cannot be trusted with arms for our own defense? Where is the
difference between having our arms in our own possession and under our own
direction, and having them under the management of Congress? If our defense
be the real object of having those arms, in whose hands can they be trusted
with more propriety, or equal safety to us, as in our own hands?''
-- Patrick Henry June 9, 1788, in the Virginia Convention on the
ratification of the Constitution.
Michael Tokarev
[]
> I was hoping to use this to help weed out the noise, before passing
> things into an RBL and other anti-spam measures. It seems perfectly
> appropriate to have a switch which will let few a possible problems onto
> the next level, but which can be used to help immediately drop problems
> before moving them onto more obtrusive checks. Yes, it only drops the
> really stupid people who cannot even setup a reverse DNS record (or
> forge one), but apparently this is the majority. It is also better than
> not dropping them, which is what I am faced with at this point in time.
May I suggest you to do just the opposite? Use any and all of dns blocklists
you want, but BEFORE checking for rDNS, sender's domain, or helo hostname
in DNS. Or else your server(s) will reject spam from numerous open relays
which have non-working rDNS, or with fake unresolvable senders, etc etc -
all is not under your control - for weeks or sometimes for months(!),
again and again and again, and your mailserver (or, dns server) will try
to reslove their client's hostname but will constantly fail each time.
Mind you, way too many misconfigured/unadministered systems out there
have _non working_ DNS - not that there is no PTR record or it points
to some fake name, but your resolver will be unable to reach nameservers
responsible for that PTRs, or those NSes will be lame, or respond with
access denied (becaues M$ support staff told us to do so, and we're
trusting them) or hell knows what else.
This is the reason why I always tries to use syntactic checks first,
local blocklists, various DNS blocklists (which are running, and temporary
DNS errors are ignored here), and only after all this, in that order:
reject_unknown_sender_domain,
reject_unknown_client,
reject_unknown_hostname
I tried this in different order as well - this one works for us the
best way.
> While in a perfect world everybody would setup their IPs to do complete
> reverse and forward lookups in order. I do not do it ON PURPOSE for
> many of my servers. I just don't want to provide this much information
Just give them some meaningless names (like dhcp-12.domain.tld, host-C.example.com
etc), but set this up in DSN properly. Enouth for most purposes.
> to the world. I have set it up for my mail servers, only to keep things
> working well. Unfortunately, I cannot control the policy of another
> site, and when push comes to shove people would rather get some spam
> with their mail, than no mail at all. If anything is meaningless or
> useless, it is the way reject_unknown_client works currently.
>
> As for the server farm issue, I know it is common (I dont do this
> myself, but have seen it even in the last three hours) for a site to
> setup a server farm which has multiple IPs all reverse resolving to one
> primary IP, which then is a round robin. It is unlikely that this
> reverse->forward process will be lucky and hit the right combination
> (and is aggrivated by how many servers are in the farm).
That'll ok too. Multiply A records, that is. Postfix will use that
just fine.
/mjt
Schmehl, Paul L
That's 85/19,000th of a percent! How about contacting the owners of
those 17 IPs and ask them to fix their broken equipment? Oh
wait......Postfix will do that for you, but rejecting the mail with an
appropriate error message...
Paul Schmehl (pa...@utdallas.edu)
TCS Department Coordinator
University of Texas at Dallas
http://www.utdallas.edu/~pauls/
Victor....@morganstanley.com
> There are only three options available:
> a - rewrite English so that "unknown" means something other than it does
A client with a only a PTR record is unknown. The only "known" clients are
verified reverse resolved clients, just as the only known list subscribers
are verified subscribers.
This term "known" from English does not more naturally apply to the
property of having a PTR than to the property of having a verifiable name.
It is used in the Postfix community as a term of art that evolved out of
the need to do domain-name based entitlement.
Similarly the word "trusted" means member of $mynetworks, the word
"virtual" means 20 different things ... :-)
--
Viktor.
Roger B.A. Klorese
>On Mon, 11 Nov 2002 rog...@queernet.org wrote:
>
>
>
>>There are only three options available:
>>a - rewrite English so that "unknown" means something other than it does
>>
>>
>
>A client with a only a PTR record is unknown. The only "known" clients are
>verified reverse resolved clients, just as the only known list subscribers
>are verified subscribers.
>
>
A client with a PTR record that does not correspond to an A record is
not unknown.
1.2.3.4 IN PTR 4.3.2.1.dsl.myisp.com
foo.mydomain.com. IN A 1.2.3.4
...is a perfectly reasonable and typical situation.
Sven 'Darkman' Michels
> A client with a PTR record that does not correspond to an A record is
> not unknown.
>
> 1.2.3.4 IN PTR 4.3.2.1.dsl.myisp.com
>
> foo.mydomain.com. IN A 1.2.3.4
>
> ...is a perfectly reasonable and typical situation.
right, BUT, the client is known as 4.3.2.1.dsl.myisp.com (as long as
your isp has a correct A record). First the PTR is looked up, and then
the result of the PTR lookup is checked. If a PTR record exists,
and the A record of the PTR points to the connecting IP the client
is NOT unknown. All other cases means the client is unknown.
Colin Campbell
If I may throw my little piece of small change in here. I think some of
the confusion may arise from not making blatantly obvious the meaning of
"unknown" is. Here's the four "unknowns" from smtpd.cf:
reject_unknown_client: reject the request if the client hostname is unknown.
reject_unknown_hostname: reject HELO hostname without DNS A or MX record.
reject_unknown_sender_domain: reject sender domain without A or MX record.
reject_unknown_recipient_domain: reject domains without A or MX record.
The last three are obvious. The first one only becomes clear if you read
the code (smtpd_peer_init in smtpd_peer.c) to discover how smtpd
determines that it doesn't know the client's hostname, ie:
ip1 = getpeername(socket)
hostname = gethostbyaddr(ip1)
ip2 = gethostbyname(hostname)
reject (at appropriate place) if
hostname == null
ip1 != ip2
If I understand the code right, maybe the comment would be better as:
reject_unknown_client: reject the request if the client has no PTR record
or if the A record for the discovered hostname doesn't resolve to the
connected ip.
Colin
--
Colin Campbell
Unix Support/Postmaster/Hostmaster
CITEC
+61 7 3227 6334
Roger B.A. Klorese
> Roger B.A. Klorese wrote:
>
>> A client with a PTR record that does not correspond to an A record is
>> not unknown.
>>
>> 1.2.3.4 IN PTR 4.3.2.1.dsl.myisp.com
>>
>> foo.mydomain.com. IN A 1.2.3.4
>>
>> ...is a perfectly reasonable and typical situation.
>
>
> right, BUT, the client is known as 4.3.2.1.dsl.myisp.com (as long as
> your isp has a correct A record).
But there's no reason for my ISP to have an A record with that name on
it -- I don't wish my system known by that name; they wish to associate
that name with their IP address. No reason they should match up.
Simon White
> While in a perfect world everybody would setup their IPs to do complete
> reverse and forward lookups in order. I do not do it ON PURPOSE for
> many of my servers. I just don't want to provide this much information
> working well.
Some IP addresses for internal / extranet servers should be hidden... but
if a machine is a public server then you should make a hostname and IP
combination public. This is the nature of *public* services.
Private / extranet / internal servers should be on an internal DNS on
private IPs which are NATted / in a VPN and should never be shown to the
public.
Now, all the mail you receive should be from mail servers (more or less)
and those servers should be set up even more rigourously than some web
server or random TCP service host. A mail server is by nature very
public and should resolve backwards and forwards to the same
IP/hostname. I don't think anyone can disagree with me there.
So, again, I don't think it's such a bad thing to do a forward/reverse
lookup on any SMTP server out there. The reason I can't do this is
because I am in Morocco, and I have enough problems getting people to
get even more basic configurations working before I attack DNS here. The
TLD registrar isn't RFC compliant so how can I expect someone else to
fight them for a delegation of an 8IP subnet to look after the reverse
map correctly?
I'd be interested to hear, Brandon, why you "do not do it ON PURPOSE"
for many of your servers, which by their nature are PUBLIC and therefore
it is only correct to give the public who visit them an arbitrary
hostname which resolves to their IP and vice versa.
One day, I may switch reject_unknown_client on for our Postfix server
and spend a week fielding calls from our customers on why mail is
rejected. I have already had calls from people who say I have "strict"
mail controls on my server but heck, I keep fighting the good fight. I
feel it's my responsibility to do "my bit" for the online community. If
I don't, then I am admitting that I am prepared for everything to start
to slide into disarray. Once, the Internet was an organised and
structured place. Now, due to overzealous admins, possibly with not
enough time on their hands, and misplaced paranoia, people are really
starting to thing that the RFCs are "not for them". Sad.
--
[Simon White. vim/mutt. si...@mtds.com. GIMPS:% see www.mersenne.org]
J'ai essayé de travailler proprement, en misant sur la qualité de service
et la rapidité d'intervention. Maintenant, je travaille à la marocaine, à
coups de bakchich. Le pire, c'est que ça marche. -- Bernard Buisson Crouzet
Brandon Gillespie
> So, again, I don't think it's such a bad thing to do a forward/reverse
> lookup on any SMTP server out there. The reason I can't do this is
> because I am in Morocco, and I have enough problems getting people to
> get even more basic configurations working before I attack DNS here. The
> TLD registrar isn't RFC compliant so how can I expect someone else to
> fight them for a delegation of an 8IP subnet to look after the reverse
> map correctly?
Server farms. Consider the situation which I know exists in many places:
Farm of 10 servers, each with their own IP. Reverse pointer on
each ip address gives the name of domain.com (not a unique name).
However, DNS on domain.com doesn't resolve to any of the 10 servers,
instead it resolves to a service address which is on a load balancer,
which then directs traffic to one of the ten addresses.
This setup is common, and is a good enterprise setup. NAT'ing the 10
individual addresses is not desired, perhaps for load reasons or perhaps
for other peripheral reasons (I know some backup systems have a problem
running through NATs). Regardless, this is what the USER WANTS, it is
what exists frequently on large scale highly available deployments.
> I'd be interested to hear, Brandon, why you "do not do it ON PURPOSE"
> for many of your servers, which by their nature are PUBLIC and therefore
> it is only correct to give the public who visit them an arbitrary
> hostname which resolves to their IP and vice versa.
Server farms. www.iomega.com looks like a single server, it isn't. I
have no intentions of publishing the individual server names behind
www.iomega.com, nor do I even need to, even though they are internet
addressable. DNS is not a requirement to route network traffic.
Infact, the ONLY time I do setup reverse pointers is when one of my
internet servers originates a connection, or on a common service address
(such as www.iomega.com). While some of these restrictions may make
complete sense on a single-install, they break down on the larger
enterprise deployment scale. And trying to force the enterprise
deployment to behave like a single server is not a solution.
> One day, I may switch reject_unknown_client on for our Postfix server
> and spend a week fielding calls from our customers on why mail is
> rejected. I have already had calls from people who say I have "strict"
> mail controls on my server but heck, I keep fighting the good fight. I
> feel it's my responsibility to do "my bit" for the online community. If
> I don't, then I am admitting that I am prepared for everything to start
> to slide into disarray. Once, the Internet was an organised and
> structured place. Now, due to overzealous admins, possibly with not
> enough time on their hands, and misplaced paranoia, people are really
> starting to thing that the RFCs are "not for them". Sad.
Unfortunatey I have to consider why I exist at my organization. I have
a job to serve the users. For them, they want the email. I may have
personal motivations to want to be strict and follow standards, but in
the end I know where my pay check comes from.
BTW, I ended up having to turn of reject_unknown_client, too much
legitimate email was being bounced. Based off what I have seen, I would
like to know how many people have it enabled, and also have a sizable
relay (greater than 50,000 emails processed per day) or user base (more
than 500 users). From what I've seen, I cannot imagine it is used in
much of a "real world" (i.e. large deployment) because it just blocks
too much legitimate email. Like it or not, the full loop in DNS isn't
always configured.
Ultimately in the end it appears my problem was purely in
mis-interpreting what 'an unknown name' means (and the docs not being
clear about it).
-Brandon
Clifton Royston
> Sven 'Darkman' Michels wrote:
> > Roger B.A. Klorese wrote:
> >
> >> A client with a PTR record that does not correspond to an A record is
> >> not unknown.
> >>
> >> 1.2.3.4 IN PTR 4.3.2.1.dsl.myisp.com
> >>
> >> foo.mydomain.com. IN A 1.2.3.4
> >>
> >> ...is a perfectly reasonable and typical situation.
> >
> >
> > right, BUT, the client is known as 4.3.2.1.dsl.myisp.com (as long as
> > your isp has a correct A record).
>
> But there's no reason for my ISP to have an A record with that name on
... and so when your system is not known by that name, it seems
to me pretty good plain English to call it an "unknown" client.
(Remember, that name from the reverse lookup is the only one initially
available to a site it may be connecting to.)
IMHO, this area of configuration confuses people because most people
(even admins) have never thought about it much, and because the whole
topic is inherently confusing, not because of any problem with the
terminology.
-- Clifton
--
Clifton Royston -- LavaNet Systems Architect -- clif...@lava.net
"As for yourself, ... I am well disposed to hope you may hitherto have
escaped many Vices of your Country. But by what I have gathered from
your own Relation, and the Answers I have with much Pain wringed and
extorted from you, I cannot but conclude the Bulk of your Natives to be
the most pernicious Race of little odious Vermin that Nature ever
suffered to crawl upon the Surface of the Earth."
- Jonathan Swift, _Gulliver's Travels_
Clifton Royston
> Hi,
>
> If I may throw my little piece of small change in here. I think some of
> the confusion may arise from not making blatantly obvious the meaning of
> "unknown" is. Here's the four "unknowns" from smtpd.cf:
>
> reject_unknown_client: reject the request if the client hostname is unknown.
> reject_unknown_hostname: reject HELO hostname without DNS A or MX record.
> reject_unknown_sender_domain: reject sender domain without A or MX record.
> reject_unknown_recipient_domain: reject domains without A or MX record.
>
> The last three are obvious. The first one only becomes clear if you read
Right. It's a documentation issue. The documentation needs to be
clarified, and I think everyone agrees on that. More documentation is
good even if people don't always read it, because one can then indulge
in the pleasure of telling them to go read it. :-)
Phil Howard
| Server farms. Consider the situation which I know exists in many places:
|
| Farm of 10 servers, each with their own IP. Reverse pointer on
| each ip address gives the name of domain.com (not a unique name).
| However, DNS on domain.com doesn't resolve to any of the 10 servers,
| instead it resolves to a service address which is on a load balancer,
| which then directs traffic to one of the ten addresses.
|
| This setup is common, and is a good enterprise setup. NAT'ing the 10
| individual addresses is not desired, perhaps for load reasons or perhaps
| for other peripheral reasons (I know some backup systems have a problem
| running through NATs). Regardless, this is what the USER WANTS, it is
| what exists frequently on large scale highly available deployments.
If whoever decides on what the reverse DNS names will be wants them to
be names which cannot validate in forward DNS, then so be it. They make
their choices and choices have consequences. Shame on the ISP _only_
if they do not at least inform the customer that there are consequences.
| > I'd be interested to hear, Brandon, why you "do not do it ON PURPOSE"
| > for many of your servers, which by their nature are PUBLIC and therefore
| > it is only correct to give the public who visit them an arbitrary
| > hostname which resolves to their IP and vice versa.
|
| Server farms. www.iomega.com looks like a single server, it isn't. I
| have no intentions of publishing the individual server names behind
| www.iomega.com, nor do I even need to, even though they are internet
| addressable. DNS is not a requirement to route network traffic.
| Infact, the ONLY time I do setup reverse pointers is when one of my
| internet servers originates a connection, or on a common service address
| (such as www.iomega.com). While some of these restrictions may make
| complete sense on a single-install, they break down on the larger
| enterprise deployment scale. And trying to force the enterprise
| deployment to behave like a single server is not a solution.
If those servers behind the load balancer at 147.178.1.100 do not try
to originate any SMTP connections to the internet with other IP address
then I don't see any problem. If they do need to send public mail,
such as sending users a confirmation for signups or orders, then you
can put the reverse DNS in, or, perhaps better, "smart host" all the
web servers over to a mail server (I'm guessing the workload of sending
mail would be less than the workload of responding to HTTP). The received
headers might then show the extra hop, but who cares if it says that
mail.iomega.com received a message from www.iomaga.com (e.g. every one
of the servers had the same rDNS and mail.iomega.com didn't care because
it trusted those internal IP address). It would be a normal setup that
way and wouldn't reveal any more info about what you are doing than if
the separate web servers made direct connections.
| > One day, I may switch reject_unknown_client on for our Postfix server
| > and spend a week fielding calls from our customers on why mail is
| > rejected. I have already had calls from people who say I have "strict"
| > mail controls on my server but heck, I keep fighting the good fight. I
| > feel it's my responsibility to do "my bit" for the online community. If
| > I don't, then I am admitting that I am prepared for everything to start
| > to slide into disarray. Once, the Internet was an organised and
| > structured place. Now, due to overzealous admins, possibly with not
| > enough time on their hands, and misplaced paranoia, people are really
| > starting to thing that the RFCs are "not for them". Sad.
|
| Unfortunatey I have to consider why I exist at my organization. I have
| a job to serve the users. For them, they want the email. I may have
| personal motivations to want to be strict and follow standards, but in
| the end I know where my pay check comes from.
Which basically means you don't generally make policy decisions, or if
you do, someone else can override them easily.
| BTW, I ended up having to turn of reject_unknown_client, too much
| legitimate email was being bounced. Based off what I have seen, I would
| like to know how many people have it enabled, and also have a sizable
| relay (greater than 50,000 emails processed per day) or user base (more
| than 500 users). From what I've seen, I cannot imagine it is used in
| much of a "real world" (i.e. large deployment) because it just blocks
| too much legitimate email. Like it or not, the full loop in DNS isn't
| always configured.
So far, all my large clients (of that size) do not bounce based on
unknown client, but one is still considering doing so. For them I
don't actually make a specific recommendation one way or the other,
but just inform them of the advantages and disadvantages. Many of
the smaller ones do have it enabled. I also do it on my mail system
which only has about 150 users (but that figure is set to grow with
the addition of a new service to be deployed in a few months).
| Ultimately in the end it appears my problem was purely in
| mis-interpreting what 'an unknown name' means (and the docs not being
| clear about it).
I find that happens a lot (the docs not being clear). Diving in and
seeing how things actually behave is often more informative than docs.
--
-----------------------------------------------------------------
| Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ |
| phil-...@ipal.net | Texas, USA | http://ka9wgn.ham.org/ |
-----------------------------------------------------------------
Simon J Mudd
> Sven 'Darkman' Michels wrote:
>
> > Roger B.A. Klorese wrote:
> >
> >> A client with a PTR record that does not correspond to an A record is
> >> not unknown.
> >>
> >> 1.2.3.4 IN PTR 4.3.2.1.dsl.myisp.com
> >>
> >> foo.mydomain.com. IN A 1.2.3.4
> >>
> >> ...is a perfectly reasonable and typical situation.
> >
> >
> > right, BUT, the client is known as 4.3.2.1.dsl.myisp.com (as long as
> > your isp has a correct A record).
>
> But there's no reason for my ISP to have an A record with that name on
> it -- I don't wish my system known by that name; they wish to associate
> that name with their IP address. No reason they should match up.
However it is a good thing if you identify yourself as
4.3.2.1.dsl.myisp.com because then you pass the tests that have been
complained about.
Although ugly, being in precisely this situation and NOT owning my IP,
I use the following in master.cf to identify myself correctly.
smtp unix - - n - - smtp -o myhostname=156.Red-80-35-166.pooles.rima-tde.net
I guess if I wanted to use my real domain name mail.wl0.org then I'd
just have to pay for ip and my ISP would do the reverse mapping for
me.
Simon
--
Simon J Mudd, Postfix RPM Packager, Amsterdam, The Netherlands.
email: sjm...@pobox.com, Tel: +31-627-592 627
Mark Plowman
>
> rog...@queernet.org ("Roger B.A. Klorese") writes:
>
> > Sven 'Darkman' Michels wrote:
> >
> > > Roger B.A. Klorese wrote:
> > >
> > >> A client with a PTR record that does not correspond to an A record is
> > >> not unknown.
> > >>
> > >> 1.2.3.4 IN PTR 4.3.2.1.dsl.myisp.com
> > >>
> > >> foo.mydomain.com. IN A 1.2.3.4
> > >>
> > >> ...is a perfectly reasonable and typical situation.
> > >
> > >
> > > right, BUT, the client is known as 4.3.2.1.dsl.myisp.com (as long as
> > > your isp has a correct A record).
> >
> > But there's no reason for my ISP to have an A record with that name on
> > it -- I don't wish my system known by that name; they wish to associate
> > that name with their IP address. No reason they should match up.
>
> However it is a good thing if you identify yourself as
> 4.3.2.1.dsl.myisp.com because then you pass the tests that have been
> complained about.
>
> Although ugly, being in precisely this situation and NOT owning my IP,
> I use the following in master.cf to identify myself correctly.
>
> smtp unix - - n - - smtp -o myhostname=156.Red-80-35-166.pooles.rima-tde.net
Simon, I very slow this morning, can you explain why have you given
your 'real' hostname only to the smtp daemon and not to all processes
via main.cf?
> I guess if I wanted to use my real domain name mail.wl0.org then I'd
> just have to pay for ip and my ISP would do the reverse mapping for
> me.
Here in the Netherlands the provider XS4ALL includes a forward and
reverse mapping to your own subdomain of 'xs4all.nl' in their
'standard' ADSL package (but I suspect that that is rare).
> Simon
> --
> Simon J Mudd, Postfix RPM Packager, Amsterdam, The Netherlands.
> email: sjm...@pobox.com, Tel: +31-627-592 627
Greetings
Mark
P.S. Welcome to the Netherlands and thanks again for the nice RPM's!
--
If each of us have one object, and we exchange them,
then each of us still has one object.
If each of us have one idea, and we exchange them,
then each of us now has two ideas.