Our setup: we have two smtp virtual servers.  One is on port 25, allows anonymous connections, and only allows connections from our upstream spam filter provider.  The second smtp virtual server is on port 465, uses TLS, and requires authentication to our domain.  The server itself is in our DMZ, and only allows ports 80, 443, 25, and 465 from the outside.

Most users can authenticate to and use the smtp server on port 465.  Some of them (roughly ten so far)...notably one person in IT, one of our VPs, and one random user created yesterday...cannot.  Using Thunderbird, they get error 5.7.3, this user does not have permission to send as the user.  The debug logs on the exchange server show: user domain/user is not allowed to send as user@domain.com.

The smtp debug log shows smtp result code 454 (TLS unavailable at the moment) instead of 250-OK after the initial starttls (and a subsequent re-issuing of EHLO).

The client sees the server saying: 454, quit.

The choice of client does not seem to matter.  The problem is account-based, and not client or IP based.  Extensive logging (turning the logging up to 7 for all elements present in HKLM/CCS/Services/MSExchangeTransport/Diagnostics) shows nothing new; the transport insist that USER does not have the right to send as USER.

I've tried having the user log on as their fully qualified name (user@domain.com).  The trace shows that the username is what gets rejected, pre-authentication: MAIL FROM: user@domain.com gets a response of 454, pre-auth.

So, WTF?  I spent $100 last night opening a case with MSFT which, I feel, will result in several weeks worth of me repeating the same words over and over again (with new logs attached each time that show the same thing), followed by, eventually, either a patch or abandonment.

Regardless, I will update this entry with any resolution, since googling for this exact issue turns up a billion hits with no solutions.

Update [2008-2-7 9:55:35 by blixco]: This is apparently limited to Thunderbird and Mac Mail.

Update [2008-2-13 11:35:34 by blixco]: To fix: open active directory users and computers. Click View and select Advanced. Find the affected user, right-click, select Properties. In the Security tab, look for an object called SELF. If the SELF object ain't there, add it.

Make sure SELF has send-as, receive-as, and write permissions. There are a couple of other perms in there normally selected by default; leave them alone. Apply, then test.

This is apparently an artifact of migrating from an older (pre-win2k3) domain, and in our case were all users who had not ever used Outlook.