I have got a feature configured to deploy the EmailReceived event
receiver and attach this to all instances of document  libraries in my
site collection.

If I send an email  to the library  then the event  is fired and the
event manager is clearly looking for my dll to run my code. However
the following error is logged in event viewer:

Event manager error: Could not load file or assembly 'FaxCentre,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=7a8dbe70cd93fc15' or
one of its dependencies. The system cannot find the file specified.

The dll is correctly deployed to the GAC and the feature used to
attach the event receiver is using the correct FQ assembly name as
you can see in the error message (I have doubled checked the public
key just to be sure).

Is this error masking the true problem? Is this a
security/permissions issue? If the dll is in the GAC it should
automatically have Full Trust shouldn't it?

make sure you reset IIS.............

Has this fixed anyone's issue? I have the exact same issue in my
environment and there is precious little available online that
explains a successful resolution to this issue.

I also cannot debug this particular issue because I can't connect to
the OWSTimer service since I don't have email  on this test server. If
I send from Outlook without the eventhandler attached the list gets
email. With the EmailReceived handler  attached it gets nothing and I
get the self-explanatory (NOT!)

Event manager error: Could not load
type 'SPFeedBack.SPFeedback_Handler' from assembly 'SPFeedbackWSP,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=0ba07e60a9eec119'.

First, you are deploying the event  handler assembly to the GAC right? It won't
work deployed anywhere else.
Second, is your assembly actually called SPFeedbackWSP and the namespace inside
the assembly just SPFeedBack? Normally these will default to the same thing so
I would double check that you've got them right.

The error message you are getting is that it can't find and load the assembly
you've specified. That's usually one of the two problems mentioned above.

I am kind of having the same problem. Are you saying that the assemly name and
the namespace should be named the same ?

They don't need to be, but when you create a new project in Visual Studio they
start out the same. They can be changed later if needed, but when I see an
error saying that an assembly can't be found the names are one of the places
that I normally start.

So the whole issue came down to the fact that the DLL was being ghosted in the
OWSTimer's cache. What I wasn't doing was restarting the OWSTimer when I was
doing the deployment. That would flush the previous version out. As it turns out
the OWSTimer service is responsible for all kinds of batch jobs that run in
SharePoint. I was looking for some kind of Outlook/Exchange service to fiddle
with.

This is the post-it I wrote myself that is now taped permanently to my monitor:
1. Rebuild
2. Refresh
3. Restart
4. Deploy
5. Attach
6. Send Email

1: Rebuild the app in Visual Studio
2: Refresh the WSPView (I know, I will transition to WSP Builder soon ;)
3: Restart the OWSTimer Service (Start-->Run..-->services.msc)
4: Deploy the Solution
5: Attach to the OWSTimer process (this was specifically for EmailReceived
debugging; normally you attach to the w3wp.exe to debug other event  handlers.)
6: Send Email from your client and wait for the process to pick it up.

I may have completely bungled through this process, but I am the wiser for it
let me tell you!! And, my app is in production.