Configuring Messaging Front End Mail Handlers
Hi,
I am trying to configure 2 Sun messaging front end mail handlers. These 2 mx machines will accept all email from the internet and pass them to a barricuda spam box which in turn passes them to the final sun messaging server for delivery. We are not yet in a position to have these boxes look at the ldap server for user group information, so I want them just to accept all email for our domain and then pass it on to the spamfilter box. I have been unable as of yet to find out how to do this. I can run ldap locally on each box for the config, but I don;t want it to look at any ldap information for users/groups. If anyone has done this, some advice would be great.
Thanks,
Darren
[711 byte] By [
DarrenLCC] at [2007-11-26 11:16:58]
# 1
Well, um. . .
I have seen the results of doing exactly what you suggest. It's not pretty.
What happens is that spammers send thousands of messages to you, mostly addressed to people that don't exist.
If your MTA's could check that the users exist, they could reject such messages instead of accepting them. By accepting anything, you have to write it to disk, send it to your barracuda boxes, and process it. Then, you have to send back a DSN that says, "this user doesn't exist". And, then, you will find that 75% of those users are bogus, too, so you have to deal with that on top of the original messages.
If you eventually expect to allow your MTA's access to ldap, then you should start that way. Don't mess around with this half-way setup. Voice of too much experience.
# 2
Well, um. . .
I have seen the results of doing exactly what you suggest. It's not pretty.
What happens is that spammers send thousands of messages to you, mostly addressed to people that don't exist.
If your MTA's could check that the users exist, they could reject such messages instead of accepting them. By accepting anything, you have to write it to disk, send it to your barracuda boxes, and process it. Then, you have to send back a DSN that says, "this user doesn't exist". And, then, you will find that 75% of those users are bogus, too, so you have to deal with that on top of the original messages.
If you eventually expect to allow your MTA's access to ldap, then you should start that way. Don't mess around with this half-way setup. Voice of too much experience.
# 3
Yes.. your correct.. this scenerio is not ideal but it is our current scenerio and the 2 old vms boxes (our current front end handlers) are dying fast and I need replacements up soon. We will move to the ldap solution, but I am not ready yet so I am hoping just to put in some replacements performing the same task until then. Unfortunately, I cannot find any way to configure these boxes just to accept mail and pass it on without the ldap lookup. I just don;t understand the workings enough yet to know how to do this.
Any help would be great.
# 4
Darren, your projected scenario is far worse than "not ideal".
If you're willing to allow ldap servers on your relays, why not replicate your user data to them. That's really all that's needed.
Or, allow your Messaging Servers to connect to your existing ldap server. Use SSL, if you have to.
Personally, I don't have servers outside my firewall. I just open the correct ports to the servers, and keep the rest of my network secure. Much easier.
You can hit my personal ip address on any port except 25, (and other ports I keep open), and get no response. Hit 25, and you'll get my Messaging Server.
I don't accept messages for any user not on my system. Period.
Please reconsider your proposed plan. It's truly a "Bad Idea".
# 5
Hi Darren,
I second Jay's advice, from equally bad experience with handling bounce emails for non-existent email addresses. I also understand your situation (we also relied on old VMS/PMDF systems to route emails based on hand-rolled routing tables -- and these were never up-to-date.
So, onto the problem at hand.
It is fairly straight forward to relay email domains. It requires two settings:
1. A rewrite rule to put the email onto a new channel for the domain in question (relay.domain.com in the following example)
2. A new channel which forwards all the emails to the barricuda spam box (barricuda.domain.com in this example).
e.g.
relay.domain.com$U%$D@tcp_spambox-daemon
! tcp_spambox
tcp_spambox smtp mx daemon barricuda.domain.com
tcp_test-daemon
Regards,
Shane.
# 6
Thanks for all the comments. I have brought the boxes up with the ldap connectivity as you have strongly suggested. We are trying to overcome our hurdles in the background to make this work. We are currently seeing all the problems you both have described and have been for a few years. ( I just started in this position this year and am trying to get a handle on what is going on). Our current VMS boxes accept all mail and let the system in the background decide to reject it etc. Not a good plan.. but it is what it is. I think you are all correct and maybe my time is better spent fixing the back end problems rather than trying to work around them.
Thanks for all the GREAT advice!
