Date: Wed, 01 May 2002 10:02:43 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Chip McClure <vhm3@hades.gigguardian.com> Cc: groggy11@mail.com, freebsd-chat@freebsd.org Subject: Re: bad isp - dns Message-ID: <3CD01FB3.CB80561A@mindspring.com> References: <MPEAJAJOPDJHNPGGEBMMKENOCBAA.vhm3@hades.gigguardian.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CD01FB3.CB80561A>