Date: Sat, 26 Jan 2008 19:19:48 -0500 From: Chuck Swiger <cswiger@mac.com> To: Gary Kline <kline@thought.org>, freebsd-questions@freebsd.org Subject: Re: why am i sending mutt mail with my FQDN?? Message-ID: <479BCE24.4020804@mac.com> In-Reply-To: <200801252223.02795.kline@thought.org> References: <200801251650.10700.kline@thought.org> <66C4132F-0441-43AF-87F0-6BCC7CBE8238@mac.com> <200801252223.02795.kline@thought.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Gary Kline wrote: > On Friday 25 January 2008 17:12:35 you wrote: >> On Jan 25, 2008, at 4:50 PM, Gary Kline wrote: >>> The problem with t rying to use mutt, even when I reach my >>> mailserver on >>> aristotle.thought.org, is that *somehow* -- I do not understand how >>> -- but >>> for some reason, mutt tacks on the FDQN rather than simply my domain >>> name. >> [ ... ] >> >>> it never reached me at magnesium.net. Can anybody clue me in? >> Sure. If you want to masquerade a local machine's FQDN to just your >> domain name, follow the happy instructions from the FAQ: >> >> http://www.sendmail.org/m4/masquerading.html > > well, i tried what was in the Sendmail.cf/README; I put the > MASQUERADE_AS() into both mc files. Below is the evidence that > it didn't work. Any other pages you can suggest...? > > > I0/85/212006 > MDeferred: 450 4.7.1 <tao.thought.org>: Helo command rejected: Host not found > Fbs > $_localhost [127.0.0.1] > $rESMTP > $stao.thought.org > ${daemon_flags} > ${if_addr}127.0.0.1 > S<kline@tao.thought.org> > MDeferred: 450 4.7.1 <tao.thought.org>: Helo command rejected: Host not found > rRFC822; freebsd-questions@freebsd.org Yes, you should either set up working DNS for all of your machines which send email (if you control the DNS for thought.org, consider using DynDNS or equivalent so that tao.thought.org is resolvable) or (depending on whether you have administrative control over the destination SMART_HOST mailserver) look into the access map: http://www.sendmail.org/m4/anti_spam.html#access_db ...or, failing that, enabling these with caution: accept_unresolvable_domains Normally, MAIL FROM: commands in the SMTP session will be refused if the host part of the argument to MAIL FROM: cannot be located in the host name service (e.g., an A or MX record in DNS). If you are inside a firewall that has only a limited view of the Internet host name space, this could cause problems. In this case you probably want to use this feature to accept all domains on input, even if they are unresolvable. relay_entire_domain This option allows any host in your domain as defined by class {m} to use your server for relaying. Notice: make sure that your domain is not just a top level domain, e.g., com. This can happen if you give your host a name like example.com instead of host.example.com. You can also define your local host name (aka class w) to be something which the other machine can resolve. By the way, an excerpt from the mail logs (/var/log/mail.log) are the best source of info for relaying issues, although it is possible to figure out some of the issues from a stuck message in the spool. It's also possible that if you set your SMART_HOST to your ISP's mailserver, and configure authentication with them, they will let you relay even if your mail submission is using local/invalid DNS hostnames. Regards, -- -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?479BCE24.4020804>