Sendmail by Root, blocked by Mail Server

[Eddie Warren]

Security has blocked mail sent from our HP-Servers (via root)utilizing Sendmail. Our mail server is a seperate UNIX server, it's sole jobe is distributing mail. The server answers on port 25 and says hello, but as soon as it see's the message is from root@someServer.com it gives "Restricted mailbox name and forces the mail to the originating hosts /.dead.letter file.
I've tried /.forward and /etc/mail/aliases, inserting an alias for root.
Just wondering if anyone has hit this wall before and was able to devise a way around it. For now all our EMS, omniback notifications are failing.

Thanks

[Christopher McCray_1]

Hello,

In simple terms, tell your security "people" to knock it off!!!


Chris

[Pete Randall]

What was the reason/excuse for them doing this? I can't imagine what purpose it could serve.

Pete

[Uday_S_Ankolekar]

1.Check for more details in /var/adm/ssylsog/mail.log file for possible reason for this. Check with Sendmail -bv option if address gets resolved.
2. Is DNS and resolv.conf file are configired correctly ??

3.Stop and restart the sendmail daemon by /sbin/init.d sendmail stop and start.

-USA..

[John Poff]

Hi,

I agree with Chris. Go to the Security geeks and tell them how much trouble their restriction is causing you. If that fails, I would start calling them EVERY time you have a failure that you would have been notified by via e-mail. Sometimes people don't appreciate our efforts until their phone rings at 3:00am. ;)


JP

[Uday_S_Ankolekar]

Also check if smtp protocol is being stopped at firewall level.

[Eddie Warren]

Thanks for the Help. I've already told the Security people they can handle the system outages since we won't be notified.

[Steven E. Protter · Accepted solution]

For a private client, I just set up a little script.

Instead of running errors to mailx, I created text files and did an su -c mailman "/usr/contrib/bin/mailout"

The script just sends an email with an ascii attatchment.

Since you already had mail coming off the server, you're in good shape and need not check /etc/nsswitch.conf and dns configuration.

It's annoying, but thats the way it goes.

Our smtp server won't forward mail that where it can't authenticate the DNS as a valid domain on the public internet. Our servers fully qualified domain names are not registered, specifically so if theres a firewall failure, theres still no way for anyone to mailbomb us.

As stated by others, your security people went over the top.

Email the error logs to upper management, or if you have a help desk, open a help desk call for every failed email, they won't be able to resolve the call without easing up on the security.

If your help desk is like ours, their batting average(average time from call to resolution) will quickly fall, and you will gain allies in your fight.

Steve

[Christopher Caldwell]

use the generics database (/etc/mail/genericstable) to rewrite the from address of outbound mail.

Uncomment:

# Generics table (mapping outgoing addresses)
#Kgenerics dbm /etc/mail/genericstable

and

# handle generics database
#R$+ < @ $=G . > $: < $1@$2 > $1 < @ $2 . > @ mark
#R$+ < @ *LOCAL* > $: < $1@$j > $1 < @ *LOCAL* > @ mark
#R< $+ > $+ < $* > @ $: < $(generics $1 $: @ $1 $) > $2 < $3 >
#R<@$+ + $* @ $+> $+ < @ $+ >
# $: < $(generics $1+*@$3 $@ $2 $:@$1 + $2@$3 $) > $4 < @ $5 >
#R<@$+ + $* @ $+> $+ < @ $+ >
# $: < $(generics $1@$3 $: $) > $4 < @ $5 >
#R<@$+ > $+ < @ $+ > $: < > $2 < @ $3 >
#R< > $+ < @ $+ . > $: < $(generics @$2 $@ $1 $: $) > $1 < @ $2 . >
#R< > $+ < @ $+ > $: < $(generics $1 $: $) > $1 < @ $2 >
#R< > $+ + $* < @ $+ > $: < $(generics $1+* $@ $2 $: $) > $1 + $2 < @ $3 >
#R< > $+ + $* < @ $+ > $: < $(generics $1 $: $) > $1 + $2 < @ $3 >
#R< $* @ $* > $* < $* > $@ $>canonify $1 @ $2 found qualified
#R< $+ > $* < $* > $: $>canonify $1 @ *LOCAL* found unqualified
#R< > $* $: $1 not found

in sendmail.cf.

The genericstable file has the format
user differentuser@newdomain.com.

To "compile" the file:

makemap dbm /etc/mail/genericstable < /etc/mail/genericstable

As an alternative, if you control the program sending the nofications, rewrite the head of the e-mail (e.g. mailx -r diff@diffdomain.com)

[Chris Vail]

At the risk of being overly simplistic: try a .forward file. We have EXACTLY the same problem here with our network people. We just put a .forward file in the root home directory, which sends it to a whole list of people with their real email addys. The network people don't know the difference, and what they don't know they can't bother us about.

Good luck
Chris