Exchange 2007 - blocking users from sending to certain email addresses (in database)

G

Got Haggis?

Veteran XX
I have an Exchange 2007 server.

I also have a RHEL5 server that has a MySQL database on it. One of the databases contains email addresses that have unsubscribed from communications from our company.

Is there anyway to somehow link these two up? The problem is that people using Outlook (thus, Exchange) still send emails to people that have unsubscribed. I don't want this, I want the emails to bounce if people try to send emails to the unsubscribed email addresses.

I guess i would like to create a transport rule that bounces email back if any of the email addresses match what is in the database. From my limited knowledge of Exchange, this seems like it would be impossible (other than manually adding email addresses to the rule, but this is pretty much out of the question)

Anyone know if it is possible to do something like this with Exchange?
 
I honestly couldn't even guide you in a direction for this. My opinion is can't be done, get some sucker to do the data entry.

Is it possible to create a query based distribution group in AD from SQL?
 
Last edited:
Got Haggis? said:
web app - people enter their email address to be unsubscribed, it populates the database
Click to expand...
right but how are your souless sales fags accessing said DB list? you said they use outlook, but how does outlook know who to send to? are you populating a distribution list?

i don't think you need any fancy cooperation between exchange and the mysql DB i think you need the DB to remove entries from the 'send to' list instead of storing 'unsubscriebed' addresses somewhere and hoping your systems go skynet and become aware of the fact that you don't want them sending to unsubscribed addresses.
 
MaD_ReBeL said:
right but how are your souless sales fags accessing said DB list? you said they use outlook, but how does outlook know who to send to? are you populating a distribution list?

i don't think you need any fancy cooperation between exchange and the mysql DB i think you need the DB to remove entries from the 'send to' list instead of storing 'unsubscriebed' addresses somewhere and hoping your systems go skynet and become aware of the fact that you don't want them sending to unsubscribed addresses.
Click to expand...

2 different systems....basically it is a sales person problem. marketing dept sends emails using a web app - that reads from said database. sales people get sneaky and want to do their own mailings, which bypass the 'do not send' list. Ideally I would like to limit the sales people (Exchange server people) from sending more than 50 emails a day, but again Exchange doesn't appear to support anything that would limit this on a daily basis.
 
You might be able to use something like xwall's approve system that supports scripting. I'm not positive if it handles outgoing email the same way, but it sounds like something third party like that would be easier than having some sort of exchange plugin coded.
 
Got Haggis? said:
2 different systems....basically it is a sales person problem. marketing dept sends emails using a web app - that reads from said database. sales people get sneaky and want to do their own mailings, which bypass the 'do not send' list. Ideally I would like to limit the sales people (Exchange server people) from sending more than 50 emails a day, but again Exchange doesn't appear to support anything that would limit this on a daily basis.
Click to expand...
here is how you fix the problem.

1) go buy the largest newspaper you can buy. these days, probably the wall street journal.

2) roll it up tight.

3) go to where the sales people sit

4) beat them on the head like naughty puppies, point and them directly and say "no!"

5) repeat step 4 until they all wet themselves or understand not to be douches.
 
um...

why don't you make a sql script that will dump the email addresses to a text file
then write a powershell script to insert those names into the transport rules for block send to

run the scripts every night, or at whatever interval you want to...

edit: you'll need to test what happens if you insert an address that's already in the rules. if that makes two entries then do some handling on the sql side to only dump new email addresses to the file

edit2: that will work. the rest of the responses are stupid. it'll take you 20 minutes to look up the scripts, and 10 minutes to test. enjoy.
 
Last edited:
Detox.enD said:
um...

why don't you make a sql script that will dump the email addresses to a text file
then write a powershell script to insert those names into the transport rules for block send to
Click to expand...

Arguably you should be able to write a powershell script to query MySQL directly if you have the necessary libraries in place. At least thats how I would do it.
 
can you export the smtp addresses from SQL? I'm not a SQL expert but I don't think it would be that hard to write a query to pull the smtp address from the database.

then take that export and put it into a transport rule. the rule is possible/will work provided there is some sort of unique identifier in the sender address, body or subject.
 
Got Haggis? said:
2 different systems....basically it is a sales person problem. marketing dept sends emails using a web app - that reads from said database. sales people get sneaky and want to do their own mailings, which bypass the 'do not send' list. Ideally I would like to limit the sales people (Exchange server people) from sending more than 50 emails a day, but again Exchange doesn't appear to support anything that would limit this on a daily basis.
Click to expand...

what is your SMTP gateway in your DMZ? If you had lets say an ironport you could create a throttling rule and possibly limit the senders from more than 50 emails per day. only problem with a cap like that is some idiot hits 50 and then freaks because he has some vital email that has to be sent after the 50.
 
Got Haggis? said:
2 different systems....basically it is a sales person problem. marketing dept sends emails using a web app - that reads from said database. sales people get sneaky and want to do their own mailings, which bypass the 'do not send' list. Ideally I would like to limit the sales people (Exchange server people) from sending more than 50 emails a day, but again Exchange doesn't appear to support anything that would limit this on a daily basis.
Click to expand...

Just curious, what happens when your sales people start receiving bounces and you can't even send regular emails to these customers due to your IP being passed around to various blacklists as a known spammer? From a business perspective, that is the last thing you want to happen to your employees.

If I'm understanding you correctly, you're trying to figure out how to give a 16 year old the keys to your Corvette to take it off-road racing.

In my opinion, you should always separate company communications from your corporate environment, but that's just me.
 
I don't know why he doesn't just use one of the multitude of commercial mailers out there that are setup in such a way to honour the system and allow users to subscribe/unsubscribe effectively, such as infousa or similar.
 
yeah, company communications are already separate - its just that some of the sales people are..well...assholes and don't give a shit. I'm trying to minimize the impact as much as possible.

exporting to txt file and then using powershell script to write the transport rule was my last resort, I was just wondering if there was some other way.

the problem is users unsubscribe/subscribe with no problems but sales guys, using a different email system, are emailing some of these same people - even when they have been told they should not be doing this. Since they are all commission based, some of them are going to do whatever it takes to get them a larger paycheck, even if it impacts the company.
 
I understand, but you have to realize that this behavior will eventually fuck over your entire company in the worst way imaginable and it won't be the sales guys taking the blame. Tread carefully.
 
You must log in or register to reply here.
Back
Top