You do not have permission to send to this recipient

If you get the following while sending to an internal recipient, chances are you haven’t set your environment to accept for the domain you are sending to.

Your message did not reach some or all of the intended recipients.

Subject: Subjects are fun!

Sent: 1/1/2009 1:00 PM

The following recipient(s) could not be reached:

Lastname, Firstname on 1/1/2009 1:00 PM

You do not have permission to send to this recipient. For assistance, contact your system administrator.

user@domain.com

The example that prompted me to post this was one where admins were adding SMTP addresses on to their users for domains that they weren’t configured to be responsible for. How do we solve this? In this case the servers were Exchange 2003, so we will start there. We need to open ESM, navigate to Recipients -> Recipient Policies

Right click and choose New -> Choose E-Mail Addresses

Navigate to the E-Mail Addresses (Policy) tab, click New, and choose SMTP Address.

Enter an example SMTP address with domain you'd like to be able to send to.

Enter a name and select who you'd like to automatically receive this policy (I left mine blank as they wanted to sporadically assign the e-mail address as needed.)

Click OK. it should ask you to run this policy now, but if it doesn't you may right click your new policy and choose 'Apply this policy now...'

In Exchange 2007 you need only make your Exchange organization authoritative for the domain in question. The place to do this is under Organization Configuration -> Hub Transport -> Accepted Domains tab.

Add your domain here as authoritative and it will accomplish the same feat.

There are other causes for this issue, but this is the most common from what I have seen.

Using LDIFDE & ADSIEdit to Verify Recipient Policies

Originally I wanted to run something like this:

ldifde -f C:\test.txt -t 3268 -s DC.domain.com -j C:\ -r "(&(|(mailnickname=*)(objectClass=user))(|(homeMDB=*)(msExchHomeServerName=*))(userPrincipalName=*@domain.com))" -l "msExchPoliciesIncluded"

Unfortunately userprinicipalname doesn't play nicely with  "msExchPoliciesIncluded."  I'm guessing this is the case with more than one user defined attribute.  Example output:

dn: CN=sname\, gname,OU=Users-Company,OU=User,DC=Corp,DC=com

changetype: add

If we change it to reflect only objectclass=user:

ldifde -f C:\test.txt -s DC.domain.com -j c:\ -r "(&(objectClass=user)(homeMDB=*))" -l "msExchPoliciesIncluded"

It pulls this as example:

dn: CN=sname\, gname,OU=User,DC=domain,DC=Corp,DC=com

changetype: add

msExchPoliciesIncluded: 

 {86129EE7-F6C7-4CE2-9549-C242356184C6},{3B6813EC-CE89-42BA-6F11-D87D4AA30DBC}

msExchPoliciesIncluded: 

 {7DF5DEB4-C2EA-4920-BC8C-5342BC1E95E6},{26491CFC-4EB1-4857-861B-0CB8DF22B5D7}

You can also find this in adsiedit here to verify:

Archiving Policies - Hard limit, or Quotas?

I run into this constantly on the job. Many people like the simplicity of a hard set policy; IE archive everything 30 days old or older. My argument to this is that quotas, while requiring a bit more planning and foresight, are eventually much more dynamic and easily managed in the long run.


My personal preference is to set the archive quota to use the warning limit. This way, it is seamless to the user as it prevents the notifications, and doesn't hit the send/receive limit either. Another pro to using the warning quota in Exchange is that because they don't see a warning, they don't misinterpret what is going on and try to archive it themselves. This is compounded if the ability to use PSTs has not been disabled via group policy. Hard set limits such as nothing in the last 7 days will help with potential user grief (especially if the slider on the quota limit tab is set toward size rather than date). Also setting the "Do not archive messages smaller than" setting is good to set so that it mitigates the frustration of having to pull down an archive that didn't really get any size savings anyways. Stubs tend to be around 2-3kb, so that part is a no brainer. I like setting it a bit higher due to the balance of overall size savings versus user acceptance. Again this is a culture based decision.


The quota limit tab is another place decisions come in to play. You'll want to set the percentage of the quota to begin archiving from to at least be less than what the person could receive in a day. That number also affects how far down to archive. The size versus message age debate is one of, surprise, culture. If your company receives a barrage of large images for viewing/editing, you'll obviously take different steps than if your business relies on email primarily as a quick messaging service.




Now to the dynamic part. The best part about this system is that you only need one policy. This means no messing with automation policies down the road, no messy clean ups, etc. Merely change the quota limit in Exchange for the mailstore or individual and viola. Powershell scripts in Exchange 2007 make this a very powerful solution!