trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: March 2011

Re: [trinity-devel] bugs.pearsoncomputing.net - DNS entry causing confirmation email to be rejected by postfix 'reject_unknown_client'

From: "David C. Rankin" <drankinatty@...>
Date: Tue, 01 Mar 2011 00:52:37 -0600
On 02/28/2011 11:55 PM, Timothy Pearson wrote:
> I host my own DNS, but it looks like the problem
> is not DNS related this time around.  Rather it seems that my firewall box
> has messed up the routing; instead of originating traffic on .180 it has
> decided to originate traffic on .181, which was reserved for QuickBuild. 
> Fixing it may involve separating the firewall boxes due to the complexity
> of the routing tables in use.
> 
> Tim

Better you than me :)

  When you need another test, let me know. I'm also curious how fixing your
routing will fix what the 'internet' thinks is your hostname. I host my own dns
as well, but for this type of address reporting problem, I always had to fix it
where the internet thought host.3111skyline.com was, not where my server thought
it was. It always had to be fixed one level above me. (even if I were GM, the
same would be true) In my experience, these problems were always here:

    Internet DNS level
(your Registrar's reporting
  of pearsoncomputing.net)
             ^
             |
             |
   +---X--Internet-<-------->-+---<rest of the net>---
   |                          |
   Your DNS                   |
  (your server level DNS)     My DNS
      |                      (postfix, etc.)
      |                          |
      Your subnets               My subnets

X - data doesn't pass

  I may be misunderstanding what you mean by fixing the routing, but when
postfix checks to 'reject_unknown_client' it is getting the answer from the
"Internet DNS level" (above) and doesn't know what "Your DNS" (above) has to say
about it. Once your smtp server encodes the header info and sends the message
out into the ether, it's done with it. That's why I was thinking this issue
won't be helped by a fix at "Your DNS" level.

  Think of it this way. If you were going to change your domain to
"notpearsoncomputing.net" -- where would that change have to take place? You can
change "Your DNS" all day long and the change will never get propogated to the
internet DNS system. I think this problem has to be fixed at the same level you
would make that change -- so the fix get propogated to the internet DNS system.

  Good luck and let me know when you want another test. (take notes to when you
fix this problem -- I might need them :)


-- 
David C. Rankin, J.D.,P.E.