Sendmail Alias

[jesselferguson]

I currently run sendmail with two different domains, one of them being restricted. When sending from the unrestricted domain to the restricted one, the mail will only be forwaded to the other domain if the username is "aliased" within the alias file. The mail must be addressed to a non-existent domain, and when the server sees that, it changes it to the actual domain name and forwards it to the appropriate recipient. My dilemma is that I have nearly 2000 users that I must maintain within the alias file. Which in turn creates a LOT of work for me. I have tried applying several rules to "strip" the "false" domain and replace it with the real one but cannot get it to work properly. I do not need any changes when going from the restricted domain to the unrestricted one. Can anyone help me out with trying to solve this problem???

 

[RhythmAce]

You totally lost me on this one. What do you mean by restricted and unrestricted? Or this "The mail must be addressed to a non-existent domain ..." can you rephrase it so even I can understand? Sorry?

 

[jesselferguson]

Sorry about that. This has me a bit confused too. I was a little uncertain on exactly what I could talk about. I spoke with my supervisors and they clarified me on exactly what I could divulge while asking the question. This is what I came up with…

I work on a military installation with two domains. One of them unclassified, the other classified. When a user wants to send an e-mail from the unclass network to the classified one it is addressed like so:

userID@hq.jfcom.mil

The mail server checks the alias file and see that address and qualifies it as:

userID@hq.jfcom.smil.mil (The .smil being the Classified network)

Then passes it to a guard, which is the "go-between" that passes mail from high-to-low/low-to-high.

So we have a very extensive alias file with each user set up as userID@hq.jfcom.mil=userID@hq.jfcom.smil.mil.

Mail server is set up to reject anything directly addressed to the .smil domain...i.e.

userID@hq.jfcom.smil.mil will be rejected because the .smil domain is not recognized in DNS.

With the amount of users we have on the domain it is very difficult to alias each and every one of them.

Bottom line...the question(s) I pose to you...
Are there any rules/settings I can enforce to automatically "strip" the incoming hq.jcom.mil and replace it with hq.jcom.smil.mil and forward it on, vice having to use the enormous alias file? Also…when sending from class to unclass I need the server to be able to strip the ".smil" from the senders address without having to refer to the alias file.

Clear as mudd now???? And by the way...Thank you VERY much for the rapid response. I have read many threads on here and respect whatever help you can provide.

Jesse L. Ferguson
Unix Systems Administrator
Ki, LLC.
jesse.ferguson@jfcom.mil

 

[RhythmAce]

On the out going mail, you would use MASQUERADE_AS to change every email from that server to the desired "from" address. As for the incoming mail, you could write a procmail recipe to do the trick. This way everything is done automagically and you don't need to mess with the alias or virtusertable. I don't have the specific recipe for this but I will look into it and get back as soon as quick as I can. Some out there however may already have it. As for the masquerading, you would add this line to sendmail.mc:

MASQUERADE_AS(`unsecure.domain.mil')dnl

Then build the new sendmail.cf with this command:

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

You may have to change the paths to match your system or change to that directory.

Then restart sendmail:

/etc/init.d/sendmail restart

I'll try to get back soon with the other info.

 

[jkupski]

Were I you, I would ask a moderator to edit/delete your post above. Most of us here do not have security concerns as demanding as yours, yet we are careful to strip identifying information out of our posts--i.e. using "example.com" and "secure.example.com" would be much better than the real domains you have posted.

When attacking a critical system, every bit of information helps, right? So why help the other guy?

Just a suggestion.