From owner-freebsd-chat Wed May 1 10:52:45 2002 Delivered-To: freebsd-chat@freebsd.org Received: from hades.gigguardian.com (vven-216.sjc.ca.bbnow.net [24.219.11.216]) by hub.freebsd.org (Postfix) with ESMTP id 15D4D37B41A for ; Wed, 1 May 2002 10:52:41 -0700 (PDT) Received: from europa (europa.gigguardian.com [192.168.1.2]) by hades.gigguardian.com (8.11.6/8.11.6) with SMTP id g41HqS000110; Wed, 1 May 2002 10:52:29 -0700 (PDT) (envelope-from vhm3@hades.gigguardian.com) From: "Chip McClure" To: "Terry Lambert" Cc: , Subject: RE: bad isp - dns Date: Wed, 1 May 2002 10:52:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <3CD01FB3.CB80561A@mindspring.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Terry, I agree totally. I was under the assumption when I had read the inital post, that this was a fully routable IP address space, and not one in the private space. And yes, ARPA will never give away the space for routing that one. :) Without much more information, it is kinda tough to suggest where to go next. As long as sendmail is configured properly (the access lists for relaying, and the smart host set), the clients on the back end are all using a valid email address, he will be able to send out mail from his system. Chip - -----Original Message----- From: Terry Lambert [mailto:tlambert2@mindspring.com] Sent: Wednesday, May 01, 2002 10:03 AM To: Chip McClure Cc: groggy11@mail.com; freebsd-chat@freebsd.org Subject: Re: bad isp - dns Chip McClure wrote: > Depending on the type of connection you have, I think you would > have a right to complain to your ISP about it. From my point of > view, if it is a residential, then you're probably out of luck with > getting reverse dns added by your isp. If your network connection > is better than residential dsl, or a cable modem, I'd start > complaining to the isp about it. You have a right to get reverse > dns in a commercial > hookup. The only other option, is to use your isp's smtp server to > relay all mail from your network. He described his problem badly. He could have described it in a single sentence: "How do I configure an outbound mail server on a non-routable network which resides behind a NAT?" I arrived at this because of the back-and-forth that has happened so far, from the context clues provided, but not explicitly stated (for some reason, people are reluctant to actually ever tell you what problem they are trying to solve, probably for fear that you will point out that their "solution" can't ever work, and they will have to change their configuration to one that will work). He still hasn't published the full information about his intended configuration to the list ...e.g., we don't know how the NAT will respond to incoming connection, we don't know if there is an external third party MX, and we don't know that the internal mail server is not retrieving it's email via ATRN or UUCP or some other mechanism which doesn't strip envelope information (e.g. "multidrop POP", of the kind badly supported by "fetchmail" -- so much for "The Cathedral and The Bazaar" being a meaningful document). The answer is that the mail server must masquerade as the NAT, so that exposed addresses in outbound email can be resolved to a replyable address. The "reverse delegations" he's having problems with are for 192.168 addresses. He's *never* going to get the ARPA delegations for those... agreed? He's also having problems with forward lookups for what are, in effect, unpublished hosts that live behind the NAT. To fix this, he should MASQUERADE_ENTIRE_DOMAIN() (see the sendmail book from O'Reilly for details on this m4 macro). He can't claim an unpublished domain part for a "helo", "ehlo", "mail from:", or "rcpt to:" argument. The mail server rejecting his email is doing so because there is no way to contact the sender of the email. If the sender is legitimate, that means he's asking the mail server to take delivery responsibility while refusing to provide the mail server with a method of discharging its responsibility in the case of failure (i.e. it has no place to send the DSN's in case of failure, because the sender is impossible to contact). If the sender is illegitimate, then it means he's asking the mail server to deliver his SPAM for him... and again, the mail server is saying "no". - -- Terry -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.8 iQA/AwUBPNAmvJuKtP8CSC69EQIJ4wCdGoBdabldbjk1YlOZ6AKeST3AzgAAn3U2 9+4w3Jf7sEHNsWRIGsgW/aY0 =gE0g -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message