When I first setup StarOffice on my Sun box, I set the Outbox's SMTP server to ex6.company.com, which was the name of the Exchange server. But now that was bouncing messages, saying something like "Relaying is not allowed". So, the first step was to change StarOffice's SMTP setting to point at the Sun box itself, gromit.company.com and use sendmailto get messages out. This way, my workstation itself was the relay, so to speak. But that still didn't work. A few weeks earlier, I had tried to get sendmail working so that I could have scripts send email. To get that to work I had put the following setting in /etc/mail/sendmail.cf:
# "Smart" relay host (may be null)
# DSmailhost.$m
DSex6.$m
This told sendmail to relay its mail via ex6. But that service was now turned off on ex6, so I remarked it out, restarted sendmail, and sent a message to my ISP address, which seemed to work. Problem solved!
Well, not quite. As time goes by, more and more ISPs, in an effort to prevent spam, require that the sender's host name be resolvable via DNS. Messages I sent had the sender address 'pscheie@gromit.company.com', but since my workstation isn't a public host (it's not visible on the internet), that host name couldn't be resolved. This didn't bother my ISP, but those of some friends were rejecting my messages because of it. Back to the web.
I should mention that to test sending a message I used
/usr/lib/sendmail -v person@address.com <message
to get a detailed account of sendmail trying to send the message. Invaluable, as it also shows what the sender's address is, and why my messages were being rejected.
Several web postings said that all that was necessary was to use the DM macro in sendmail.cf to trigger masquerading and everything would be fine:
# who I masquerade as (null for no masquerading) (see also $=M)
DMcompany.com
I made the change, sent a message, no joy. More hunting. I found one article that said there also needed to be a CM setting in sendmail.cf to tell sendmail which hosts/domains the masquerade setting should be applied to. I grep-ed for CM but it came up empty. Looking more carefully, I concluded that I needed to add the CM setting (I added just the last line):
# class E: names that should be exposed as from this host, even
if we masquerade
# class L: names that should be delivered locally, even if we have
a relay
# class M: domains that should be converted to $M
#CL root
#CE root
CMgromit.company.com
Save sendmail.cf, restart sendmail, send a message via 'sendmail -v', and it still doesn't work. Sigh. Back to the web.
After lots of hunting I found a posting in which it was said that the default setting in Ruleset 94, which governs masquerading, was incorrect. So I added the second line and commented out the third (original) line thusly:
S94
R$+
$@ $>93 $1
#R$* < @ *LOCAL* > $* $: $1 < @ $j . > $2
Save, restart, send a message, and...it worked! Some day I'll learn sendmail's syntax well enough to understand the difference between those two lines, but for now all that mattered was that it seemed to work. I was home free.
Well, almost. I couldn't be too upset with the mail admins for turning off open relaying because it was I who started them down the path that resulted in that change. What had started this whole thing was that a few friends' addresses were unreachable from within the company. But if I sent a message from my ISP account, the messages got through fine, which suggests that the problem was at the source, not the destination. The problem seemed to be DNS related. If I used
sendmail -v sara@herdomain.net <message
I got a message saying
sara@herdomain.net... Deferred: Name server: herdomain.net.: host name lookup failure
I ran nslookup with the server setting pointing to the company's DNS servers (Windows2K--bad idea I suspect). First, I just looked up the address record for herdomain.net, and that seemed okay, which I expected because I had always been able to successfully point my browser to www.herdomain.net. Then I typed
set q=mx
to tell nslookup to look for mail records, and told it to lookup herdomain.net again. This time I got back
*** dns1.company.com can't find herdomain.net: Non-existent host/domain
But then I set nslookup to look for any data types:
set q=any
and then I got a bunch of info including the mailserver for herdomain.com, the DNS servers, etc. So, the problem was that mail queries to the company DNS servers weren't always getting the right info. The solution for me was to add the DNS servers that belonged to the company's ISP to my /etc/resolv.conf file. Actually, I initially added the DNS server of my friend's ISP to resolv.conf and when that worked I knew I'd found the answer. But I didn't feel it was polite to use the DNS services of an ISP with whom I had no relation, so I changed it to the company's ISP DNS servers which also worked fine. I told our DNS people about the problem: they said it sounded like a mail problem, and of course the mail people think it's a DNS problem. I think it's a DNS problem, but I'll let them work it out.
07/26/2001
12/12/01