Searched, coulnd't find a post on this. Not critical. But I just tried to send an email using the personal contact form for a blocked user. The contact form was available and I got no error message when submitting the message - but it wasn't received (I was sending to an address I check).

I unblocked the user and send again. The message went through with no problems.

CommentFileSizeAuthor
#6 contact_disabled_user_fix.patch5.54 KBkaerast

Comments

kaerast’s picture

I can reproduce this in 5.1. Logged in as administrator, sending a message to a disabled user. No error message is displayed, and Drupal attempts to send the email. However the following is generated in Postfix's mail.log:

Feb  2 00:03:36 example postfix/pickup[17881]: AC3EB221C0C2: uid=33 from=<www-data>
Feb  2 00:03:36 example postfix/cleanup[26387]: AC3EB221C0C2: message-id=<20070202000336.AC3EB221C0C2@example.com>
Feb  2 00:03:36 example postfix/cleanup[26387]: AC3EB221C0C2: to=<unknown>, relay=none, delay=0, status=bounced (No recipients specified)

I'd therefore assume that Drupal is failing to detect the user's email address when the user is disabled, isn't detecting this, and so is trying to send to a blank email address without logging anything.

I believe the correct behaviour should be:

check if user is disabled
if user is disabled, check if user is administrator
if user is administrator allow form to be sent
otherwise generate an error message.

seanberto’s picture

Maybe I'm not understanding your point about checking if the user is the administrator. Is that to check if the sender is the administrator or the recipient user (who may or may not be blocked)?

I think it makes sense to allow the administrator to be able to use the contact form to communicate with blocked users. For example, to communicate the reason that the user has been blocked.

-s

kaerast’s picture

We need to check whether the user sending is an administrator. We don't want just anybody sending messages through the contact form of a disabled user, but it is vital that the administrators are able to send emails to disabled users.

kaerast’s picture

This issue is caused by line 360 of contact.module which will only load the recipient user object if it is enabled. I propose we change this to something along the lines of:

$account = user_load(array('uid' => arg(1)));
// check if the recipient account is enabled, or the sender is an administrator
if ($account->Status == 1 || user_access('administer site configuration')) {

  // stuff to send message

} else {
  drupal_access_denied();
}

I've just looked at Drupal 4.7.4, and this issue also exists there, so it's been around for a while. My proposed solution should work in 4.7.4 as well as it does in 5.x, so I'd like to see it backported too.

Right, I should probably get on with testing this and developing a patch.

webchick’s picture

I'd base it on "administer users" permission rather than "administer site configuration" permission, since that's what the contact form is based on.

This also needs to be in patch form. See http://drupal.org/patch.

kaerast’s picture

StatusFileSize
new5.54 KB

OK, I've created a patch based upon my previous comment and webchick's suggestion. I've also added a check when the form is being rendered.

I suppose we should return an error message somehow rather than simply giving a drupal_access_denied? How best to implement that?

kaerast’s picture

Status: Active » Needs work
Zothos’s picture

I would prefer a Message like:

"This User is blocked. You are not able to Contact him this way. Please excuse this matter."

Or something that tells the user what is going on now.
With this error message, he will maybe think its a site error...

Zothos’s picture

I would prefer a Message like:

"This User is blocked. You are not able to Contact him this way. Please excuse this matter."

Or something that tells the user what is going on now.
With the old error message, he will maybe think its a site error...

dave reid’s picture

Status: Needs work » Fixed

You can contact blocked users if you have the 'administer users' permission. Also no followup in two years, so closing the issue.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.