Bill Davidsen wrote:
> Liam wrote:
> > Bill Davidsen wrote:
> >> Liam wrote:
> >>> We have a remote, off-site (redundant, sorry) production server our
> >>> domain name points to.
> >>> Let's call it "X.domainname.com".
> >>>
> >>> We have a small web server at the office that performs a couple but
> >>> vital functions that needs to send an e-mail out about twice a day to
> >>> two different external recipients.
> >>> It has no domain name pointed to it.
> >>>
> >>> Every email that goes out from the local server, let's call
> >>> "Y.localdomain", that goes out gets returned with:
> >>>
> >>> The original message was received at Mon, 24 Apr 2006 21:16:47 -0500
> >>> from localhost [127.0.0.1]
> >>>
> >>> ----- The following addresses had permanent fatal errors -----
> >>> <(the recipient email address)>
> >>> (reason: 550-Verification failed for <root@Y.localdomain>)
> >>>
> >>> ----- Transcript of session follows -----
> >>> ... while talking to celticbear.com.:
> >>>>>>>>> DATA
> >>> <<< 550-Verification failed for <root@Y.localdomain>
> >>> <<< 550-unrouteable mail domain "Y.localdomain"
> >>> <<< 550 Sender verify failed
> >>> 550 5.1.1 <(the recipient email address)>... User unknown
> >>> <<< 503 valid RCPT command must precede DATA
> >>>
> >>> Now, it works fine if I replace the Y server's /etc/sysconfig/network
> >>> 's
> >>> HOSTNAME=Y.localdomain
> >>> with
> >>> HOSTNAME=X.domainname.com
> >>>
> >>> Works perfectly.
> >>> However, and there may be no way around this if this is the only way to
> >>> get it to work, but a few of us SSH shell into the local server AND
> >>> that remote server, and if the local HOSTNAME= matches the remote
> >>> server's, the command prompt and shell window title bar are the same
> >>> for both servers and that can cause no end of confusion and
> >>> accidentally doing something on one server meant for the other.
> >>>
> >>> I'd like to find some way in which the HOSTNAME= can be different and
> >>> unique, but the mail from it still be accepted as verifyable.
> >>> I can change the local domainname to the remote's domain name, and that
> >>> makes the sending server in the mail headers become "Y.domainname.com"
> >>> but the existance of that machine name "Y" prevents the verification.
> >>>
> >>> So looking into SENDMAIL options I tried the "domain masquerading" but
> >>> that didn't change a single thing in the header.
> >>> I added the outgoing user to "trusted users" but also no difference.
> >>>
> >>> Thinking the problem is, or at least partly, the remote server only
> >>> accepting verification checks from itself (X.domainname.com) and
> >>> obviously not for Y.domainname.com, I looked into its SENDMAIL options.
> >>> I added Y.domainname.com to "local domains" and "relay domains" but
> >>> still no change.
> >>>
> >>> I've reached the end of what I can find to try.
> >>> Any other suggestions?
> >>> Thanks!! =)
> >>>
> >> First, for sanity every machine should have and use a FQDN, even if it
> >> isn't in DNA. You have obfuscated to the point where I'm not sure if you
> >> have that.
> >
> > Yeah, I guess a another $9 domain name from GoDaddy would fix this
> > pretty easy. =/
> >
> >> I would suggest that if possible you tell the hidden machine to use the
> >> visible machine as a smart mailer, and then tell the visible machine to
> >> accept mail from the hidden site (by IP) and allow relay. The smart
> >> mailer is in sendmail.mc (and then create the .cf file), and the relay
> >> stuff is on the visible machine in /etc/mail/access.
> >
> > Ah, OK, I get the concept. Makes sense.
> > Not sure I get the details.
> > Here's what I tried:
> >
> > Remote main mail server ("X":
> > I added to /etc/mail/access
> > Y.domainname.com RELAY
> > (Y's public IP address) RELAY
>
> Just a thought, did you rebuild the table after that? Using makemap?
> >
> > And then on the local, "hidden" server ("Y"):
> > /etc/mail/mailertable
> > .localdomain smtp:domainname.com
> >
> > (and in sendmail.cf)
> > DMdomainname.com
> > CMY.domainname.com
> > CMlocaldomain
> >
> > And still, no difference.
> >
> > Here's an odd bit, doubt it's related but maybe...
> > In looking at /var/log/maillog on the local "hidden" server ("Y") after
> > trying, I found this entry:
> >
> > Apr 26 16:12:23 fileserve sendmail[32213]: k3QLCJAj032211:
> > to=<news@celticbear.com>, ctladdr=<liam@Y.domainname.com> (500/500),
> > delay=00:00:03, xdelay=00:00:03, mailer=esmtp, pri=120374,
> > relay=celticbear.com. [69.93.188.250], dsn=5.1.1, stat=User unknown
> > Apr 26 16:12:23 fileserve sendmail[32213]: k3QLCJAj032211:
> > k3QLCNAj032213: DSN: User unknown
>
> Did you reboot after the change? Set the new value with "hostname -s" if
> not?
>

Odd. I:
[root@webserve mail]# hostname -s
hostname: Unknown host
When I made the hostname changes I just restarted the service: network.
Thought that'd be enough. Guess not.
I reboot the machine, and now all the logs refer to itself as
"webserve" instead of "fileserve". So, guess that's fine now. =) Thanks
for the advice!
But I still get "hostname: Unknown host" when I hostname -s.

> I would just have forwarded the mail to the open host by setting the
> smartmailer field in sendmail.mc and building sendmail.cf. The open host
> will probably accept the mail. I don't think the name change was needed
> if you just send all the non-local mail for remailing.

Well, on the local machine I made sure to add the following to the MC:
define(`SMART_HOST',`smtp.domainname.com')dnl
MASQUERADE_AS(`domainname.com')dnl

and rebuilt sendmail.cf

On the remote server I have in:
/etc/mail/access
Y.domainname.com RELAY
local-IP-address RELAY

and /etc/mail/relay-domains
Y.domainname.com
local-IP-address

All that sounds like it should be enough... in fact! on the local
server in /var/log/maillog I don't get the errors anymore, I get:

Apr 27 15:41:51 webserve sendmail[2427]: k3RKfpWa002427: from=liam,
size=53, class=0, nrcpts=1,
msgid=<200604272041.k3RKfpWa002427@webserve.domain name.com>,
relay=liam@localhost
Apr 27 15:41:51 webserve sendmail[2428]: k3RKfpRB002428:
from=<liam@webserve.domainname.com>, size=383, class=0, nrcpts=1,
msgid=<200604272041.k3RKfpWa002427@webserve.domain name.com>,
proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1]
Apr 27 15:41:51 webserve sendmail[2427]: k3RKfpWa002427:
to=news@celticbear.com, ctladdr=liam (500/500), delay=00:00:00,
xdelay=00:00:00, mailer=relay, pri=30053, relay=[127.0.0.1]
[127.0.0.1], dsn=2.0.0, stat=Sent (k3RKfpRB002428 Message accepted for
delivery)
Apr 27 15:41:52 webserve sendmail[2430]: k3RKfpRB002428:
to=<news@celticbear.com>, ctladdr=<liam@webserve.domainname.com>
(500/500), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=120383,
relay=smtp.domainname.com [72.3.xx.xx], dsn=2.0.0, stat=Sent
(k3RKfjXk013713 Message accepted for delivery)

Which seems OK, until I get the email back saying:

The original message was received at Thu, 27 Apr 2006 15:41:46 -0500
from webserve [64.19.xx.xx]

----- The following addresses had permanent fatal errors -----
<news@celticbear.com>
(reason: 550-Verification failed for
<liam@webserve.domainname.com>)

----- Transcript of session follows -----
.... while talking to celticbear.com.:
>>> >>> DATA
<<< 550-Verification failed for <liam@webserve.domainname.com>
<<< 550-unrouteable mail domain "webserve.domainname.com"
<<< 550 Sender verify failed
550 5.1.1 <news@celticbear.com>... User unknown
<<< 503 valid RCPT command must precede DATA


*sigh*
Well, I appreciate the feedback and assistance. =)
Thanks!
Liam

> You are getting close to my "I have to try it and look at logs" point,
> the method of forwarding is sound, that's how people with DHCP IPs
> usually do it, but the mail to Y.domainname.com should have been locally
> delivered, and I don't think changing or faking machine names was needed.
> >
> > That right after the timestamp, "fileserve", was the old machine name
> > for this box. It should now be Y.
> > I checked /etc/hosts and /etc/HOSTNAME and both have "Y", not
> > "fileserve".
> > Where else would it pull the name of the box from except from those
> > files?
> >
> > Anyway, thanks for the assistance!!
> > -Liam
> >
> >
> >> That's if you have a more or less stock config, if your distribution has
> >> moved things you will have to look.
> >>
> > Well, the visible main server is RedHet AS 2.1, and the local non-FQDN
> > server is Fedora Core 5. No changes from stock.
>
> AS 2.1... a piece of history. But it should work.
>
>
> --
> bill davidsen
> SBC/Prodigy Yorktown Heights NY data center
> http://newsgroups.news.prodigy.com