|
I'm investigating a potential problem with our Exchange server (I'm not really an Exchange admin, I just inherited this)/ I received an email from another companies CIO complaining that our Exchange server is DDoSing their email server. Basically from what I understand, they blacklisted our server so when someone from our company sends someone from their company an email, it gets bounced back to us with 554 5.7.1 domain is blacklisted. I'm ok with this. Well the other day someone from my company sent about 15 emails to their company - all were rejected with 554 5.7.1 - however the CIO from the other company says that it resulted in over 11529 emails coming from this one email address from our company. I used message tracking and I only see 15 emails sent from that email address. Could our Exchange server not be handling 554 5.7.1 rejection correctly? Where would I go to check this? Any other ideas? Could it be on the other companies end? Basically I'm at a loss how to track down this issue.
|
#
¿
Jun 13, 2012 14:27
|
|
|
|
| # ¿ Apr 18, 2024 04:33 |
|
|
Hello, I have an Exchange 2007 server. I would like to block all email that users send to a specific domain. I have done two things (neither of which are working) 1) I opened up Hub Transport under Organization Configuration -> Anti-spam -> Recipient Filtering -> added *@blockeddomain.com to the Blocked Recipients 2) Under Organization Configuration -> Transport Rules -> setup a new rule that applies 'from users inside the organization and when a To contains @blockedomain.com, send Delivery not authorized, message refsued to sender with 5.7.1 and silently drop the message. Neither of these are working, users are still able to send messages to the blocked domain. What am I doing wrong and how can I blocked all emails sent to a specific domain? Thanks! edit: i just created a fake mx record for the domain in our DNS and sent it to a black hole. that seemed to work as a last resort. Got Haggis? fucked around with this message at 20:52 on Aug 17, 2012 |
|
#
¿
Aug 17, 2012 15:06
|
|
|
I'm running Exchange 2007. Currently we have some PHP scripts that connect to it using IMAP - we have recently discovered that PHPs IMAP functions can't determine the email address alias the email was sent to -it will always only show the default email alias. So for example, if I have both of the email addresses for my account - me@mydomain.com and haggis@mydomain.com whereas me@mydomain.com is the default address, using IMAP, there appears to be no way to tell if emails were sent to haggis@mydomain.com - they will always show up as being from whichever alias is set to default. I looked at the headers in Thunderbird using IMAP and it also only shows the default email address - however in Outlook 2007, it will show the correct alias (haggis@mydomain.com). (as a sidenote, gmail and some other providers will sometimes have the correct email alias in the headers...but hotmail.com won't, so can't depend on that). So my question is....is there anyway to actually get which email alias the email was sent to? Would it be possible to do something server side on Exchange? I looked at Transport Rules, but there doesn't seem to be any way to determine the actual email alias. I was hoping I could maybe just create a transport rule that looked at the email alias and filtered them to different folders, or something along those lines.
|
|
#
¿
Jul 11, 2013 14:19
|
|
|
theperminator posted:The Delivered-To header will show the actual name of the mailbox, but the To header should reflect the alias it was sent to it definitely doesn't when using IMAP. It shows whatever email address is set as 'default'. It's very annoying. edit: after researching, apparently microsoft added this "feature" in Exchange 2007 and say that its a feature, not a bug...it actually rewrites IMAP headers....stunning http://www.mail-archive.com/exchange@intm-dl.sparklist.com/msg21844.html Got Haggis? fucked around with this message at 19:49 on Jul 15, 2013 |
|
#
¿
Jul 15, 2013 19:38
|
|
|
so I have run across a bug in Exchange 2007 - took forever to figure out the cause, seems like it still exists in Exchange 2010 as well. Anyway, turns out if users have over 20k messages in their inboxes and connect to exchange using the IMAP protocol, it will shoot the CPU percentage up to 100%, killing the server. Have been able to fix it by having users delete messages. While I know that it is possible to impose email limits like total size of mailbox, is there anyway to limit the number of items users are able to store in folders? I would like to set this at around 10k or so, but I can't seem to find a way to do it.
|
|
#
¿
Jan 31, 2014 21:16
|
|
|
The Electronaut posted:What does your throttling policy look like? Also get-imapsettings? When you say kills the server, which server? Are you running multirole single server or split role? multirole single server...we have about 40 users total. Can't turn off IMAP because the majority of clients run Thunderbird (and linux). After narrowing it down to folder size I was able to do some googling and found many people with the same issue. Users with a large number of items in their inbox cause the CPU of the server to climb to 100%. Clear out inboxes, problem solved. I was hoping there was an automatic way to make this happen or at least work the same way it does with messagebox size. It seems ms says its good practice to have no more than 5k messages per folder in exchange 2007 - but somewhat depends on server specs. This server is fairly beefy - for us we really see problems once users have more than 20k messages in any folder.
|
|
#
¿
Jan 31, 2014 22:22
|
|
|
|
| # ¿ Apr 18, 2024 04:33 |
|
|
I'm running Exchange 2007. Is there any way to check a database (or something?) before sending an email - if its in the database, don't send? We maintain a 'DoNotEmail' mysql database that works great for all of our automated programs. The problem is, we have humans that send out emails using our Exchange server that sometimes email the people in the DoNotEmail database (which we don't want). Right now, when someone gets a "please don't email me" request, someone logs into Exchange, creates a new mail contact with that persons email, then adds them to a distribution group called 'DoNotEmail' - exchange is set up to drop emails from anyone in that group. The main issue is that its somewhat time consuming for someone to do this (takes about 2 minutes per request - they have 300 requests back logged) Many moons ago, I created a script that looked at the mysqldb and automated this process, but it caused our server to crap out - likely because we have thousands of Do not Email requests dating from years ago - and exchange couldn't handle all of the mail contacts being created (there may be a hard limit). I'm just wondering if there is a better way to do this? Like, I dunno, set up a postfix proxy or something that has some sort of script that looks at our mysqldb, and only send the email if not in the database...just thinking postfix may be easier to deal with in that regard.
|
|
#
¿
Jul 30, 2015 16:41
|
|